From daemon Thu Nov 6 09:56:19 1997 Delivery-Date: Thu, 06 Nov 1997 10:04:28 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id JAA16476 for ietf-123-outbound.10@ietf.org; Thu, 6 Nov 1997 09:55:38 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA16457; Thu, 6 Nov 1997 09:55:30 -0500 (EST) Message-Id: <199711061455.JAA16457@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-route-damp-00.txt,.ps Date: Thu, 06 Nov 1997 09:55:30 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Route Flap Damping Author(s) : C. Villamizar, R. Govindan, R. Chandra Filename : draft-ietf-idr-route-damp-00.txt,.ps Pages : 28 Date : 05-Nov-97 A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes. This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead Excessive updates to reachability state has been widespread in the Internet. This observation was made in the early 1990s by many people involved in Internet operations and remains to case to date. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is ``route flap''. The techniques described here are now widely deployed and are commonly referred to as ``route flap damping''. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-damp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-route-damp-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-damp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971105121541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-damp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-damp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971105121541.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Thu Nov 6 10:34:57 1997 Delivery-Date: Thu, 06 Nov 1997 10:34:57 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA17555 for ; Thu, 6 Nov 1997 10:34:57 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA14795 for ; Thu, 6 Nov 1997 10:37:58 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA23244 for idr-outgoing; Thu, 6 Nov 1997 09:55:43 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA23239 for ; Thu, 6 Nov 1997 09:55:38 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA16457; Thu, 6 Nov 1997 09:55:30 -0500 (EST) Message-Id: <199711061455.JAA16457@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-route-damp-00.txt,.ps Date: Thu, 06 Nov 1997 09:55:30 -0500 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Route Flap Damping Author(s) : C. Villamizar, R. Govindan, R. Chandra Filename : draft-ietf-idr-route-damp-00.txt,.ps Pages : 28 Date : 05-Nov-97 A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes. This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead Excessive updates to reachability state has been widespread in the Internet. This observation was made in the early 1990s by many people involved in Internet operations and remains to case to date. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is ``route flap''. The techniques described here are now widely deployed and are commonly referred to as ``route flap damping''. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-damp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-route-damp-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-damp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971105121541.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-damp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-damp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971105121541.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Mon Nov 10 08:12:17 1997 Delivery-Date: Mon, 10 Nov 1997 08:12:20 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id IAA11703 for ; Mon, 10 Nov 1997 08:12:15 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA01942 for ; Mon, 10 Nov 1997 08:15:15 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA23740 for idr-outgoing; Mon, 10 Nov 1997 07:27:24 -0500 (EST) Received: from door2inet.boehm.priv.at (mcp.vbs.at [194.152.163.128]) by merit.edu (8.8.7/8.8.5) with ESMTP id HAA23727 for ; Mon, 10 Nov 1997 07:26:55 -0500 (EST) Received: (from hannes@localhost) by door2inet.boehm.priv.at (8.8.5/8.8.5) id NAA23558; Mon, 10 Nov 1997 13:26:03 +0100 Message-ID: <19971110132602.08109@boehm.org> Date: Mon, 10 Nov 1997 13:26:02 +0100 From: "Hannes R. Boehm" To: idr@merit.edu Subject: Filtering on IBGP-Sessions ? Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=FL5UXtIhxfXey3p5 X-Mailer: Mutt 0.74 Sender: owner-idr@merit.edu Precedence: bulk --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii I wonder wether it is possible (recommended) or not to filter on IBGP sessions. I've got a transit area in my autonomous system. If I do not filter on the IBGP sessions all routers in the transit area have full BGP routes. -> since I don't want to upgrade all my routers to the same amount of RAM, I am thinking about filtering on some of the IBGP sessions. -> our Router at the local Exchange does not have to have full BGP routes (-> we do not offer transit for any party at the local Exchange) My Questions: Is it possible to filter on IBGP sessions (-> is it recommended ?) ? Should I use a conferderation of two or more private AS to solve this problem ? Hannes R. Boehm -- -- "The nice thing about standards is that there's so many to choose from." -- Andrew S. Tannenbaum !------------------------------------------------------------------! Hannes R. Boehm email : hannes@boehm.org www : http://hannes.boehm.org PGP-key : http://hannes.boehm.org/hannes-pgp.asc !------------------------------------------------------------------! --FL5UXtIhxfXey3p5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3i iQCVAwUBNGb9Wv+orJHFWmKpAQGM3AP9EhiC5omub74QVUXOFoltbjnUhC/LYubE y1Wp3uG5h+FJn5mZbF4fb5qrAp3VSvmIJB00dOpOKJrrMBEh4OpQks9Tc8jr5CL9 9Q9kUsH6Gl2ixMy06A42Fwf4UOqebknHWK/NmPKsoQuj59hJq99xCu+8z9hSs1hZ Gdk23WOWXbg= =OaGH -----END PGP SIGNATURE----- --FL5UXtIhxfXey3p5-- From daemon Mon Nov 10 10:07:10 1997 Delivery-Date: Mon, 10 Nov 1997 10:14:04 -0500 Return-Path: daemon Received: (from daemon@localhost) by ietf.org (8.8.7/8.8.7a) id KAA12757 for ietf-123-outbound.10@ietf.org; Mon, 10 Nov 1997 10:05:46 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA12737; Mon, 10 Nov 1997 10:05:42 -0500 (EST) Message-Id: <199711101505.KAA12737@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-ipv6-00.txt Date: Mon, 10 Nov 1997 10:05:41 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing Author(s) : F. Dupont, P. Marques Filename : draft-ietf-idr-bgp4-ipv6-00.txt Pages : 5 Date : 07-Nov-97 BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-ipv6-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971107115426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-ipv6-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971107115426.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Mon Nov 10 10:53:19 1997 Delivery-Date: Mon, 10 Nov 1997 10:53:20 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA14146 for ; Mon, 10 Nov 1997 10:53:19 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02659 for ; Mon, 10 Nov 1997 10:56:19 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA25731 for idr-outgoing; Mon, 10 Nov 1997 10:05:51 -0500 (EST) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA25725 for ; Mon, 10 Nov 1997 10:05:47 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA12737; Mon, 10 Nov 1997 10:05:42 -0500 (EST) Message-Id: <199711101505.KAA12737@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-ipv6-00.txt Date: Mon, 10 Nov 1997 10:05:41 -0500 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing Author(s) : F. Dupont, P. Marques Filename : draft-ietf-idr-bgp4-ipv6-00.txt Pages : 5 Date : 07-Nov-97 BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-ipv6-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971107115426.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-ipv6-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971107115426.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Tue Nov 11 01:35:20 1997 Delivery-Date: Tue, 11 Nov 1997 01:35:26 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id BAA28210 for ; Tue, 11 Nov 1997 01:35:09 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA05719 for ; Tue, 11 Nov 1997 01:38:07 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA15509 for idr-outgoing; Tue, 11 Nov 1997 00:50:54 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA15505 for ; Tue, 11 Nov 1997 00:50:50 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id AAA23595; Tue, 11 Nov 1997 00:50:23 -0500 (EST) Message-Id: <199711110550.AAA23595@brookfield.ans.net> To: "Hannes R. Boehm" cc: idr@merit.edu Reply-To: curtis@ans.net Subject: Re: Filtering on IBGP-Sessions ? In-reply-to: Your message of "Mon, 10 Nov 1997 13:26:02 +0100." <19971110132602.08109@boehm.org> Date: Tue, 11 Nov 1997 00:50:23 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk > I wonder wether it is possible (recommended) or not to filter on IBGP A *Real Bad Idea* (sm). If you have inconsistent routing within you IBGP mesh you can get route loops. Curtis From owner-idr@merit.edu Thu Nov 20 22:31:46 1997 Delivery-Date: Thu, 20 Nov 1997 22:31:46 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA04807 for ; Thu, 20 Nov 1997 22:31:45 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA19521 for ; Thu, 20 Nov 1997 22:34:44 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA25496 for idr-outgoing; Thu, 20 Nov 1997 21:54:07 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by merit.edu (8.8.7/8.8.5) with SMTP id VAA25489 for ; Thu, 20 Nov 1997 21:54:01 -0500 (EST) Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Nov 20 21:52:56 EST 1997 Received: from dnrc.bell-labs.com (prz-laptop.dnrc.bell-labs.com [135.180.130.120]) by couch.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id VAA26025; Thu, 20 Nov 1997 21:52:55 -0500 (EST) Message-ID: <347ED9F1.C7FD00C7@dnrc.bell-labs.com> Date: Fri, 28 Nov 1997 09:49:21 -0500 From: Antoni Przygienda Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: internet-drafts@ns.ietf.org CC: idr@merit.edu Subject: [Fwd: new draft BGP-4 over ATM and Proxy PAR] Content-Type: multipart/mixed; boundary="------------56AA7FF1EEE82EE6BBFA66D1" Sender: owner-idr@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------56AA7FF1EEE82EE6BBFA66D1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------56AA7FF1EEE82EE6BBFA66D1 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <347356FA.A676CFE4@dnrc.bell-labs.com> Date: Wed, 19 Nov 1997 16:15:38 -0500 From: Antoni Przygienda Organization: Bell Labs, Lucent Technologies X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: "internet-drafts@ietf.org" Subject: new draft BGP-4 over ATM and Proxy PAR Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit new draft draft-przygienda-bgp4-atm-00.txt thank you for processing. --- tony Internet Engineering Task Force T. Przygienda INTERNET DRAFT Bell Labs, Lucent Technologies 19 November 1997 BGP-4 over ATM and Proxy PAR Status of This Memo This document is an Internet Draft, and can be found as draft-przygienda-bgp4-atm-00.txt in any standard internet drafts repository. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract This draft specifes for BGP-4 implementors and users mechanisms describing how the protocol operates in ATM networks over PVC and SVC meshes with the presence of Proxy PAR. These recommendations do not require any protocol changes and allow for simpler, more efficient and cost-effective network designs. Proxy PAR can help to distribute changes of peer relationships when BGP-4 capable routers are reconfigured on the ATM cloud. Przygienda Expires 25 May 1998 [Page 1] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 1. Introduction 1.1. Introduction to Proxy PAR Proxy PAR [CPS96, PD97a] is an extension allowing for different ATM attached devices to interact with PAR capable switches and obtain information about non-ATM services without executing PAR [Ca96] which is an extension of PNNI [AF96b] themselves. The client side is much simpler in terms of implementation complexity and memory requirements than a complete PAR protocol stack and should allow for easy implementation in e.g. existing IP routers. Additionally, clients can use Proxy PAR to register different non-ATM services and protocols they support. Proxy PAR has consciously not been included as part of ILMI due to the complexity of PAR information passed in the protocol and the fact that it is intended for integration of non-ATM protocols and services only. A device executing Proxy PAR does not necessarily need to execute ILMI or UNI signaling although this normally will be the case. The context or reference model is aligned with the one included in ILMI [AF96a]. The protocol in itself does not specify how the distributed service registration and data delivered to the client is supposed to be driving other protocols so e.g. OSPF routers finding themselves through proxy PAR could use this information in RFC1577 [Lau94] fashion, forming a full mesh of point-to-point connections to interact with each other to simulate broadcast interfaces. For the same purpose LANE [AF95] or MARS [Arm96] could be used. As a by-product, Proxy PAR could provide the ATM address resolution for IP attached devices but such resolution can be achieved by other protocols under specification in IETF as well, e.g. [CH97a, CH97b]. And last but not least, it should be mentioned here that the protocol coexists with and complements the ongoing work in IETF on server detection via ILMI extensions [Dav97] and opaque LSAs [CH97a, CH97b]. 1.1.1. Proxy PAR Scopes Any Proxy PAR registration is carried only within a defined scope that is set during registration and is equivalent to the PNNI routing level. Since no assumptions except scope values can be made about the information distributed (e.g. IP addresses bound to NSAPs are not assumed to be aligned with them in any respect such as Przygienda Expires 25 May 1998 [Page 2] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 encapsulation or functional mapping), registration information cannot be summarized. This makes a careful handling of scopes necessary to preserve the scalability. More detailed comments on these issues and optimizations possible when logical IP topology aligns with aspects of ATM topology can be found in [PD97b]. 1.2. Introduction to BGP Border Gateway Protocol (BGP) is an Exterior Gateway Protocol (EGP) and described in [RL95, RL97] from which most of the following paragraphs have been taken almost literally. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP runs over a reliable transport protocol. This eliminates the need to implement explicit update fragmentation, retransmission, acknowledgment, and sequencing. Any authentication scheme used by the transport protocol may be used in addition to BGP's own authentication mechanisms. The error notification mechanism used in BGP assumes that the transport protocol supports a "graceful" close, i.e., that all outstanding data will be delivered before the connection is closed. BGP deployments are normally configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed. The alternative supported in Proxy PAR are route reflectors [Bat96] due to their simplicity, easy migration and compatibility with existing BGP configurations. Przygienda Expires 25 May 1998 [Page 3] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 2. BGP over ATM 2.1. Model The model used for BGP operation over ATM in connection with Proxy PAR assumes that not only pre-configured peers exist but neighbor relationships can be formed dynamically based on discovery mechanisms. Such a discovery must be provided by an underlying layer since BGP does not include peer auto-detection that would be comparable with e.g. OSPF's hellos used to find all OSPF routers on a specific subnet. To fulfill this purpose, Proxy PAR allows BGP to register and query the following data with the server: - ATM address - IP instance - IP address - IP mask - BGP Identifier - route reflector type as one of: * reflector of a certain cluster or * client of a certain cluster or * non-client The motivation of such a model is to allow for a simpler maintainance of BGP router configuration when some router interfaces are connected over ATM. As an example, full mesh connectivity on a specific subnet does not require the configuration of peer relationsships in routersa priori but a router can register as providing BGP services on an interface and his possible peers discover it through Proxy PAR queries. Figure 1 illustrates a possible BGP scenario with several cases of relationsships based on the following Proxy PAR registrations: - Router R1 is configured to be BGP capable and has the interface * 1.1.1.1 reaching into DMZ subnet 1.1.1/255.255.255 Przygienda Expires 25 May 1998 [Page 4] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 +--+ |R1| +--+ 1.1.1.1 | register BGP for | AS101, BGP Id 1.1.1.1, no route | reflector | ======================= | ========================== AS101 1.1.1/255.255.255.0 | +--------------+---------+-------------+------+ DMZ | | ============= | ===================== | ============ AS100 | | | 1.1.1.3 | 1.1.1.2 | | +--+ +--+ |R2| registers BGP for |R3| registers BGP for | | AS100, Id 1.1.1.3, | | AS100, Id 1.1.1.2, +--+ non-client +--+ RR for cluster 4 | | | 1.1.2.3 | 1.1.2.2 | | +---+----------+-----------------------+-----------+ | 1.1.2/255.255.255.0 | | 1.1.2.1 + +--+ | |R4|-----------+ +--+ 1.1.3.1 | 1.1.3.2 +--+ registers BGP for AS100, +-----------|R5| Id 1.1.2.1, | +--+ RR client cluster 4 + Figure 1: Logical IP Topology with Proxy PAR Registrations (Single ATM network) - Router R3 is configured to be BGP capable, is route reflector for cluster id 4, and has the interfaces * 1.1.1.2 reaching into DMZ subnet 1.1.1/255.255.255 and * 1.1.2.2 to the subnet 1.1.2/255.255.255 inside its AS Przygienda Expires 25 May 1998 [Page 5] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 - Router R2 is configured to be BGP capable and has the interfaces * 1.1.1.3 reaching into DMZ subnet 1.1.1/255.255.255 and * 1.1.2.3 to the subnet 1.1.2/255.255.255 inside its AS - Router R5 is configured to be BGP capable, is a client of route reflector cluster id 4, and has the interface * 1.1.2.1 to a subnet 1.1.2/255.255.255 inside its AS It has to be stated here that the model assumes that E-BGP-multihop will not be supported through auto-configuration. Based on such an assumption, the following queries are generated by the routers and conclusions drawn concerning the BGP sessions to be formed: Q1> Router R1 queries for all BGP capable routers on the DMZ subnet (1) and discovers R2 and R3 supporting interfaces 1.1.1.3 and 1.1.1.2 and being in a different AS. Router R1 concludes to * build a E-BGP connection to router R3 (shown with &'s in Figure 2) * build a EBPG connection to router R2 (shown with #'s in Figure 2) Q2> Router R2 queries for all BGP capable routers on the DMZ subnet and discovers R3 and R1 on the same subnet and concludes to * build a E-BGP connection to router R1 since it is in a different AS * not to build a E-BGP connection to router R3 since it is in the same AS Q3> Router R3 issues a symmetric query to Q2 and comes to conclusions analogous to Q2> Q4> Router R2 queries for all routers supporting BGP inside of the same AS, detects R3 and R5 and concludes to ___________________________________________ 1. since one of its interfaces is on this subnet Przygienda Expires 25 May 1998 [Page 6] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 +--+ |R1| +--+ 1.1.1.1 #& #& #& #& ======================= #& ========================= AS101 #& +--------------###########&&&&&&&&&&&&&&------+ DMZ # & ============= # ===================== & ============ AS100 # & # 1.1.1.3 & 1.1.1.2 # & +--+ +--+ |R2| |R3| | | | | +--+ +--+ % %@ % 1.1.2.3 %@ 1.1.2.2 % %@ % %@ +--------------%%%%%%%%%%%%%%%%%%%%%%%%%@----------+ @@@@@@@@@@@@@@@@@@@@@@@@@@ @ @ + +-@@ | |R4@@@@@@@@@@@@@ +--+ @ 1.1.3.2 +--+ @@@@@@@@@@@@|R5| + +--+ Figure 2: Active BGP Connections after Auto-Discovery in Figure 1. * build an I-BGP connection to R3 since R3 is a reflector and R2 is a non-client (shown with %'s in Figure 2) * not build an I-BGP connection to R5 since R5 is a client of a route reflector Przygienda Expires 25 May 1998 [Page 7] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 Q5> Router R3 queries for all routers supporting BGP inside of the same AS, detects R2 and R5 and concludes to * build an I-BGP connection to R2 since R3 is a reflector and R2 is a non-client * build an I-BGP connection to R5 since R5 is a client of the route reflector for the same cluster (shown with @'s in Figure 2) Q6> Router R5 queries for all routers supporting BGP inside of the same AS, detects R2 and R3 and concludes to * not build an I-BGP connection to R2 since R5 is a reflector client and R2 is a non-client * to build an I-BGP connection to R3 since R3 is the reflector for the same cluster R5 is client of The resulting peerings are visualized in Figure 2. Based on the configuration of BGP properties the network automatically set up valid and necessary connections between routers. It should be obvious that especially for I-BGP such a mechanism faciliates the maintainance of many routers inside of an AS. The necessary route reflector and mesh connections for BGP are built correctly. A carefull reader observes as well that the automatically formed full set of E-BGP connections between AS border routers is not always a good thing. This problem will be given some special consideration. The intended auto-configuration behavior when registering and retrieving information can be split across the internal and external BGP functionality boundary. Since I-BGP requires a full mesh configuration (2) Proxy PAR information proves very beneficial to meet this necessary constraint in an automatic manner. For E-BGP, as mentioned above, a full mesh between all peers on the same subnet is not always a good solution and therefore Proxy PAR information has to be treated more carefully or not used at all. ___________________________________________ 2. with exceptions in presence of route reflectors, of course Przygienda Expires 25 May 1998 [Page 8] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 2.2. BGP Configuration Interaction with Proxy PAR To resolve problems with multiple IP subnets operating on top of a single ATM NSAP, multiple BGP instances, and possibly even multiple ATM clouds the router attaches to, router configuration has to define what information is feasible to be registered. As default, any new upcoming IP interface running on top of an ATM link should be registered with the server on one of the ATM links interfacing with the same ATM cloud. The necessary IP instance is determined by the BGP instance and the NSAP is equivalent to the NSAP of the ATM interface through which the registration is performed. 2.2.1. Registration of Information for Autoconfiguration of External BGP Peerings An implicit assumption when using Proxy PAR for autoconfiguration of BGP external peerings is that multihop peers are not supported. A BGP router with an IP over ATM interface that attaches to a subnet between different AS'es registers the interface for the according IP instance with one of the proxy PAR servers on the same cloud. It is possible, although not necessary, to omit multiple registrations in the case of a BGP router having multiple interfaces to the same IP subnet with broadcast capabilities. 2.2.2. Registration of Information for Autoconfiguration of Internal BGP Peerings For the IP over ATM interfaces on subnets being entirely inside of the router's AS, BGP instances should register with proxy PAR server. This allows for necessary sessions to be formed and consecutively provides full mesh connectivity between non-clients, and star connectivity inside route reflector clusters. Same optimizations as described in section 2.2.1 are possible. 2.3. Proxy PAR Interaction with BGP Configuration 2.3.1. Autoconfiguration of Internal BGP Peerings Proxy PAR presence in a BGP network 'on the internal side' is helping to meet the requirement that all I-BGP peers have to be connected as full-mesh or connect to their route reflectors. To make sure that Przygienda Expires 25 May 1998 [Page 9] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 all route reflector clients and non-clients are configured correctly, Proxy PAR queries will present enough information to let the routers configure a minimal valid connectivity graph. After being provided with the information about all BGP peers running in the same AS, a BGP router determines which peers it must initiate connections to based on the following criteria: - looking at the other router's BGP identifier no session has been formed yet and - the other router is in the same AS and * one router is route reflector with the same cluster ID and the other router is a client of this cluster or * one of the routers is a non-client The example in section 2.1 encompasses the different cases that can trigger initiation of connections. 2.3.2. Autoconfiguration of external BGP peerings Proxy PAR registration information made available can be used to determine which BGP routers are present to form sessions with. Normally, all routers on a specific DMZ subnet are interested in forming relationships with routers in different ASes to exchange route information. However, to prevent unnecessary or insecure external sessions, each of the IP interfaces on a subnet reaching into other AS'es can filter information from query results based on any of the fields or combinations thereof. The filter would prevent BGP from autodetecting the registration and effectively the possible neighbor. Since the connection could be initiated from either side, the filters should be symmetrical in both BGP peers that try to prevent that session from forming. If this is unenforcable, a peer accepting an E-BGP connection for which Proxy PAR information is filtered, could explicitly close it after providing appropriate notification. 2.4. IP to ATM Address Resolution Given the nature of Proxy PAR registrations that contain not only BGP specific information but always carry IP interface address and Przygienda Expires 25 May 1998 [Page 10] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 the attached NSAP, when running BGP over IP interfaces on top of ATM with Proxy PAR capabilities, the information obtained in queries can be used to provide address resolution for the lower layers. When BGP chooses to initiate a connection to a peer, lower layers of the TCP/IP protocol stack could use the available Proxy PAR information to resolve the IP address into the necessary NSAP of the registration point. Such a solution however necessitates an appropriate stack architecture. 3. Acknowledgments Comments and contributions from several sources, especially Rob Coltun are included in this work. 4. Security Consideration Security issues in the context of BGP autoconfiguration in presence of Proxy PAR can be split into parts specific to either of the protocols. BGP protocol addresses the issues in existing RFCs and ongoing work. PNNI protocol in version 2 contains peer authentication mechanisms and Proxy PAR in itself could be extended to encompass the same security features in the future. To address the problem of security of Proxy PAR client/server interactions, especially registrations that could be used for denial-of-service attacks is an issue not addressed so far. Its scope is similar to the problem of a secure ILMI [AF96a]. 5. Conclusions This RFC specifes for BGP implementors and users mechanisms describing how the protocol operates in ATM networks over PVC and SVC meshes with the presence of Proxy PAR. These recommendations do not require any protocol changes and allow for simpler, more efficient and cost- effective network designs. Proxy PAR can help to distribute configuration changes when BGP capable routers are reconfigured on the ATM cloud and greatly facilitates consistence of I-BGP meshes and can be used for E-BGP auto-configuration as well. Przygienda Expires 25 May 1998 [Page 11] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 References [AF95] ATM-Forum. LAN Emulation over ATM 1.0. ATM Forum af-lane-0021.000, January 1995. [AF96a] ATM-Forum. Interim Local Management Interface (ILMI) Specification 4.0. ATM Forum 95-0417R8, June 1996. [AF96b] ATM-Forum. Private Network-Network Interface Specification Version 1.0. ATM Forum af-pnni-0055.000, March 1996. [Arm96] G. Armitage. Support for Multicast over UNI 3.0/3.1 based ATM Networks, RFC 2022. Internet Engineering Task Force, November 1996. [Bat96] T. Bates. BGP Route Reflection, RFC 1966. Internet Engineering Task Force, June 1996. [Ca96] R. Callon and al. An Overview of PNNI Augmented Routing. ATM Forum 96-0354, April 1996. [CH97a] R. Coltun and J. Heinanen. Opaque LSA in OSPF. Internet Draft, 1997. [CH97b] R. Coltun and J. Heinanen. The OSPF Address Resolution Advertisement Option. Internet Draft, 1997. [CPS96] R. Coltun, T. Przygienda, and S. Shew. MIPAR: Minimal PNNI Augmented Routing. ATM Forum 96-0838, June 1996. [Dav97] M. Davison. Simple ILMI-Based Server Discovery. Internet Draft, 1997. [Lau94] M. Laubach. Classical IP and ARP over ATM, RFC 1577. Internet Engineering Task Force, January 1994. [PD97a] T. Przygienda and P. Droz. Proxy PAR. ATM Forum 97-0495, 97-0705, 97-0882, July 1997. [PD97b] T. Przygienda and P. Droz. Proxy PAR. Internet Draft, 1997. [RL95] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4), RFC 1771. Internet Engineering Task Force, March 1995. Przygienda Expires 25 May 1998 [Page 12] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 [RL97] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). Internet Draft, 1997. Authors' Addresses Tony Przygienda Bell Labs, Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733-3030 prz@dnrc.bell-labs.com Przygienda Expires 25 May 1998 [Page 13] --------------56AA7FF1EEE82EE6BBFA66D1-- From owner-idr@merit.edu Thu Nov 20 22:36:04 1997 Delivery-Date: Thu, 20 Nov 1997 22:36:04 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA04823 for ; Thu, 20 Nov 1997 22:36:03 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA19533 for ; Thu, 20 Nov 1997 22:39:02 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA25350 for idr-outgoing; Thu, 20 Nov 1997 21:48:16 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by merit.edu (8.8.7/8.8.5) with SMTP id VAA25338 for ; Thu, 20 Nov 1997 21:48:04 -0500 (EST) Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Nov 20 21:47:26 EST 1997 Received: from dnrc.bell-labs.com (prz-laptop.dnrc.bell-labs.com [135.180.130.120]) by couch.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id VAA25976; Thu, 20 Nov 1997 21:47:26 -0500 (EST) Message-ID: <347ED8A7.EA9848B2@dnrc.bell-labs.com> Date: Fri, 28 Nov 1997 09:43:51 -0500 From: Antoni Przygienda Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: internet-drafs@ns.ietf.org CC: idr@merit.edu Subject: [Fwd: new draft BGP-4 over ATM and Proxy PAR] Content-Type: multipart/mixed; boundary="------------050E607B595E026A23014C2D" Sender: owner-idr@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------050E607B595E026A23014C2D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------050E607B595E026A23014C2D Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <347356FA.A676CFE4@dnrc.bell-labs.com> Date: Wed, 19 Nov 1997 16:15:38 -0500 From: Antoni Przygienda Organization: Bell Labs, Lucent Technologies X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: "internet-drafts@ietf.org" Subject: new draft BGP-4 over ATM and Proxy PAR Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit new draft draft-przygienda-bgp4-atm-00.txt thank you for processing. --- tony Internet Engineering Task Force T. Przygienda INTERNET DRAFT Bell Labs, Lucent Technologies 19 November 1997 BGP-4 over ATM and Proxy PAR Status of This Memo This document is an Internet Draft, and can be found as draft-przygienda-bgp4-atm-00.txt in any standard internet drafts repository. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract This draft specifes for BGP-4 implementors and users mechanisms describing how the protocol operates in ATM networks over PVC and SVC meshes with the presence of Proxy PAR. These recommendations do not require any protocol changes and allow for simpler, more efficient and cost-effective network designs. Proxy PAR can help to distribute changes of peer relationships when BGP-4 capable routers are reconfigured on the ATM cloud. Przygienda Expires 25 May 1998 [Page 1] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 1. Introduction 1.1. Introduction to Proxy PAR Proxy PAR [CPS96, PD97a] is an extension allowing for different ATM attached devices to interact with PAR capable switches and obtain information about non-ATM services without executing PAR [Ca96] which is an extension of PNNI [AF96b] themselves. The client side is much simpler in terms of implementation complexity and memory requirements than a complete PAR protocol stack and should allow for easy implementation in e.g. existing IP routers. Additionally, clients can use Proxy PAR to register different non-ATM services and protocols they support. Proxy PAR has consciously not been included as part of ILMI due to the complexity of PAR information passed in the protocol and the fact that it is intended for integration of non-ATM protocols and services only. A device executing Proxy PAR does not necessarily need to execute ILMI or UNI signaling although this normally will be the case. The context or reference model is aligned with the one included in ILMI [AF96a]. The protocol in itself does not specify how the distributed service registration and data delivered to the client is supposed to be driving other protocols so e.g. OSPF routers finding themselves through proxy PAR could use this information in RFC1577 [Lau94] fashion, forming a full mesh of point-to-point connections to interact with each other to simulate broadcast interfaces. For the same purpose LANE [AF95] or MARS [Arm96] could be used. As a by-product, Proxy PAR could provide the ATM address resolution for IP attached devices but such resolution can be achieved by other protocols under specification in IETF as well, e.g. [CH97a, CH97b]. And last but not least, it should be mentioned here that the protocol coexists with and complements the ongoing work in IETF on server detection via ILMI extensions [Dav97] and opaque LSAs [CH97a, CH97b]. 1.1.1. Proxy PAR Scopes Any Proxy PAR registration is carried only within a defined scope that is set during registration and is equivalent to the PNNI routing level. Since no assumptions except scope values can be made about the information distributed (e.g. IP addresses bound to NSAPs are not assumed to be aligned with them in any respect such as Przygienda Expires 25 May 1998 [Page 2] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 encapsulation or functional mapping), registration information cannot be summarized. This makes a careful handling of scopes necessary to preserve the scalability. More detailed comments on these issues and optimizations possible when logical IP topology aligns with aspects of ATM topology can be found in [PD97b]. 1.2. Introduction to BGP Border Gateway Protocol (BGP) is an Exterior Gateway Protocol (EGP) and described in [RL95, RL97] from which most of the following paragraphs have been taken almost literally. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASs) that reachability information traverses. This information is sufficient to construct a graph of AS connectivity from which routing loops may be pruned and some policy decisions at the AS level may be enforced. BGP runs over a reliable transport protocol. This eliminates the need to implement explicit update fragmentation, retransmission, acknowledgment, and sequencing. Any authentication scheme used by the transport protocol may be used in addition to BGP's own authentication mechanisms. The error notification mechanism used in BGP assumes that the transport protocol supports a "graceful" close, i.e., that all outstanding data will be delivered before the connection is closed. BGP deployments are normally configured such that that all BGP speakers within a single AS must be fully meshed so that any external routing information must be re-distributed to all other routers within that AS. This represents a serious scaling problem that has been well documented with several alternatives proposed. The alternative supported in Proxy PAR are route reflectors [Bat96] due to their simplicity, easy migration and compatibility with existing BGP configurations. Przygienda Expires 25 May 1998 [Page 3] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 2. BGP over ATM 2.1. Model The model used for BGP operation over ATM in connection with Proxy PAR assumes that not only pre-configured peers exist but neighbor relationships can be formed dynamically based on discovery mechanisms. Such a discovery must be provided by an underlying layer since BGP does not include peer auto-detection that would be comparable with e.g. OSPF's hellos used to find all OSPF routers on a specific subnet. To fulfill this purpose, Proxy PAR allows BGP to register and query the following data with the server: - ATM address - IP instance - IP address - IP mask - BGP Identifier - route reflector type as one of: * reflector of a certain cluster or * client of a certain cluster or * non-client The motivation of such a model is to allow for a simpler maintainance of BGP router configuration when some router interfaces are connected over ATM. As an example, full mesh connectivity on a specific subnet does not require the configuration of peer relationsships in routersa priori but a router can register as providing BGP services on an interface and his possible peers discover it through Proxy PAR queries. Figure 1 illustrates a possible BGP scenario with several cases of relationsships based on the following Proxy PAR registrations: - Router R1 is configured to be BGP capable and has the interface * 1.1.1.1 reaching into DMZ subnet 1.1.1/255.255.255 Przygienda Expires 25 May 1998 [Page 4] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 +--+ |R1| +--+ 1.1.1.1 | register BGP for | AS101, BGP Id 1.1.1.1, no route | reflector | ======================= | ========================== AS101 1.1.1/255.255.255.0 | +--------------+---------+-------------+------+ DMZ | | ============= | ===================== | ============ AS100 | | | 1.1.1.3 | 1.1.1.2 | | +--+ +--+ |R2| registers BGP for |R3| registers BGP for | | AS100, Id 1.1.1.3, | | AS100, Id 1.1.1.2, +--+ non-client +--+ RR for cluster 4 | | | 1.1.2.3 | 1.1.2.2 | | +---+----------+-----------------------+-----------+ | 1.1.2/255.255.255.0 | | 1.1.2.1 + +--+ | |R4|-----------+ +--+ 1.1.3.1 | 1.1.3.2 +--+ registers BGP for AS100, +-----------|R5| Id 1.1.2.1, | +--+ RR client cluster 4 + Figure 1: Logical IP Topology with Proxy PAR Registrations (Single ATM network) - Router R3 is configured to be BGP capable, is route reflector for cluster id 4, and has the interfaces * 1.1.1.2 reaching into DMZ subnet 1.1.1/255.255.255 and * 1.1.2.2 to the subnet 1.1.2/255.255.255 inside its AS Przygienda Expires 25 May 1998 [Page 5] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 - Router R2 is configured to be BGP capable and has the interfaces * 1.1.1.3 reaching into DMZ subnet 1.1.1/255.255.255 and * 1.1.2.3 to the subnet 1.1.2/255.255.255 inside its AS - Router R5 is configured to be BGP capable, is a client of route reflector cluster id 4, and has the interface * 1.1.2.1 to a subnet 1.1.2/255.255.255 inside its AS It has to be stated here that the model assumes that E-BGP-multihop will not be supported through auto-configuration. Based on such an assumption, the following queries are generated by the routers and conclusions drawn concerning the BGP sessions to be formed: Q1> Router R1 queries for all BGP capable routers on the DMZ subnet (1) and discovers R2 and R3 supporting interfaces 1.1.1.3 and 1.1.1.2 and being in a different AS. Router R1 concludes to * build a E-BGP connection to router R3 (shown with &'s in Figure 2) * build a EBPG connection to router R2 (shown with #'s in Figure 2) Q2> Router R2 queries for all BGP capable routers on the DMZ subnet and discovers R3 and R1 on the same subnet and concludes to * build a E-BGP connection to router R1 since it is in a different AS * not to build a E-BGP connection to router R3 since it is in the same AS Q3> Router R3 issues a symmetric query to Q2 and comes to conclusions analogous to Q2> Q4> Router R2 queries for all routers supporting BGP inside of the same AS, detects R3 and R5 and concludes to ___________________________________________ 1. since one of its interfaces is on this subnet Przygienda Expires 25 May 1998 [Page 6] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 +--+ |R1| +--+ 1.1.1.1 #& #& #& #& ======================= #& ========================= AS101 #& +--------------###########&&&&&&&&&&&&&&------+ DMZ # & ============= # ===================== & ============ AS100 # & # 1.1.1.3 & 1.1.1.2 # & +--+ +--+ |R2| |R3| | | | | +--+ +--+ % %@ % 1.1.2.3 %@ 1.1.2.2 % %@ % %@ +--------------%%%%%%%%%%%%%%%%%%%%%%%%%@----------+ @@@@@@@@@@@@@@@@@@@@@@@@@@ @ @ + +-@@ | |R4@@@@@@@@@@@@@ +--+ @ 1.1.3.2 +--+ @@@@@@@@@@@@|R5| + +--+ Figure 2: Active BGP Connections after Auto-Discovery in Figure 1. * build an I-BGP connection to R3 since R3 is a reflector and R2 is a non-client (shown with %'s in Figure 2) * not build an I-BGP connection to R5 since R5 is a client of a route reflector Przygienda Expires 25 May 1998 [Page 7] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 Q5> Router R3 queries for all routers supporting BGP inside of the same AS, detects R2 and R5 and concludes to * build an I-BGP connection to R2 since R3 is a reflector and R2 is a non-client * build an I-BGP connection to R5 since R5 is a client of the route reflector for the same cluster (shown with @'s in Figure 2) Q6> Router R5 queries for all routers supporting BGP inside of the same AS, detects R2 and R3 and concludes to * not build an I-BGP connection to R2 since R5 is a reflector client and R2 is a non-client * to build an I-BGP connection to R3 since R3 is the reflector for the same cluster R5 is client of The resulting peerings are visualized in Figure 2. Based on the configuration of BGP properties the network automatically set up valid and necessary connections between routers. It should be obvious that especially for I-BGP such a mechanism faciliates the maintainance of many routers inside of an AS. The necessary route reflector and mesh connections for BGP are built correctly. A carefull reader observes as well that the automatically formed full set of E-BGP connections between AS border routers is not always a good thing. This problem will be given some special consideration. The intended auto-configuration behavior when registering and retrieving information can be split across the internal and external BGP functionality boundary. Since I-BGP requires a full mesh configuration (2) Proxy PAR information proves very beneficial to meet this necessary constraint in an automatic manner. For E-BGP, as mentioned above, a full mesh between all peers on the same subnet is not always a good solution and therefore Proxy PAR information has to be treated more carefully or not used at all. ___________________________________________ 2. with exceptions in presence of route reflectors, of course Przygienda Expires 25 May 1998 [Page 8] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 2.2. BGP Configuration Interaction with Proxy PAR To resolve problems with multiple IP subnets operating on top of a single ATM NSAP, multiple BGP instances, and possibly even multiple ATM clouds the router attaches to, router configuration has to define what information is feasible to be registered. As default, any new upcoming IP interface running on top of an ATM link should be registered with the server on one of the ATM links interfacing with the same ATM cloud. The necessary IP instance is determined by the BGP instance and the NSAP is equivalent to the NSAP of the ATM interface through which the registration is performed. 2.2.1. Registration of Information for Autoconfiguration of External BGP Peerings An implicit assumption when using Proxy PAR for autoconfiguration of BGP external peerings is that multihop peers are not supported. A BGP router with an IP over ATM interface that attaches to a subnet between different AS'es registers the interface for the according IP instance with one of the proxy PAR servers on the same cloud. It is possible, although not necessary, to omit multiple registrations in the case of a BGP router having multiple interfaces to the same IP subnet with broadcast capabilities. 2.2.2. Registration of Information for Autoconfiguration of Internal BGP Peerings For the IP over ATM interfaces on subnets being entirely inside of the router's AS, BGP instances should register with proxy PAR server. This allows for necessary sessions to be formed and consecutively provides full mesh connectivity between non-clients, and star connectivity inside route reflector clusters. Same optimizations as described in section 2.2.1 are possible. 2.3. Proxy PAR Interaction with BGP Configuration 2.3.1. Autoconfiguration of Internal BGP Peerings Proxy PAR presence in a BGP network 'on the internal side' is helping to meet the requirement that all I-BGP peers have to be connected as full-mesh or connect to their route reflectors. To make sure that Przygienda Expires 25 May 1998 [Page 9] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 all route reflector clients and non-clients are configured correctly, Proxy PAR queries will present enough information to let the routers configure a minimal valid connectivity graph. After being provided with the information about all BGP peers running in the same AS, a BGP router determines which peers it must initiate connections to based on the following criteria: - looking at the other router's BGP identifier no session has been formed yet and - the other router is in the same AS and * one router is route reflector with the same cluster ID and the other router is a client of this cluster or * one of the routers is a non-client The example in section 2.1 encompasses the different cases that can trigger initiation of connections. 2.3.2. Autoconfiguration of external BGP peerings Proxy PAR registration information made available can be used to determine which BGP routers are present to form sessions with. Normally, all routers on a specific DMZ subnet are interested in forming relationships with routers in different ASes to exchange route information. However, to prevent unnecessary or insecure external sessions, each of the IP interfaces on a subnet reaching into other AS'es can filter information from query results based on any of the fields or combinations thereof. The filter would prevent BGP from autodetecting the registration and effectively the possible neighbor. Since the connection could be initiated from either side, the filters should be symmetrical in both BGP peers that try to prevent that session from forming. If this is unenforcable, a peer accepting an E-BGP connection for which Proxy PAR information is filtered, could explicitly close it after providing appropriate notification. 2.4. IP to ATM Address Resolution Given the nature of Proxy PAR registrations that contain not only BGP specific information but always carry IP interface address and Przygienda Expires 25 May 1998 [Page 10] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 the attached NSAP, when running BGP over IP interfaces on top of ATM with Proxy PAR capabilities, the information obtained in queries can be used to provide address resolution for the lower layers. When BGP chooses to initiate a connection to a peer, lower layers of the TCP/IP protocol stack could use the available Proxy PAR information to resolve the IP address into the necessary NSAP of the registration point. Such a solution however necessitates an appropriate stack architecture. 3. Acknowledgments Comments and contributions from several sources, especially Rob Coltun are included in this work. 4. Security Consideration Security issues in the context of BGP autoconfiguration in presence of Proxy PAR can be split into parts specific to either of the protocols. BGP protocol addresses the issues in existing RFCs and ongoing work. PNNI protocol in version 2 contains peer authentication mechanisms and Proxy PAR in itself could be extended to encompass the same security features in the future. To address the problem of security of Proxy PAR client/server interactions, especially registrations that could be used for denial-of-service attacks is an issue not addressed so far. Its scope is similar to the problem of a secure ILMI [AF96a]. 5. Conclusions This RFC specifes for BGP implementors and users mechanisms describing how the protocol operates in ATM networks over PVC and SVC meshes with the presence of Proxy PAR. These recommendations do not require any protocol changes and allow for simpler, more efficient and cost- effective network designs. Proxy PAR can help to distribute configuration changes when BGP capable routers are reconfigured on the ATM cloud and greatly facilitates consistence of I-BGP meshes and can be used for E-BGP auto-configuration as well. Przygienda Expires 25 May 1998 [Page 11] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 References [AF95] ATM-Forum. LAN Emulation over ATM 1.0. ATM Forum af-lane-0021.000, January 1995. [AF96a] ATM-Forum. Interim Local Management Interface (ILMI) Specification 4.0. ATM Forum 95-0417R8, June 1996. [AF96b] ATM-Forum. Private Network-Network Interface Specification Version 1.0. ATM Forum af-pnni-0055.000, March 1996. [Arm96] G. Armitage. Support for Multicast over UNI 3.0/3.1 based ATM Networks, RFC 2022. Internet Engineering Task Force, November 1996. [Bat96] T. Bates. BGP Route Reflection, RFC 1966. Internet Engineering Task Force, June 1996. [Ca96] R. Callon and al. An Overview of PNNI Augmented Routing. ATM Forum 96-0354, April 1996. [CH97a] R. Coltun and J. Heinanen. Opaque LSA in OSPF. Internet Draft, 1997. [CH97b] R. Coltun and J. Heinanen. The OSPF Address Resolution Advertisement Option. Internet Draft, 1997. [CPS96] R. Coltun, T. Przygienda, and S. Shew. MIPAR: Minimal PNNI Augmented Routing. ATM Forum 96-0838, June 1996. [Dav97] M. Davison. Simple ILMI-Based Server Discovery. Internet Draft, 1997. [Lau94] M. Laubach. Classical IP and ARP over ATM, RFC 1577. Internet Engineering Task Force, January 1994. [PD97a] T. Przygienda and P. Droz. Proxy PAR. ATM Forum 97-0495, 97-0705, 97-0882, July 1997. [PD97b] T. Przygienda and P. Droz. Proxy PAR. Internet Draft, 1997. [RL95] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4), RFC 1771. Internet Engineering Task Force, March 1995. Przygienda Expires 25 May 1998 [Page 12] Internet Draft BGP-4 over ATM and Proxy PAR 19 November 1997 [RL97] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). Internet Draft, 1997. Authors' Addresses Tony Przygienda Bell Labs, Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733-3030 prz@dnrc.bell-labs.com Przygienda Expires 25 May 1998 [Page 13] --------------050E607B595E026A23014C2D-- From owner-idr@merit.edu Thu Nov 20 22:39:01 1997 Delivery-Date: Thu, 20 Nov 1997 22:39:02 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA04837 for ; Thu, 20 Nov 1997 22:39:01 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA19540 for ; Thu, 20 Nov 1997 22:42:00 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA25348 for idr-outgoing; Thu, 20 Nov 1997 21:48:14 -0500 (EST) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by merit.edu (8.8.7/8.8.5) with SMTP id VAA25333 for ; Thu, 20 Nov 1997 21:48:01 -0500 (EST) Received: from couch.dnrc.bell-labs.com ([135.180.160.30]) by dirty; Thu Nov 20 21:46:38 EST 1997 Received: from dnrc.bell-labs.com (prz-laptop.dnrc.bell-labs.com [135.180.130.120]) by couch.dnrc.bell-labs.com (8.7.5/8.7.3) with ESMTP id VAA25968; Thu, 20 Nov 1997 21:46:37 -0500 (EST) Message-ID: <347ED876.D7AAB6A0@dnrc.bell-labs.com> Date: Fri, 28 Nov 1997 09:43:02 -0500 From: Antoni Przygienda Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: internet-drafts@ns.ietf.org CC: idr@merit.edu Subject: [Fwd: new draft BGP-4 MD5 Authentication] Content-Type: multipart/mixed; boundary="------------521AAEE7A3B2AD860D695146" Sender: owner-idr@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------521AAEE7A3B2AD860D695146 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit --------------521AAEE7A3B2AD860D695146 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <347355DE.AEA30B65@dnrc.bell-labs.com> Date: Wed, 19 Nov 1997 16:10:54 -0500 From: Antoni Przygienda Organization: Bell Labs, Lucent Technologies X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: internet-drafts@ietf.org Subject: new draft BGP-4 MD5 Authentication Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit new draft draft-przygienda-bgp-md5-00.txt or IETF thank you for processing. --- tony Internet Engineering Task Force T. Przygienda INTERNET DRAFT Bell Labs, Lucent Technologies 5 November 1997 BGP-4 MD5 Authentication Status of This Memo This document is an Internet Draft, and can be found as draft-przygienda-bgp-md5-00.txt in any standard internet drafts repository. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract This memo describes MD5 authentication scheme for BGP-4 routing protocol analogous to the one proposed for SNMP Version 2 and RIP-2. The mechanism provides greatly enhanced probability for a system attacked to detect and ignore messages received. A sequence number improves additionally the resistance against replay attacks. 1. Use of Imperatives Throughout this document, the words that are used to define the significance of particular requirements are capitalized. These words are: Przygienda Expires 10 May 1998 [Page 1] Internet Draft BGP-4 MD5 Authentication 5 November 1997 MUST This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification. MUST NOT This phrase means that the item is an absolute prohibition of this specification. SHOULD This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. SHOULD NOT This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. MAY This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. 2. Introduction Recent developments in the Internet has introduced a stronger need for improved authentication of routing information. RIP-2 and OSPF provide originally for unauthenticated service and clear-text password authentication. Both are not sufficient to withstand attacks currently widespread in the Internet. In case of disabled authentication only misconfiguration can be detected and clear password protections can be intercepted easily by an hostile attacker. Recently, both OSPF [Moy97] and RIP-2 [BA97] (1) added additional mechanisms using well-known MD-5 signature algorithms [Riv92] that is considered to be secure and fast enough for protection of routing protocol data units [Tou95]. BGP-4 [RL95, RL97] contains already authentication information marker in the message header that can be used for a MD5 signature. Its fixed length however prevents a more generic approach using keyed ___________________________________________ 1. on which large parts of this document are based Przygienda Expires 10 May 1998 [Page 2] Internet Draft BGP-4 MD5 Authentication 5 November 1997 algorithms generating more than 128 bits long signatures without redefining its meaning. This memo proposes an authentication algorithm, as was originally proposed for SNMP Version 2, augmented by a sequence number. Keyed MD5 is chosen here as the authentication algorithm for BGP-4. This mechanism will provide a greatly enhanced probability that a system being attacked will detect and ignore hostile information. This property derives from the fact that only the output of an authentication algorithm (e.g., Keyed MD5) rather than the secret Authentication Key is transmited. This output is a one-way function of a message and a secret Authentication Key. Again, the Authentication Key is never sent over the network unencrypted, therefore providing protection against passive attacks. Protection against forgery or message modification is inherent to this scheme. A sequence number is provided that makes a replay attack much harder. It is possible to replay a message until the sequence number changes. The mechanism does not provide confidentiality. The messages are not encrypted. Such a protection is provided in other protocols such as PNNIv2 [AF97] or IETF's recent work [Atk95] and could be considered in the future. Keyed MD5 is being used for OSPF cryptographic authentication [Moy97], and is therefore present in routers already, as is some form of password management. 3. Method Description The method requires three issues to be addressed: 1. Changed packet formats, 2. Authentication procedures, and 3. Management controls. 3.1. OPEN Message Extensions The OPEN message in BGP-4 specifies an optional parameter that is specifically reserved for authentication purposes. For MD-5 purposes the authentication code with value 1 MAY be used by an Przygienda Expires 10 May 1998 [Page 3] Internet Draft BGP-4 MD5 Authentication 5 November 1997 implementation. In case this authentication code is used, the OPEN message contains the parameter and it MUST be formatted the following way: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Auth. Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | reserved 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The meaning of fields specified reads as: 1. The "Authentication Code" is Keyed Message Digest Algorithm, indicated by the value 1. All other octets are reserved and MUST be set to 0. 3.2. Message Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth. Type | 0x000000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Data Len | 0x000000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key ID | 0x000000 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The message header format for the OPEN and subsequent UPDATE and KEEPALIVE messages MUST have the marker formatted in the following way: Przygienda Expires 10 May 1998 [Page 4] Internet Draft BGP-4 MD5 Authentication 5 November 1997 1. The "Authentication Type" is Keyed Message Digest Algorithm, indicated by the value 1. 2. An unsigned 8-bit field that contains the length in octets of the trailing Authentication Data field. The presence of this field permits other algorithms (e.g., Keyed SHA) to be substituted for Keyed MD5 if desired. 3. An unsigned 32 bit sequence number. The sequence number MUST be non-decreasing for all messages sent with the same Key ID. 4. An unsigned 8-bit field that contains the Key Identifier or Key-ID. This identifies the key used to create the Authentication Data for this BGP-4 message. In implementations supporting more than one authentication algorithm, the Key-ID also indicates the authentication algorithm in use for this message. A key is associated with a session. The trailer consists of the Authentication Data, which is the output of the Keyed Message Digest Algorithm. When the Authentication Algorithm is Keyed MD5, the output data is 16 bytes; during digest calculation, this is effectively followed by a pad field and a length field as defined by [Riv92]. 3.3. UPDATE and KEEPALIVE Message Trailer The OPEN and all subsequent UPDATE and KEEPALIVE messages MUST be trailed after length padded to 32-bit boundary with the indicated length of authentication data. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BGP Header + ............... | BGP Data + ............... | Padding to 32-bit boundary with reserved 0 octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 0xFFFF | 0x0001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Authentication Data (var. length; 16 bytes with Keyed MD5) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Przygienda Expires 10 May 1998 [Page 5] Internet Draft BGP-4 MD5 Authentication 5 November 1997 In memory, the following trailer is appended by the MD5 algorithm and treated as though it were part of the message. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sixteen octets of MD5 "secret" | / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more pad bytes (defined by RFC 1321 when MD5 is used) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64 bit message length MSW | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 64 bit message length LSW | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.4. Message Generation The BGP-4 packet is created as usual, except that the marker is set to contain the authentication type (1), the authentication data length, the sequence number and the Key Identifier. The value used in the sequence number is arbitrary, but two suggestions are the time of the message's creation or a simple message counter. The BGP-4 Authentication Key is selected by the sender based on the session. Each key has a lifetime associated with it. No key is ever used outside its lifetime. 1. The BGP-4 header's packet length field indicates the standard BGP-4 portion of the packet. 2. The Authentication Data Offset, Key Identifier, and Authentication Data size fields are filled in appropriately. 3. The BGP-4 Authentication Key, which is 16 bytes long when the Keyed MD5 algorithm is used, is now appended to the data. For all algorithms, the BGP-4 Authentication Key is never longer than the output of the algorithm in use. Przygienda Expires 10 May 1998 [Page 6] Internet Draft BGP-4 MD5 Authentication 5 November 1997 4. Trailing pad and length fields are added and the digest calculated using the indicated algorithm. When Keyed MD5 is the algorithm in use, these are calculated per [Riv92]. 5. The digest is written over the BGP-4 Authentication Key. When MD5 is used, this digest will be 16 bytes long. The trailing pad is not actually transmitted, as it is entirely predictable from the message length and algorithm in use. 3.5. Message Reception When the message is received, the process is reversed: 1. The digest is set aside, 2. The appropriate algorithm and key are determined from the value of the Key Identifier field, 3. The BGP-4 Authentication Key is written into the appropriate number (16 when Keyed MD5 is used) of bytes starting at the offset indicated, 4. Appropriate padding is added as needed, and 5. A new digest calculated using the indicated algorithm. If the calculated digest does not match the received digest, the message is discarded and appropriate Authentication failed NOTIFICATION sent. The connection is closed subsequently. If the sequence number is not zero and smaller than the last received one, the message is discarded and appropriate Authentication failed NOTIFICATION sent. The connection is closed subsequently. A router that has forgotten its current sequence number but remembers its key and Key-ID MUST send its next packet with a sequence number of zero. This leaves a small opening for a replay attack although appropriate procedures can be provided by an implementation to report excessive zero key usage. Router vendors are encouraged to provide stable storage for keys, key lifetimes, Key-IDs, and the related sequence numbers. Przygienda Expires 10 May 1998 [Page 7] Internet Draft BGP-4 MD5 Authentication 5 November 1997 Acceptable messages are now truncated to a BGP-4 message itself and treated normally. 4. New UPDATE Message Error Subcode A new UPDATE Message Error subcode with the value 12 - Authentication Failure MUST be understood by all implementations supporting keyed authentication. 5. Management Procedures 5.1. Key Management Requirements It is strongly desirable that a hypothetical security breach in one Internet protocol not automatically compromise other Internet protocols. The Authentication Key of this specification SHOULD NOT be stored using protocols or algorithms that have known flaws. Implementations MUST support the storage of more than one key at the same time, although it is recognized that only one key will normally be active on a session. They MUST associate a specific lifetime (i.e., date/time first valid and date/time no longer valid) and a key identifier with each key, and MUST support manual key distribution (e.g., the privileged user manually typing in the key, key lifetime, and key identifier on the router console). The lifetime may be infinite. If more than one algorithm is supported, then the implementation MUST require that the algorithm be specified for each key at the time the other key information is entered. Keys that are out of date MAY be deleted at will by the implementation without requiring human intervention. Manual deletion of active keys SHOULD also be supported. It is likely that the IETF will define a standard key management protocol. It is strongly desirable to use that key management protocol to distribute BGP-4 Authentication Keys among communicating BGP-4 implementations. Such a protocol would provide scalability and significantly reduce the human administrative burden. The Key ID can be used as a hook between BGP-4 and such a future protocol. Key management protocols have a long history of subtle flaws that are often discovered long after the protocol was first described in public. To avoid having to change all BGP-4 implementations Przygienda Expires 10 May 1998 [Page 8] Internet Draft BGP-4 MD5 Authentication 5 November 1997 should such a flaw be discovered, integrated key management protocol techniques were deliberately omitted from this specification. 5.2. Key Management Procedures As with all security methods using keys, it is necessary to change the BGP-4 Authentication Key on a regular basis. To maintain routing stability during such changes, implementations MUST be able to store and use more than one BGP-4 Authentication Key for a given session at the same time. Each key will have its own Key Identifier, which is stored locally. The combination of the Key Identifier and the session associated with the message uniquely identifies the Authentication Algorithm and BGP-4 Authentication Key in use. The party creating the BGP-4 message will select a valid key from the set of valid keys for that session. The receiver will use the Key Identifier and session to determine which key to use for authentication of the received message. More than one key may be associated with a session at the same time. Hence it is possible to have fairly smooth BGP-4 Authentication Key rollovers without losing legitimate BGP-4 messages because the stored key is incorrect and without requiring people to change all the keys at once. To ensure a smooth rollover, each communicating BGP-4 system must be updated with the new key several minutes before the current key will expire and several minutes before the new key lifetime begins. The new key should have a lifetime that starts several minutes before the old key expires. This gives time for each system to learn of the new BGP-4 Authentication Key before that key will be used. It also ensures that the new key will begin being used and the current key will go out of use before the current key's lifetime expires. For the duration of the overlap in key lifetimes, a system may receive messages using either key and authenticate the message. The Key-ID in the received message is used to select the appropriate key for authentication. Przygienda Expires 10 May 1998 [Page 9] Internet Draft BGP-4 MD5 Authentication 5 November 1997 5.3. Pathological Cases Two pathological cases exist which must be handled, which are failures of the network manager. Both of these should be exceedingly rare. During key switchover, devices may exist which have not yet been successfully configured with the new key. Therefore, routers SHOULD implement (and would be well advised to implement) an algorithm that detects the set of keys being used by its neighbors, and transmits its messages using both the new and old keys until all of the neighbors are using the new key or the lifetime of the old key expires. Under normal circumstances, this elevated transmission rate will exist for a single update interval. In the event that the last key associated with an session expires, it is unacceptable to revert to an unauthenticated condition, and not advisable to disrupt routing. Therefore, the router should send a "last authentication key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured. 6. Conformance Requirements To conform to this specification, an implementation MUST support all of its aspects. The Keyed MD5 authentication algorithm MUST be implemented by all conforming implementations. MD5 is defined in [Riv92]. A conforming implementation MAY also support other authentication algorithms such as Keyed Secure Hash Algorithm (SHA). Manual key distribution as described above MUST be supported by all conforming implementations. All implementations MUST support the smooth key rollover described under "Key Change Procedures." The user documentation provided with the implementation MUST contain clear instructions on how to ensure that smooth key rollover occurs. Implementations SHOULD support a standard key management protocol for secure distribution of BGP-4 Authentication Keys once such a key management protocol is standardized by the IETF. Przygienda Expires 10 May 1998 [Page 10] Internet Draft BGP-4 MD5 Authentication 5 November 1997 7. Security Consideration This memo describes and specifies an authentication mechanism for the BGP-4 routing protocol that is believed to be secure against active and passive attacks. Users need to understand that the quality of the security provided by this mechanism depends completely on the strength of the implemented authentication algorithms, the strength of the key being used, and the correct implementation of the security mechanism in communicating BGP-4 implementations. This mechanism also depends on the BGP-4 Authentication Key being kept confidential by all parties. If any of these incorrect or insufficiently secure, then no real security will be provided to the users of this mechanism. Specifically with respect to the use of SNMP, compromise of SNMP security has the necessary result that the various BGP-4 configuration parameters (e.g. routing table, BGP-4 Authentication Key) manageable via SNMP could be compromised as well. Changing Authentication Keys using non-encrypted SNMP is no more secure than sending passwords in the clear. Confidentiality is not provided by this mechanism. 8. Acknowledgements Large parts of this memo are based or has been taken over from the RIP-2 MD-5 authentication [BA97]. References [AF97] ATM-Forum. Private Network-Network Interface Specification Version 2.0. ATM Forum, work in progress, 1997. [Atk95] R. Atkinson. IP Encapsulating Security Payload. Internet Engineering Task Force, August 1995. [BA97] F. Baker and R. Atkinson. RIP-2 MD5 Authentication. Internet Engineering Task Force, January 1997. Przygienda Expires 10 May 1998 [Page 11] Internet Draft BGP-4 MD5 Authentication 5 November 1997 [Moy97] J. Moy. OSPFv2, RFC 2178. Internet Engineering Task Force, July 1997. [Riv92] R. Rivest. The MD5 Message-Digest Algorithm, RFC 1321. Internet Engineering Task Force, April 1992. [RL95] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4), RFC 1771. Internet Engineering Task Force, March 1995. [RL97] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4). Internet Draft, 1997. [Tou95] J. Touch. Report on MD5 Performance, RFC 1810. Internet Engineering Task Force, June 1995. Authors' Addresses Tony Przygienda Bell Labs, Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733-3030 prz@dnrc.bell-labs.com Przygienda Expires 10 May 1998 [Page 12] --------------521AAEE7A3B2AD860D695146-- From daemon Mon Nov 24 17:04:02 1997 Delivery-Date: Mon, 24 Nov 1997 17:16:57 -0500 Return-Path: daemon Received: (from daemon@localhost) by ns.ietf.org (8.8.7/8.8.7a) id RAA23089 for ietf-123-outbound.10@ietf.org; Mon, 24 Nov 1997 17:03:15 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA23076; Mon, 24 Nov 1997 17:03:13 -0500 (EST) Message-Id: <199711242203.RAA23076@ns.ietf.org> To: IETF-Announce: ; Cc: idr@merit.edu From: The IESG SUBJECT: Last Call: Multiprotocol Extensions for BGP-4 to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Mon, 24 Nov 1997 17:03:13 -0500 Sender: scoya@cnri.reston.va.us The IESG has received a request from the Inter-Domain Routing Working Group to consider Multiprotocol Extensions for BGP-4 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 2, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-01.txt From owner-idr@merit.edu Mon Nov 24 17:25:28 1997 Delivery-Date: Mon, 24 Nov 1997 17:25:29 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA23604 for ; Mon, 24 Nov 1997 17:25:28 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA04687 for ; Mon, 24 Nov 1997 17:27:06 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA26365 for idr-outgoing; Mon, 24 Nov 1997 16:29:23 -0500 (EST) Received: from portal.netedge.com (portal.netedge.com [199.170.8.2]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA26266 for ; Mon, 24 Nov 1997 16:25:29 -0500 (EST) Received: from NetEdge.COM by portal.netedge.com id AA13451; Mon, 24 Nov 97 16:24:29 EST Received: from bertha2.NetEdge.COM by NetEdge.COM id AA14100; Mon, 24 Nov 97 16:24:10 EST Received: by bertha2.NetEdge.COM (SMI-8.6/NESCL-5.3) id QAA07539; Mon, 24 Nov 1997 16:24:36 -0500 Date: Mon, 24 Nov 1997 16:24:36 -0500 From: Vivian_Lu@NetEdge.COM (Vivian_Lu) Message-Id: <199711242124.QAA07539@NetEdge.COM> To: idr@merit.edu Subject: third party nexthop Cc: sbar@portal.netedge.com X-Sun-Charset: US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Hi, We are currently implementing bgp4, and have the following questions. In the latest draft, (section 5.1.3 NEXT_HOP) "The NEXT_HOP path attribute defines the IP address of the border router that should be used as the next hop to the destinations listed in the UPDATE message. When advertising a NEXT_HOP attribute to an external peer, a router may use one of its own interface addresses in the NEXT_HOP attribute provided the external peer to which the route is being advertised shares a common subnet with the NEXT_HOP address. This is known as a "first party" NEXT_HOP attribute. A BGP speaker ^^^^^^^^^^^^^ can advertise to an external peer an interface of any internal peer ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ router in the NEXT_HOP attribute provided the external peer to which ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the route is being advertised shares a common subnet with the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ NEXT_HOP address. This is known as a "third party" NEXT_HOP ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ attribute. A BGP speaker can advertise any external peer router in ^^^^^^^^^ the NEXT_HOP attribute provided that the IP address of this border router was learned from an external peer and the external peer to which the route is being advertised shares a common subnet with the NEXT_HOP address. This is a second form of "third party" NEXT_HOP attribute." It seems to me with the underlined restriction in the "third party" NEXT_HOP case, the internal peer whose interface address is advertised in the NEXT_HOP attribute by the BGP speaker must be on the same subnet as BGP speaker and its external peer. My question is when and how does this get used in the real world scenario? why will there be a need of a IBGP and EBGP running on two different machines on the same subnet? and how many vendors actually enforce this checking? Your help is very much appreciated. Vivian. ------------------------------------------------------------------------ Vivian H. Lu E-MAIL: vlu@netedge.com NetEdge Systems, Inc. PHONE: (508)670-2934 85 Rangeway Road, FAX: (508)262-0802 Billerica, Massachusetts. ------------------------------------------------------------------------ From owner-idr@merit.edu Mon Nov 24 18:10:19 1997 Delivery-Date: Mon, 24 Nov 1997 18:10:19 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA24448 for ; Mon, 24 Nov 1997 18:10:19 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA04943 for ; Mon, 24 Nov 1997 18:13:17 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA27155 for idr-outgoing; Mon, 24 Nov 1997 17:05:00 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA27151 for ; Mon, 24 Nov 1997 17:04:44 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA23076; Mon, 24 Nov 1997 17:03:13 -0500 (EST) Message-Id: <199711242203.RAA23076@ns.ietf.org> To: IETF-Announce: ; Cc: idr@merit.edu From: The IESG SUBJECT: Last Call: Multiprotocol Extensions for BGP-4 to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Mon, 24 Nov 1997 17:03:13 -0500 Sender: owner-idr@merit.edu Precedence: bulk The IESG has received a request from the Inter-Domain Routing Working Group to consider Multiprotocol Extensions for BGP-4 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 2, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-01.txt From owner-idr@merit.edu Mon Nov 24 18:43:14 1997 Delivery-Date: Mon, 24 Nov 1997 18:43:14 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA24755 for ; Mon, 24 Nov 1997 18:43:13 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA05062 for ; Mon, 24 Nov 1997 18:46:10 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA28382 for idr-outgoing; Mon, 24 Nov 1997 18:13:50 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA28375 for ; Mon, 24 Nov 1997 18:13:44 -0500 (EST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id PAA03918; Mon, 24 Nov 1997 15:13:13 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id PAA00523; Mon, 24 Nov 1997 15:12:42 -0800 (PST) To: Vivian_Lu@NetEdge.COM (Vivian_Lu) cc: idr@merit.edu, sbar@portal.netedge.com Subject: Re: third party nexthop References: <199711242124.QAA07539@NetEdge.COM> From: Tony Li Date: 24 Nov 1997 15:12:41 -0800 In-Reply-To: Vivian_Lu@NetEdge.COM's message of 24 Nov 97 21:24:36 GMT Message-ID: <82afetzy1i.fsf@chimp.juniper.net> Lines: 27 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-idr@merit.edu Precedence: bulk > It seems to me with the underlined restriction in the "third party" > NEXT_HOP case, the internal peer whose interface address is advertised > in the NEXT_HOP attribute by the BGP speaker must be on the same subnet > as BGP speaker and its external peer. Yup, that's what that's trying to say. > My question is when and how does this get used in the real world scenario? How IS it used, or how COULD it be used? Suppose that you had a LAN for an inter-domain interconnect where particular providers showed up with more than one router. One router could be used to distribute routing info to neighbors, and this feature would cause traffic to actually short cut this router. I'm not aware of anyone who actually makes use of this as the redundancy in this mechanism is somewhat lacking... > why will there be a need of a IBGP and EBGP running on two different machines > on the same subnet? > and how many vendors actually enforce this checking? I know of at least two implementations that check this. Further, not checking is pretty much guaranteed to be suicidal (to your traffic). Tony From owner-idr@merit.edu Wed Nov 26 16:22:53 1997 Delivery-Date: Wed, 26 Nov 1997 16:22:53 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA22531 for ; Wed, 26 Nov 1997 16:22:53 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA12745 for ; Wed, 26 Nov 1997 16:25:50 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA14773 for idr-outgoing; Wed, 26 Nov 1997 15:41:22 -0500 (EST) Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA14765 for ; Wed, 26 Nov 1997 15:40:50 -0500 (EST) Received: by relay.hq.tis.com; id PAA11305; Wed, 26 Nov 1997 15:39:16 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma011298; Wed, 26 Nov 97 15:38:29 -0500 Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id PAA29297; Wed, 26 Nov 1997 15:36:19 -0500 (EST) Date: Wed, 26 Nov 1997 15:36:19 -0500 (EST) From: Sandy Murphy Message-Id: <199711262036.PAA29297@clipper.hq.tis.com> To: idr@merit.edu Subject: a draft that missed the deadline Cc: sandy@tis.com Sender: owner-idr@merit.edu Precedence: bulk Attached you will find an internet-draft describing the security vulnerabilities in BGP, some possible solutions and the costs of those solutions. This is an item that I've been supposed to complete for an unconscionable length of time. Unfortunately, I did not get it done in time for submission to the IETF by the Friday cutoff. Yakov has suggested that I discuss this at the idr meeting in Washington. --Sandy Murphy Trusted Information Systems Glenwood, MD 21738 ------------------------------------------------------------------------- Network Working Group Sandra Murphy INTERNET DRAFT Trusted Information Systems draft-ietf-bgp-secr-00.txt November 1997 BGP Security Analysis Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet Drafts as reference material or to cite them other than as ``work in progress''. To learn the current status of any Internet Draft, please check the 1id-abstracts.txt listing contained in one of the Internet Drafts Shadow Directories on ds.internic.net (US East Coast), venera.isi.edu (US West Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe). Abstract BGP, along with a host of other infrastructure protocols designed before the Internet environment became perilous, is designed with little consideration for protection of the data it communicates or of its own behavior. There are no mechanisms in BGP to protect against attacks that modify, delete, forge, or replay data, any of which has the potential to be destructive of overall network routing behavior. This internet draft discusses some of the security issues with BGP routing data dissemination, and possible security solutions and the costs of those solutions. This internet draft does not discuss security issues with forwarding of packets. 1. Introduction The two most common inter-domain routing protocols, BGP and IDRP, were created when the Internet environment had not yet reached the present contentious state. Consequently, neither protocol was designed with Murphy Expires: Jun 1998 [Page 1] INTERNET DRAFT BGP Security Analysis December 1997 protection against deliberate or accidental errors causing disruptions of routing behavior. We here discuss the vulnerabilities of BGP, based on the BGP RFC [1]. Vulnerabilities in IDRP should be similar. We propose several different security solutions to protect these vulnerabilities, discuss the benefits derived from each solution and its cost. It is clear that the Internet is vulnerable to attack through its routing protocols. BGP is no exception. Faulty, misconfigured or deliberately malicious sources can disrupt overall Internet behavior by injecting bogus routing information into the BGP distributed routing database (by modifying, forging, or replaying BGP packets). The same methods can also be used to disrupt local and overall network behavior by breaking the distributed communication of information. The sources can be either external or internal to the protocol, i.e., non-BGP speakers or true BGP speakers. Under the present BGP/IDRP design, any external source can inject believable BGP/IDRP packets into the communication between BGP/IDRP peers and thereby inject bogus routing information or break the peer to peer connection. With IP spoofing, the external sources of bogus BGP information can reside anywhere in the world. Furthermore, external sources can disrupt communications between BGP peers by breaking their TCP connection with spoofed RST packets. Internal sources, i.e., BGP speakers themselves, can inject bogus routing information masquerading as information from any other legitimate BGP speaker. Bogus information from either external or internal sources can affect routing behavior in the Internet over a wide, possibly unbounded, area. Bogus routing information can have many different effects on routing behavior. If the bogus information removes routing information for a particular network, that network can become unreachable for the portion of the Internet that accepts the bogus information. If the bogus information changes the route to a network, then packets destined for that network may be forwarded by a sub-optimal path, or a path that does not follow the expected policy, or a path that will not forward the traffic. If the bogus information makes it appear that an autonomous system originates a network when it does not, then packets for that network may not be deliverable for the portion of the Internet that accepts the bogus information. A false announcement that an autonomous systems originates a network may also fragment aggregated address blocks in other parts of the Internet and cause routing problems for other networks. Murphy Expires: Jun 1998 [Page 2] INTERNET DRAFT BGP Security Analysis December 1997 2. Specific Vulnerabilities Each message introduces certain different vulnerabilities: 2.1. OPEN Because receipt of a new OPEN message in the Established state will cause the close of the BGP peering session and thereby induce the release of all resources and deletion of all associated routes, the ability to spoof this message can lead to a severe disruption of routing. 2.2. KEEPALIVE Receipt of a KEEPALIVE message when the peering connection is in the OpenSent state can lead to a failure to establish a connection. The ability to spoof this message is a vulnerability, but difficult to exploit deliberately, as it must be carefully timed in the sequence of messages exchanged between the peers if it is to cause damage. 2.3. NOTIFICATION Receipt of a NOTIFICATION message will cause the close of the BGP peering session and thereby induce the release of all resources and deletion of all associated routes. Therefore, the ability to spoof this message can lead to a severe disruption of routing. 2.4. UPDATE The Update message carries the routing information. The ability to spoof any part of this message can lead to a disruption of routing. 2.4.1. Unfeasible Routes Length, Total Path Attribute Length There is a vulnerability arising from the ability to modify these fields. If a length is modified, the message is not likely to parse properly, resulting in an error, the transmission of a NOTIFICATION message and the close of the connection. As a true BGP speaker is always able to close a connection at any time, this vulnerability represents an additional risk only when the source is external, i.e., it presents no additional risk from internal sources. Murphy Expires: Jun 1998 [Page 3] INTERNET DRAFT BGP Security Analysis December 1997 2.4.2. Withdrawn Routes An external source could cause the elimination of existing legitimate routes by forging or modifying this field. An external source could also cause the elimination of reestablished routes by replaying this withdrawal information from earlier packets. A BGP speaker could "falsely" withdraw feasible routes using this field. However, as the BGP speaker is authoritative for the routes it will announce, it is allowed to withdraw any previously announced routes that it wants. As the receiving BGP speaker will only withdraw routes associated with the sending BGP speaker, there is no opportunity for a BGP speaker to withdraw another BGP speaker's routes. Therefore, there is no additional vulnerability from internal sources via this field. 2.4.3. Path Attributes The path attributes present many different vulnerabilities. Attribute Flags, Attribute Type Codes, Attribute Length An internal or external source could modify the attribute length or attribute type (flags and type codes) so they did not reflect the attribute values that followed. If the length were modified, the likely result would be that the UPDATE message would not parse correctly. If the flags were modified, the flags and type code could become incompatible (i.e., a mandatory attribute marked as partial), or a optional attribute could be interpreted as a mandatory attribute or vice versa. Modifying the type code could cause the attribute value to be interpreted as if it were the data type and value of a different attribute. The most likely result from modifying the attribute flags or type code would be a parse error of the UPDATE message. A parse error from any modification would cause the transmission of a NOTIFICATION message and the close of the connection. As a true BGP speaker is always able to close a connection at any time, this vulnerability represents an additional risk only when the source is external, i.e., it presents no additional risk from internal sources. ORIGIN This field indicates whether the information was learned from IGP or EGP information. If the route is used in inter-AS multicast routing, a values of INCOMPLETE may be used. This field is not used in making routing decisions, so there are no vulnerabilities arising from this field, either from internal or external sources. Murphy Expires: Jun 1998 [Page 4] INTERNET DRAFT BGP Security Analysis December 1997 AS_PATH An internal or external source could announce an AS_PATH that was not accurate for the associated NLRI. Forwarding for the NLRI associated with the AS_PATH could potentially be induced to follow a sub-optimal path, a path that did not follow some intended policy, or even a path that would not forward the traffic. It is not clear how far an inaccurate AS_PATH could deviate from the true AS_PATH. It may be that the first AS in the AS_PATH, at least, must be a legal hop. The RFC states that a BGP speaker prepends its own AS to an AS_PATH before announcing it to a neighbor. If the BGP speaker must prepend its own AS, then a BGP speaker that produced a bogus AS_PATH could end up receiving the traffic for the associated NLRI. This could be desirable if the error was deliberate and the intent was to receive traffic that would not otherwise be received. Receiving the mis-routed traffic could be undesirable for the faulty BGP speaker if it is not prepared to handle the extra (mis-routed) traffic. So, if a deliberately malicious speaker must prepend its own AS, it could be motivated or discouraged from inventing an arbitrary AS_PATH. If the BGP speaker need not prepend its own AS, then it could announce a path that begins with the AS of any BGP speaker. Whether such an arbitrary AS_PATH is a vulnerability would depend on whether BGP implementations check the AS_PATH (to see if the first AS is the neighbor) and would catch the error. If there are legitimate situations in which a BGP speaker could pass an AS_PATH to a neighbor without putting its own AS at the head of the AS_PATH, then there is no way for implementations to detect totally bogus AS_PATHs. Originating Routes A special case of announcing a false AS_PATH occurs when the AS_PATH advertises a direct path to a very specific network address. An internal or external source could disrupt routing to the network(s) listed in the NLRI field by falsely advertising a direct path to the network. The NLRI would become unreachable to the portion of the network that accepted this route, unless the BGP speaker undertook to tunnel the packets it was forwarded for this NLRI on toward their destination by a legal path. But even when the BGP speaker tunnels the packets on to the correct destination, the route followed may not be optimal or may not follow the intended policy. Additionally, routing for other networks in the Internet could be affected if the false advertisement fragmented an aggregated address block. Murphy Expires: Jun 1998 [Page 5] INTERNET DRAFT BGP Security Analysis December 1997 NEXT_HOP The NEXT_HOP attribute defines the IP address of the border router that should be used as the next hop when forwarding the NLRI listed in the UPDATE message. If the recipient is an external peer, then the recipient and the NEXT_HOP address must share a subnet. It is clear that an outside source modifying this field could disrupt the forwarding of traffic between the two AS's. In the case that the NEXT_HOP address is an inter-AS peer and the recipient of the message is an inter-AS peer of a different AS (this is one of two forms of "third party" NEXT_HOP), then the BGP speaker advertising the route has the opportunity to direct the recipient to forward traffic to a BGP speaker (the NEXT_HOP peer) that may not be able to continue forwarding the traffic. It is unclear whether this would also require the advertising BGP speaker to construct an AS_PATH mentioning the NEXT_HOP inter-AS peer's AS. MULTI_EXIT_DISC The MULTI_EXIT_DISC attribute is used in UPDATE messages transmitted between inter-AS BGP peers. While the MULTI_EXIT_DISC received from an inter-AS peer may be propagated within an AS, it may not be propagated to other AS's. Consequently, this field is only used in making routing decisions internal to one AS. Modifying this field, whether by an external source or an internal source, could influence routing within an AS to be sub-optimal, but the effect should be limited in scope. LOCAL_PREF The LOCAL_PREF attribute must be included in all messages with internal peers and excluded from messages with external peers. Consequently, modification of the LOCAL_PREF could effect the routing process within the AS only. Note that there is no requirement in the BGP RFC that the LOCAL_PREF be consistent among the internal BGP speakers of an AS. As internal sources are free to choose the LOCAL_PREF as they wish, modification of this field is a vulnerability with respect to external sources only. ATOMIC_AGGREGATE The ATOMIC_AGGREGATE field indicates that an AS somewhere along the way has received a more specific and a less specific route to the NLRI and installed the aggregated route. This route cannot be deaggregated because it is not certain that the route to more specific prefixes will follow the listed AS_PATH. Consequently, BGP speakers receiving a route with ATOMIC_AGGREGATE are restricted from making the NLRI any more Murphy Expires: Jun 1998 [Page 6] INTERNET DRAFT BGP Security Analysis December 1997 specific. Removing the ATOMIC_AGGREGATE attribute would remove the restriction, possibly causing traffic intended for the more specific NLRI to be routed incorrectly. Adding the ATOMIC_AGGREGATE attribute when no aggregation was done would have little effect, beyond restricting the un-aggregated NLRI from being made more specific. This vulnerability exists whether the source is internal or external. AGGREGATOR This field may be included by a BGP speaker who has computed the routes represented in the UPDATE message from aggregation of other routes. The field contains the AS number and IP address of the last aggregator of the route. It is not used in making any routing decisions, so it does not represent a vulnerability. 2.4.4. NLRI By modifying or forging this field, either an external or internal source could cause disruption of routing to the announced network, overwhelm a router along the announced route, cause data loss when the announced route will not forward traffic to the announced network, route traffic by a sub-optimal route, etc. 3. Possible Protections 3.1. External sources External sources can be prevented from disrupting routing by providing cryptographic protection of the BGP peer connection. The cryptography chosen should protect the authenticity and integrity of the message and should also protect against replay. As the protection is only of the peer-peer communications, asymmetric cryptography is not needed. The protection could be provided at the IP level by using existing IPSEC mechanisms. If IPSEC is not available, using cryptographic protection within BGP or TCP would be necessary (but is not as yet defined). Note that applying the cryptographic protection within BGP does not provide the same protection as applying it within TCP, as TCP information other than the payload (BGP) data (e.g., the RST field) could still be spoofed in ways that would harm the connection. Prevention of spoofing completely removes any risk associated with bogus OPEN, KEEPALIVE, or NOTIFICATION messages, as the only vulnerabilities from these messages come from external sources. It also protects against all threats from bogus UPDATE messages arising from external sources. Murphy Expires: Jun 1998 [Page 7] INTERNET DRAFT BGP Security Analysis December 1997 3.2. Internal sources Protection of the communication between BGP peers does nothing to protect against errors introduced by the BGP speakers themselves. BGP speakers can introduce bogus routing information, e.g., invalid AS_PATHs, incorrect ORIGINs, etc., at any time. Furthermore, detecting the internal source of bogus information (if and when the bogus-ness is detected) can be difficult if not impossible. There are several possible solutions to prevent a BGP speaker from inserting bogus information in its advertisements to its peers. (1) sign the originating AS. (2) sign the originating AS and predecessor information (3) sign the originating AS, and nest signatures of AS_PATHs to the number of consecutive bad routers you want to prevent from causing damage. (4) rely on a registry to say if AS_PATH and originating AS are valid 3.3. Sign Originating AS It would be beneficial to know which AS has first advertised a route to a NLRI. This could be done by including a new field which would contain the originating AS number and the originating AS's digital signature [3] of that plus the NLRI advertised. A digital signature is required because the number and identities of all eventual recipients could not be known and because non-repudiation would be desired. This field could be verified against an Internet registry, if a complete and accurate registry existed. If routing was disturbed by the presence of this advertisement, then the culprit could be determined. If a structure exists representing ownership of network addresses, then the owner as well as the advertiser could sign. A representation of an owner could be useful when Internet service providers transfer sub- blocks of their owned addresses to smaller ISP's. The ISP's could advertise NLRI but the ownership of the network could still be determined. If routes are aggregated by a BGP speaker and the aggregated route advertised, then the idea of "originator" and "owner" become less useful. There might be several "originators" and "owners" represented among the aggregated routes. We suggest that the AGGREGATOR field Murphy Expires: Jun 1998 [Page 8] INTERNET DRAFT BGP Security Analysis December 1997 become mandatory and that an aggregating BGP speaker append its signature of the AGGREGATOR field and the aggregated NLRI. Unfortunately, aggregation prevents identification of the specific culprit should it be discovered that a network is being originated in error. 3.4. Sign Originating AS and Predecessor Information Reference [2] suggests several different types of cryptographic protection of BGP. The suggested protection against possibly faulty BGP speakers introduces some link state topology information (see [4]) that can be used to verify AS_PATHs. To protect against the need to trust BGP speakers regarding NLRI information not specific to their own AS, [2] suggests adding the following information to the UPDATE message: - the AS originating the information (either the aggregator or the advertiser of a direct route) and - the predecessor of the originating AS (i.e., the neighbor to which the NLRI is first advertised). This field is digitally signed along with the NLRI, the ATOMIC_AGGREGATOR, and other fields of the UPDATE message. The signature and the predecessor information must be included as the route in the UPDATE message propagates across the network, i.e., it is transitive. This information distributes a bit of link state topology information, concerning just the last hop before the destination network's AS, into the usual BGP distance vector (some say "path vector") protocol. Each BGP speaker, even those who are transit only and originate no UPDATE messages with NLRI contained in their own AS, will transmit this "predecessor" information. From all the signed predecessor information received, it would be possible to verify that each of the adjacencies represented in an AS_PATH is legitimate. When a segment of an AS_PATH is a sequence, each adjacent pair in the sequence must correspond to a received signed predecessor tuple. The protection provided by the signed predecessor information becomes more difficult to use past an aggregation point where a BGP speaker advertises a less specific route which includes the NLRI. In particular, the rules for verifying an AS_PATH containing a segment that is a set would be either very lenient or very complex. Murphy Expires: Jun 1998 [Page 9] INTERNET DRAFT BGP Security Analysis December 1997 While this predecessor information assures that each adjacency in a sequence of an AS_PATH is valid, it does not ensure that the AS_PATH as a whole is valid. Each AS's decision regarding routes it will advertise and traffic it will transit is individual and totally unconstrained. The fact that a valid path of ASs exists to a destination does not ensure that the corresponding AS_PATH is valid. This mechanism also does not assure that any information which comes from one router alone (LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.) is accurate. A router, then, can still falsely announce that its neighbor should be forwarded the traffic for an NLRI. 3.5. Sign Originating AS and AS_PATH A protection against possibly faulty BGP speakers that does provide some assurance that the AS_PATH is valid involves nested digital signatures of the AS_PATH. Each BGP speaker would receive signed AS_PATH information (including the ATOMIC_AGGREGATOR and NLRI attributes) from its peer. After making its routing decision, it would augment the chosen AS_PATH with its own AS and sign the result. The BGP speaker would pass to its peers the augmented AS_PATH, its signature, and the signature of its peer over the base AS_PATH from which the augmented AS_PATH was formed. The peer receiving this information can verify that the received AS_PATH was indeed constructed with some basis in reality by verifying the signature of the BGP speaker's peer over the tail of the received AS_PATH. The BGP speaker's signature will be passed on by the peer to provide similar assurance that it constructed its advertised AS_PATH legitimately. This procedure as described protects against one consecutive faulty router in the path. If it is desired to protect against more possibly faulty routers in the path, then the procedure can be nested arbitrarily. To protect against n consecutive faulty routers, each router would receive signed AS_PATH information from its neighbor along with n signatures of the preceding n BGP speakers in the path, each successive signature covering a shorter suffix of the path. It would pass on a newly constructed AS_PATH along with its own signature, its neighbor's signature and n-1 of the included nested signatures. A BGP speaker could snip out a suffix of the data it received as well as the associated signatures and pass those on as the proof that its AS_PATH was based on reality. To prevent this, the signatures generated should cover not only the AS_PATH but the intended receiver as well. Murphy Expires: Jun 1998 [Page 10] INTERNET DRAFT BGP Security Analysis December 1997 For example, consider a case where it was decided to protect against only one faulty BGP speaker. Suppose AS1 receives an AS_PATH from AS2 of "AS2 AS3 ... ASk". Then it should also receive AS2's signature of "AS1, 'AS2 AS3 ... ASk'" and AS3's signature of "AS2, 'AS3 ... ASk'". AS1 would compute a path "AS1 AS2 AS3 ... ASk", and pass on to AS0 this path along with its signature of "AS0, 'AS1 AS2 AS3 ... ASk'" and AS2's signature of "AS1, 'AS2 AS3 ... ASk'". Note that this scheme becomes more complicated when one of the BGP speakers performs aggregation of a set of routes. To assure recipients of the validity of the aggregated route, it would be necessary to pass on the text and signatures of each of the aggregated component routes. This means an enormous increase in transmission bandwidth and verification time at each aggregation point, rather than a decrease. This cost would not have to be passed on to further neighbors, but it does violate the spirit of aggregation. Note that this scheme does not assure that the received route is the best route the peer could have computed. In particular, it does not guard against a peer that does not announce the best result of its decision process - a peer that replays previous announcements, perhaps, or does not change its announcements when it receives withdrawn routes. These are a matter for the internal correct operation of the router and cannot be induced by security protection. This mechanism also does not assure that any information which comes from one router alone (LOCAL_PREF, NEXT_HOP, AGGREGATOR, etc.) is accurate. A router, then, can still falsely announce that its neighbor should be forwarded the traffic for an NLRI. This discussion is predicated on the use of asymmetric cryptography. Each autonomous system would be required to possess an asymmetric key pair. The public key would have to be accessible to all recipients of the digital signature. The private key would have to be available to all BGP speakers in the autonomous system, but protected from exposure. Alternatively, each BGP speaker could possess its own asymmetric key pair, at the cost of further complicating the protocol. The protocol would have to be altered to include the identity of the BGP speaker within the AS who produces the AS_PATH and signature so that the signature verification procedure could choose the correct public key to use. Symmetric cryptography could be used to protect the information by using a keyed cryptographic hash instead of a digital signature. However, in order to provide the same level of protection against faulty routing, each BGP speaker would have to share a different secret key with each of Murphy Expires: Jun 1998 [Page 11] INTERNET DRAFT BGP Security Analysis December 1997 its neighbors and each of its neighbors' neighbors. (In the case that it is desired to protect against n>1 faulty BGP speakers, the number of keys would grow exponentially - a different key with all 1-hop-away neighbors, 2-hop-away neighbors, ..., and n+1-hop-away neighbors.) This is obviously not a scalable solution. It may also require autonomous systems to reveal their peering agreements where they would not wish to do so. 3.6. Rely on Registries The Internet registries can provide data that will help to assure that AS_PATHS and NLRI origination data are correct. If the data registered in the Internet registries can be assumed to be correct, then the peering information in the database can be used to verify each pair of AS's in an AS_PATH sequence segment are truly peers. Depending on the sophistication of the information recorded in the registry, the registries might also be used to verify that the AS_PATH as a whole was valid. The assurance provided by this protection would rely on the completeness of the registry, on the authenticity of the registry data and on the protection it received in storage and transit. The protection is useful if data from the registry is either available locally or retrievable with an acceptable lag time. The assurance provided by this protection also relies on the openness of the data recorded in the registries. To be truly useful, each autonomous system's policy would have to be recorded in the registry, in order that the AS_PATH as a whole can be verified to be valid. Information about policy, however, can be sensitive to an autonomous system and not openly available to every other autonomous system. Any restrictions on the availability of information stored in the registry will restrict its applicability as a protection mechanism. 4. Security Costs Choosing the protection to apply in any situation depends on the perception of the risk of attack, of the damage that can result, of the benefits derived from providing the protection, and of the cost of providing the protection. This section discusses the cost of each of the protection options mentioned above. Murphy Expires: Jun 1998 [Page 12] INTERNET DRAFT BGP Security Analysis December 1997 4.1. Protecting the Peer-Peer Link The cost of this protection is the processing required for the cryptography and the need to establish and manage the cryptographic keys. The cryptography need not be computationally expensive; HMAC or similar algorithms can be used. Shared secret keys are adequate for this protection, as the protection applies only to the communication between peers, so the key management cost is low. Ideally, a separate key should be used for each BGP peering. One key might be used for multiple peerings with a reduction in the level of protection that is provided. However, it is best to remember that apocryphally, the more places know a secret, the more chances it will be exposed. This level of protection is low cost and protects against the vast number of possible adversaries (i.e., any non-BGP speaker in the internet). 4.2. Sign Originating AS The cost of signing the originating AS of each route is the cost of providing a public key infrastructure to generate an asymmetric key pair for each autonomous system and to distribute and maintain the public keys associated with each autonomous system. The Internet registries might be sufficient to serve as an authorization structure for advertising each NLRI, but the authorization of ownership of network addresses would either have to come from the IANA or from some new authorization structure. 4.3. Sign Originating AS and Predecessor Information This scheme requires the same public key infrastructure as is needed if one simply signs the originating AS information. It also requires that each adjacency for a BGP speaker be signed (the "predecessor" information) and transmitted along with an AS_PATH. Essentially, each BGP speaker must announce its peers, something that does not currently occur in the BGP protocol. Each BGP speaker must compute one signature for each UPDATE message transmitted and must verify one signature for each UPDATE message received. (Each UPDATE message must be separately signed because the mechanism described in [2] includes a sequence number, the Withdrawn Routes and the Unfeasible Route Length fields, so the information to be signed changes with each message. These fields are protected from external sources by the peer-peer communication protection and so do not need to be digitally signed. If only the NLRI, ATOMIC_AGGREGATE and predecessor information were signed each time, then the signature might not have to be computed with each new UPDATE message.) The predecessor information in each route must be stored Murphy Expires: Jun 1998 [Page 13] INTERNET DRAFT BGP Security Analysis December 1997 indefinitely. Each route received must be verified by comparison to predecessor information previously received. 4.4. Sign Originating AS and AS_PATH This scheme requires the same public key infrastructure as is needed if one simply signs the originating AS information. For each UPDATE message received, n signatures (the level of protection from consecutive faulty routers) must be verified. For each UPDATE message transmitted, one signature must be computed. Note that the signature includes the recipient, so computing one signature per AS_PATH and NLRI announced is insufficient. 4.5. Rely on Registries The cost of relying on registries would vary considerably depending on the protection provided to the information in storage and in transit. Any latency, above that caused by the use of cryptography, would depend on the mechanism used to protect the registry information (e.g., anything from frequent complete download to real-time query and response). 5. Security Considerations This entire memo is about security considerations. 6. References [1] RFC1771, A Border Gateway Protocol 4 (BGP-4). Y. Rekhter & T. Li. March 1995. [2] B. Smith and J.J. Garcia-Luna-Aceves, ``Securing the Border Gateway Routing Protocol,'' Proc. Global Internet'96, London, UK, 20-21 November 1996. [3] Bruce Schneier. Applied Cryptography Protocols, Algorithms, and Source Code in C, John Wiley & Sons, Inc 1994 [4] John Moy. OSPF Version 2. RFC 1583, March 1994 7. Author's Address Sandra Murphy Trusted Information Systems 3060 Washington Road Murphy Expires: Jun 1998 [Page 14] INTERNET DRAFT BGP Security Analysis December 1997 Glenwood, MD 21738 EMail: Sandy@tis.com Murphy Expires: Jun 1998 [Page 15] INTERNET DRAFT BGP Security Analysis December 1997 Table of Contents Status of this Memo .............................................. 1 Abstract ......................................................... 1 1 Introduction .................................................... 1 2 Specific Vulnerabilities ........................................ 3 2.1 OPEN .......................................................... 3 2.2 KEEPALIVE ..................................................... 3 2.3 NOTIFICATION .................................................. 3 2.4 UPDATE ........................................................ 3 2.4.1 Unfeasible Routes Length, Total Path Attribute Length ....... 3 2.4.2 Withdrawn Routes ............................................ 4 2.4.3 Path Attributes ............................................. 4 Attribute Flags, Attribute Type Codes, Attribute Length .......... 4 ORIGIN ........................................................... 4 AS_PATH .......................................................... 5 Originating Routes ............................................... 5 NEXT_HOP ......................................................... 6 MULTI_EXIT_DISC .................................................. 6 LOCAL_PREF ....................................................... 6 ATOMIC_AGGREGATE ................................................. 6 AGGREGATOR ....................................................... 7 2.4.4 NLRI ........................................................ 7 3 Possible Protections ............................................ 7 3.1 External sources .............................................. 7 3.2 Internal sources .............................................. 8 3.3 Sign Originating AS ........................................... 8 3.4 Sign Originating AS and Predecessor Information ............... 9 3.5 Sign Originating AS and AS_PATH ............................... 10 3.6 Rely on Registries ............................................ 12 4 Security Costs .................................................. 12 4.1 Protecting the Peer-Peer Link ................................. 13 4.2 Sign Originating AS ........................................... 13 4.3 Sign Originating AS and Predecessor Information ............... 13 4.4 Sign Originating AS and AS_PATH ............................... 14 4.5 Rely on Registries ............................................ 14 5 Security Considerations ......................................... 14 6 References ...................................................... 14 7 Author's Address ................................................ 14 Murphy Expires: Jun 1998 [Page 16] From owner-idr@merit.edu Wed Nov 26 20:40:29 1997 Delivery-Date: Wed, 26 Nov 1997 20:40:30 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id UAA25281 for ; Wed, 26 Nov 1997 20:40:29 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA13215 for ; Wed, 26 Nov 1997 20:43:26 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA18944 for idr-outgoing; Wed, 26 Nov 1997 20:03:24 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA18937 for ; Wed, 26 Nov 1997 20:03:20 -0500 (EST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id RAA09362; Wed, 26 Nov 1997 17:02:43 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id RAA07246; Wed, 26 Nov 1997 17:02:08 -0800 (PST) To: sandy@tis.com (Sandy Murphy) cc: idr@merit.edu Subject: Re: a draft that missed the deadline References: <199711262036.PAA29297@clipper.hq.tis.com> From: Tony Li Date: 26 Nov 1997 17:02:08 -0800 In-Reply-To: sandy@tis.com's message of 26 Nov 97 20:36:19 GMT Message-ID: <82n2ircfov.fsf@chimp.juniper.net> Lines: 21 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-idr@merit.edu Precedence: bulk Sandy, Thank you for the note. I was quite disappointed to see no mention of draft-heffernan-tcp-md5-02.txt.gz (admittedly, it has expired) or its methods. You alude to the benefits, but seem completely oblivious to the fact that it's already in shipping code. I was also hoping for more of a recommendation for the internal sources solution. The problem there is of the most theoretical interest and the one that we would appreciate the assistance on. Finally, I was really hoping to see more discussion of the prefix assignment problem. Again, you allude to it briefly in section 3.3, but the authenticated delegation of prefixes is a serious problem that we could use help with. Regards, Tony From owner-idr@merit.edu Mon Dec 1 12:17:50 1997 Delivery-Date: Mon, 01 Dec 1997 12:17:51 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA19406 for ; Mon, 1 Dec 1997 12:17:50 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA03362 for ; Mon, 1 Dec 1997 12:20:44 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA19370 for idr-outgoing; Mon, 1 Dec 1997 11:39:41 -0500 (EST) Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA19366 for ; Mon, 1 Dec 1997 11:39:37 -0500 (EST) Received: by relay.hq.tis.com; id LAA16457; Mon, 1 Dec 1997 11:38:46 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma016438; Mon, 1 Dec 97 11:38:01 -0500 Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id LAA01103; Mon, 1 Dec 1997 11:35:31 -0500 (EST) Date: Mon, 1 Dec 1997 11:35:31 -0500 (EST) From: Sandy Murphy Message-Id: <199712011635.LAA01103@clipper.hq.tis.com> To: tli@juniper.net Subject: Re: a draft that missed the deadline Cc: idr@merit.edu, sandy@tis.com Sender: owner-idr@merit.edu Precedence: bulk >I was quite disappointed to see no mention of >draft-heffernan-tcp-md5-02.txt.gz (admittedly, it has expired) or its >methods. You alude to the benefits, but seem completely oblivious to the >fact that it's already in shipping code. I am well aware of Andy Heffernan's work (which I thought you also had a hand in, judging by our conversations about TCP RST's). I did not mention it because, as you said, the work had been dropped from the IETF working group active consideration. I thought that the reason those drafts were allowed to expire was because the protection provided by IPSEC is at least as good as the protection provided by doing MD5 protection at the TCP level. Given the limited amount of option space in the TCP packet and the recent concerns about MD5 potential vulnerabilities by itself (leading the IPSEC group to recommend the HMAC approach), the IPSEC solution might even be better. Be that as it may, I saw several messages in September between Ran Atkinson and Jeff Schiller about that draft, suggesting that it might be resurrected for publication as an Informational RFC. Do you know anything more about that? On a side note, I've been trying to come up with good reasons why keyed crypto hash protection at the application level might still be useful when IPSEC is fully deployed. Given the number of protocols that have defined their own protection while waiting for IPSEC, it is a question with some broad applicability. One might say that protecting at the application level prevents other processes in the same host from horning in. Can you see that as a valid concern to keep application level protection when IPSEC protection is available? >I was also hoping for more of a recommendation for the internal sources >solution. The problem there is of the most theoretical interest and the >one that we would appreciate the assistance on. I was asked, not for a recommendation, but for a discussion of the possibilities and the costs. I think that the business environment plays such a large part in determining what level of protection you need as well as how much you're willing to do to protect yourself that it may take a community decision to make a recommendation. If the usual environment was such that a valid sequence of BGP peers was almost certainly also a valid AS_PATH (i.e., the policy decisions would let traffic through), then Brad Smith's proposal to insert link state information is attractive. The frequency of signatures (I think) can be reduced and therefore the number of verifications. You do have to check each AS_PATH against the link state information to see if it is a valid sequence of adjacent AS's, though. If the usual environment was such that valid sequences of BGP peers were NOT likely to be valid AS_PATH (because of peering agreements and their effect on the traffic that will be transited, etc.), then you need assurance that the *path* is valid, which can mean assurance that your neighbor came by the determination of the path he/she/it sent you honestly - which means some sort of proof that your neighbor based its path on information IT received from a neighbor - which means passing on to you some sort of token from the neighbor's neighbor. And so forth. As I said, the Internet registries can provide some of this assurance. They certainly collect the sort of information that would provide assurance that the hops represented in the AS_PATH are valid. They might also collect the detailed information about policies that would help determine that AS_PATHs are valid. The business environment sticks its nose in that as well, as the policy information needed to determine the validity of AS_PATH might be sensitive and something the ISPs would not want published to the world. >Finally, I was really hoping to see more discussion of the prefix >assignment problem. Again, you allude to it briefly in section 3.3, but >the authenticated delegation of prefixes is a serious problem that we could >use help with. When you say "prefix assignment" problem, you're talking about some AS announcing a prefix that actually belongs to someone else? especially when it's in the middle of someone else's CIDR block? Unfortunately, asking for that sort of protection is asking for assurance that someone is *authorized* (not just authenticated) to speak the information they are providing. Authorization is always something that one is given by someone else. So authorizing the advertisement of a network implies an infrastructure for assigning networks to AS's. That means, for example, an authenticatable token from IANA proving you are allowed to announce this network (maybe given to you when you acquire the address), or some verification from some Internet registry (which implies an infrastructure that would make sure the registry itself had the correct info and got the info to you securely, etc). This is more than just a protocol question. Do you think the idr group (and maybe the rps working group) could take on recommending an infrastructure like this? (I suppose you point to DNS as an example of a working group that set up a ownership infrastructure.) Then there's the problem of aggregation of information. If you have aggregated several pieces of properly authorized information, how do you show that you are authorized to speak the aggregate? Include all the individual authorization tokens? That would pretty much undo the benefits of aggregation. And de-aggregation is a problem as well. As long as BGP contains features to allow de-aggregation (a necessity, I think) of the addresses received, there will be the possibility of mis-use. I actually came to a full stop in early May on this work when I realized that the MAI-Sprint problem was a fully legal use of the protocol, just an extremely unwise one. Maybe the proof-of-originable-address infrastructure could prevent AS's from announcing class-ful addresses that they weren't directly connected to. I think that would mean the protocol would have to know when an address was being advertised as a direct connection, different from the ORIGIN attribute. This message is long enough. I'll quit for now. --Sandy From owner-idr@merit.edu Mon Dec 1 16:54:11 1997 Delivery-Date: Mon, 01 Dec 1997 16:54:12 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA19118 for ; Mon, 1 Dec 1997 16:54:11 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04855 for ; Mon, 1 Dec 1997 16:57:07 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA25783 for idr-outgoing; Mon, 1 Dec 1997 16:22:19 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA25779 for ; Mon, 1 Dec 1997 16:22:03 -0500 (EST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id NAA25367; Mon, 1 Dec 1997 13:21:32 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id NAA10432; Mon, 1 Dec 1997 13:21:37 -0800 (PST) Date: Mon, 1 Dec 1997 13:21:37 -0800 (PST) Message-Id: <199712012121.NAA10432@chimp.juniper.net> From: Tony Li To: sandy@tis.com CC: idr@merit.edu, sandy@tis.com In-reply-to: <199712011635.LAA01103@clipper.hq.tis.com> (message from Sandy Murphy on Mon, 1 Dec 1997 11:35:31 -0500 (EST)) Subject: Re: a draft that missed the deadline Sender: owner-idr@merit.edu Precedence: bulk Sandy, I am well aware of Andy Heffernan's work (which I thought you also had a hand in, judging by our conversations about TCP RST's). I did not mention it because, as you said, the work had been dropped from the IETF working group active consideration. Well, I don't believe that it was actively dropped so much as expired by entropy. I thought that the reason those drafts were allowed to expire was because the protection provided by IPSEC is at least as good as the protection provided by doing MD5 protection at the TCP level. I suspect it was apathy rather than thought. ;-) Given the limited amount of option space in the TCP packet and the recent concerns about MD5 potential vulnerabilities by itself (leading the IPSEC group to recommend the HMAC approach), the IPSEC solution might even be better. I don't disagree, but I'll point out that there's a Best Current Practice and it's pretty much a requirement today and there's no current documentation of it. In short, I would like to see it revived as a draft, if only to become an Informational (and someday Historical?) RFC. Be that as it may, I saw several messages in September between Ran Atkinson and Jeff Schiller about that draft, suggesting that it might be resurrected for publication as an Informational RFC. Do you know anything more about that? That's news to me. On a side note, I've been trying to come up with good reasons why keyed crypto hash protection at the application level might still be useful when IPSEC is fully deployed. Given the number of protocols that have defined their own protection while waiting for IPSEC, it is a question with some broad applicability. One might say that protecting at the application level prevents other processes in the same host from horning in. Can you see that as a valid concern to keep application level protection when IPSEC protection is available? I don't see that as valid for connection oriented protocols. In particular, if a host allows an untrusted user to generate random TCP packets, that would be an OS issue. For UDP based protocols, yes, I think that there might be a valid concern. Consider the multiuser host and the ability of an untrusted user (under some OSs) to listen to well known ports. Brrr..... I was asked, not for a recommendation, but for a discussion of the possibilities and the costs. I think that the business environment plays such a large part in determining what level of protection you need as well as how much you're willing to do to protect yourself that it may take a community decision to make a recommendation. Ok, different question/different answer. If the usual environment was such that valid sequences of BGP peers were NOT likely to be valid AS_PATH (because of peering agreements and their effect on the traffic that will be transited, etc.), then you need assurance that the *path* is valid, which can mean assurance that your neighbor came by the determination of the path he/she/it sent you honestly - which means some sort of proof that your neighbor based its path on information IT received from a neighbor - which means passing on to you some sort of token from the neighbor's neighbor. And so forth. I believe that we will eventually need to do this. Note that I'm not convinced that we need it today, but the ability of Joe Warez to tap into the BGP mesh and fabricate BS is just too credible for any sense of security. When you say "prefix assignment" problem, you're talking about some AS announcing a prefix that actually belongs to someone else? especially when it's in the middle of someone else's CIDR block? Unfortunately, asking for that sort of protection is asking for assurance that someone is *authorized* (not just authenticated) to speak the information they are providing. Yes, yes. Authorization is always something that one is given by someone else. So authorizing the advertisement of a network implies an infrastructure for assigning networks to AS's. That means, for example, an authenticatable token from IANA proving you are allowed to announce this network (maybe given to you when you acquire the address), or some verification from some Internet registry (which implies an infrastructure that would make sure the registry itself had the correct info and got the info to you securely, etc). This is more than just a protocol question. Do you think the idr group (and maybe the rps working group) could take on recommending an infrastructure like this? Recommending? No, I think it's wholly beyond the capabilities of the group. This is not because the protocol is difficult -- that is easily doable. The problem is the entire security infrastructure that you correctly allude to. I believe that this is the first order security problem that we should be addressing. Just for brevity's sake, let's refer to this as the 7007 problem. ;-) (I suppose you point to DNS as an example of a working group that set up a ownership infrastructure.) Was the DNS group soley responsible for DNSSEC? Or did they get help? Then there's the problem of aggregation of information. If you have aggregated several pieces of properly authorized information, how do you show that you are authorized to speak the aggregate? Include all the individual authorization tokens? That would pretty much undo the benefits of aggregation. Yup, a fine question. And de-aggregation is a problem as well. As long as BGP contains features to allow de-aggregation (a necessity, I think) of the addresses received, there will be the possibility of mis-use. Well, in fact, de-aggregation didn't actually ever happen. And I think that's a fine thing. Primarily it was seen as a tool to ease the transition to BGP, but the flash cutover was so quick (thanks to the folks on this list) that the world never really needed it. In fact, we might move deaggregation to a non-feature someday soon (ala OSPF TOS). Tony From owner-idr@merit.edu Mon Dec 1 19:36:34 1997 Delivery-Date: Mon, 01 Dec 1997 19:36:35 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA17158 for ; Mon, 1 Dec 1997 19:36:34 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA05483 for ; Mon, 1 Dec 1997 19:39:27 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA29872 for idr-outgoing; Mon, 1 Dec 1997 19:11:15 -0500 (EST) Received: from home.partan.com (home.partan.com [198.6.255.236]) by merit.edu (8.8.7/8.8.5) with SMTP id TAA29859 for ; Mon, 1 Dec 1997 19:10:59 -0500 (EST) Received: (from asp@localhost) by home.partan.com (8.6.12/8.6.12) id TAA17655; Mon, 1 Dec 1997 19:10:25 -0500 From: Andrew Partan Message-Id: <199712020010.TAA17655@home.partan.com> Subject: Re: a draft that missed the deadline To: tli@juniper.net (Tony Li) Date: Mon, 1 Dec 1997 19:10:24 -0500 (EST) Cc: sandy@tis.com, idr@merit.edu In-Reply-To: <199712012121.NAA10432@chimp.juniper.net> from "Tony Li" at Dec 1, 97 01:21:37 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-idr@merit.edu Precedence: bulk > I am well aware of Andy Heffernan's work (which I thought you also had > a hand in, judging by our conversations about TCP RST's). I did not > mention it because, as you said, the work had been dropped from the > IETF working group active consideration. Its in active use on the Internet today. There are at least 2 implementations of it (there may be more). I don't know anything about its IETF status; I just know some about what is actually used. --asp@partan.com (Andrew Partan) From owner-idr@merit.edu Tue Dec 2 00:03:27 1997 Delivery-Date: Tue, 02 Dec 1997 00:03:28 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA25363 for ; Tue, 2 Dec 1997 00:03:27 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA06087 for ; Tue, 2 Dec 1997 00:06:19 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA03071 for idr-outgoing; Mon, 1 Dec 1997 23:36:05 -0500 (EST) Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by merit.edu (8.8.7/8.8.5) with SMTP id XAA03067 for ; Mon, 1 Dec 1997 23:36:01 -0500 (EST) Received: (ahh@localhost) by stilton.cisco.com (8.6.12/8.6.5) id UAA06763; Mon, 1 Dec 1997 20:34:59 -0800 Date: Mon, 1 Dec 1997 20:34:59 -0800 From: Andy Heffernan Message-Id: <199712020434.UAA06763@stilton.cisco.com> To: tli@juniper.net Subject: Re: a draft that missed the deadline Newsgroups: cisco.external.ietf.iwg In-Reply-To: <199712012121.NAA10432@chimp.juniper.net> References: <199712011635.LAA01103@clipper.hq.tis.com> Organization: cisco Systems, Inc., San Jose, CA Cc: idr@merit.edu, sandy@tis.com Sender: owner-idr@merit.edu Precedence: bulk In article <199712012121.NAA10432@chimp.juniper.net> you write: > >Sandy, > > I am well aware of Andy Heffernan's work (which I thought you also had > a hand in, judging by our conversations about TCP RST's). I did not > mention it because, as you said, the work had been dropped from the > IETF working group active consideration. > >Well, I don't believe that it was actively dropped so much as expired by >entropy. The idea of having an MD5 signature for each TCP segment I think was Tony's, related to me about 4.5 years ago. Don't know if he was thinking about carrying it in an option, but that's how it turned out. The draft has been resubmitted, with an extra paragraph or two about the use of MD5 as the hash algorithm. We'll see what we can do about (finally) turning it into an RFC of some flavor. From owner-idr@merit.edu Tue Dec 2 00:08:13 1997 Delivery-Date: Tue, 02 Dec 1997 00:08:14 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id AAA25377 for ; Tue, 2 Dec 1997 00:08:13 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id AAA06098 for ; Tue, 2 Dec 1997 00:11:06 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA02958 for idr-outgoing; Mon, 1 Dec 1997 23:30:15 -0500 (EST) Received: from rip.psg.com (root@rip.psg.com [147.28.0.39]) by merit.edu (8.8.7/8.8.5) with SMTP id XAA02949 for ; Mon, 1 Dec 1997 23:30:10 -0500 (EST) Received: by rip.psg.com id m0xcjyI-0007zWC; Mon, 1 Dec 97 20:30 PST (Smail3.1.29.1#1) Message-Id: Date: Mon, 1 Dec 97 20:30 PST MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Tony Li Cc: idr@merit.edu Subject: Re: a draft that missed the deadline References: <199712011635.LAA01103@clipper.hq.tis.com> <199712012121.NAA10432@chimp.juniper.net> Sender: owner-idr@merit.edu Precedence: bulk > that there's a Best Current Practice and it's pretty much a requirement > today and there's no current documentation of it. there is code and a lot of us, at least the more prudent ones, are running it. what stands in the way of getting the document revived and out? randy From owner-idr@merit.edu Tue Dec 2 03:12:14 1997 Delivery-Date: Tue, 02 Dec 1997 03:12:14 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA26345 for ; Tue, 2 Dec 1997 03:12:13 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA06394 for ; Tue, 2 Dec 1997 03:15:07 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA05724 for idr-outgoing; Tue, 2 Dec 1997 02:47:36 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id CAA05720 for ; Tue, 2 Dec 1997 02:47:30 -0500 (EST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id XAA07487; Mon, 1 Dec 1997 23:46:59 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id XAA11770; Mon, 1 Dec 1997 23:47:03 -0800 (PST) Date: Mon, 1 Dec 1997 23:47:03 -0800 (PST) Message-Id: <199712020747.XAA11770@chimp.juniper.net> From: Tony Li To: ahh@cisco.com CC: idr@merit.edu, sandy@tis.com In-reply-to: <199712020434.UAA06763@stilton.cisco.com> (message from Andy Heffernan on Mon, 1 Dec 1997 20:34:59 -0800) Subject: Re: a draft that missed the deadline Sender: owner-idr@merit.edu Precedence: bulk The idea of having an MD5 signature for each TCP segment I think was Tony's, related to me about 4.5 years ago. Don't know if he was thinking about carrying it in an option, but that's how it turned out. Well, if you say so. I don't remember it but I'll take the blame if you'll take the credit. Tony From owner-idr@merit.edu Tue Dec 2 17:24:57 1997 Delivery-Date: Tue, 02 Dec 1997 17:24:59 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA06408 for ; Tue, 2 Dec 1997 17:24:52 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA10010 for ; Tue, 2 Dec 1997 17:27:47 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA18448 for idr-outgoing; Tue, 2 Dec 1997 16:48:09 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA18444 for ; Tue, 2 Dec 1997 16:48:05 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id QAA24663; Tue, 2 Dec 1997 16:45:57 -0500 (EST) Message-Id: <199712022145.QAA24663@brookfield.ans.net> To: Vivian_Lu@NetEdge.COM (Vivian_Lu) cc: idr@merit.edu, sbar@portal.netedge.com Reply-To: curtis@ans.net Subject: Re: third party nexthop In-reply-to: Your message of "Mon, 24 Nov 1997 16:24:36 EST." <199711242124.QAA07539@NetEdge.COM> Date: Tue, 02 Dec 1997 16:45:57 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <199711242124.QAA07539@NetEdge.COM>, Vivian_Lu writes: > > > My question is when and how does this get used in the real world scenario? Major providers at a major interconnect. > why will there be a need of a IBGP and EBGP running on two different machines > on the same subnet? Redundancy. One or more providers may have two or more routers each on the same media. > and how many vendors actually enforce this checking? I don't know of any that don't enforce this. It can be overridden for multihop EBGP but that's a hack used more for testing and for some very ugly hacks. Curtis From owner-idr@merit.edu Tue Dec 2 17:50:07 1997 Delivery-Date: Tue, 02 Dec 1997 17:50:12 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA06707 for ; Tue, 2 Dec 1997 17:50:02 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA10128 for ; Tue, 2 Dec 1997 17:52:59 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA18927 for idr-outgoing; Tue, 2 Dec 1997 17:18:45 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA18923 for ; Tue, 2 Dec 1997 17:18:39 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id RAA24764; Tue, 2 Dec 1997 17:16:56 -0500 (EST) Message-Id: <199712022216.RAA24764@brookfield.ans.net> To: Tony Li cc: Vivian_Lu@NetEdge.COM (Vivian_Lu), idr@merit.edu, sbar@portal.netedge.com Reply-To: curtis@ans.net Subject: Re: third party nexthop In-reply-to: Your message of "24 Nov 1997 15:12:41 PST." <82afetzy1i.fsf@chimp.juniper.net> Date: Tue, 02 Dec 1997 17:16:56 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <82afetzy1i.fsf@chimp.juniper.net>, Tony Li writes: > > I'm not aware of anyone who actually makes use of this as the redundancy in > this mechanism is somewhat lacking... Tony, Didn't Barrnet have 6-8 peers with enss128 at Hayward in the old NSFNET days and send tons of third party routes? I thought for a while you wrote the BGP code on the Barrnet side of this and I wrote the BGP code on the NSFNET side. (Senility? Yours or mine? :) Still goes on today. We have two routers at some NAPs and two or more at some private interconnects and so do other providers. In any case, you do need to implement third party routing and you do need to get it right and the quoted section of the RFC is correct. Cheers, Curtis From owner-idr@merit.edu Tue Dec 2 18:00:56 1997 Delivery-Date: Tue, 02 Dec 1997 18:00:57 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA06814 for ; Tue, 2 Dec 1997 18:00:56 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA10171 for ; Tue, 2 Dec 1997 18:03:52 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA19089 for idr-outgoing; Tue, 2 Dec 1997 17:26:35 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA19085 for ; Tue, 2 Dec 1997 17:26:32 -0500 (EST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id OAA24787; Tue, 2 Dec 1997 14:23:55 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id OAA13476; Tue, 2 Dec 1997 14:23:58 -0800 (PST) Date: Tue, 2 Dec 1997 14:23:58 -0800 (PST) Message-Id: <199712022223.OAA13476@chimp.juniper.net> From: Tony Li To: curtis@ans.net CC: Vivian_Lu@NetEdge.COM, idr@merit.edu, sbar@portal.netedge.com In-reply-to: <199712022216.RAA24764@brookfield.ans.net> (message from Curtis Villamizar on Tue, 02 Dec 1997 17:16:56 -0500) Subject: Re: third party nexthop Sender: owner-idr@merit.edu Precedence: bulk Curtis, Didn't Barrnet have 6-8 peers with enss128 at Hayward in the old NSFNET days and send tons of third party routes? I thought for a while you wrote the BGP code on the Barrnet side of this and I wrote the BGP code on the NSFNET side. (Senility? Yours or mine? :) Well, it's definitely senility cause I don't know of an ENSS that was ever at Hayward. Stanford, yes.... ;-) I don't dispute that the code is out there to support it. I just don't know of people using it. Still goes on today. Ok, I sit educated. ;-) Tony From owner-idr@merit.edu Tue Dec 2 19:54:42 1997 Delivery-Date: Tue, 02 Dec 1997 19:54:42 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA07761 for ; Tue, 2 Dec 1997 19:54:41 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA10531 for ; Tue, 2 Dec 1997 19:57:31 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA19749 for idr-outgoing; Tue, 2 Dec 1997 17:58:28 -0500 (EST) Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA19745 for ; Tue, 2 Dec 1997 17:58:23 -0500 (EST) Received: from gen1.uu.net by relay5.UU.NET with ESMTP (peer crosschecked as: gen1.uu.net [153.39.49.138]) id QQdsfz28345; Tue, 2 Dec 1997 17:58:12 -0500 (EST) Received: from aotearoa.uu.net by gen1.uu.net with ESMTP (peer crosschecked as: aotearoa.UU.NET [153.39.253.124]) id QQdsfz11374; Tue, 2 Dec 1997 17:57:36 -0500 (EST) Received: from localhost by aotearoa.uu.net with SMTP (peer crosschecked as: sherk@localhost) id QQdsfz05054; Tue, 2 Dec 1997 17:57:34 -0500 (EST) Message-Id: To: Tony Li cc: curtis@ans.net, Vivian_Lu@NetEdge.COM, idr@merit.edu, sbar@portal.netedge.com Subject: Re: third party nexthop In-reply-to: Your message of "Tue, 02 Dec 1997 14:23:58 PST." <199712022223.OAA13476@chimp.juniper.net> Date: Tue, 02 Dec 1997 17:57:34 -0500 From: Erik Sherk Sender: owner-idr@merit.edu Precedence: bulk > > Curtis, > > Didn't Barrnet have 6-8 peers with enss128 at Hayward in the old > NSFNET days and send tons of third party routes? I thought for a > while you wrote the BGP code on the Barrnet side of this and I wrote > the BGP code on the NSFNET side. (Senility? Yours or mine? :) > > Well, it's definitely senility cause I don't know of an ENSS that was ever > at Hayward. Stanford, yes.... ;-) We certainly used it on ENSS136. Jeez, what does it say when I can remember that number, but can't remember what my wife wants me to pick up at the store tonight? Must be Senility :-) > I don't dispute that the code is out there to support it. I just don't > know of people using it. > > Still goes on today. Yes, we use it extensivly today, mainly in a BGP confederation context. Erik > Ok, I sit educated. ;-) > > Tony From owner-idr@merit.edu Wed Dec 3 15:00:29 1997 Delivery-Date: Wed, 03 Dec 1997 15:00:29 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA27583 for ; Wed, 3 Dec 1997 15:00:28 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA13885 for ; Wed, 3 Dec 1997 15:03:23 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA04177 for idr-outgoing; Wed, 3 Dec 1997 14:15:35 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA04173 for ; Wed, 3 Dec 1997 14:15:31 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id OAA28153; Wed, 3 Dec 1997 14:13:15 -0500 (EST) Message-Id: <199712031913.OAA28153@brookfield.ans.net> To: Tony Li cc: curtis@ans.net, Vivian_Lu@NetEdge.COM, idr@merit.edu, sbar@portal.netedge.com Reply-To: curtis@ans.net Subject: Re: third party nexthop In-reply-to: Your message of "Tue, 02 Dec 1997 14:23:58 PST." <199712022223.OAA13476@chimp.juniper.net> Date: Wed, 03 Dec 1997 14:13:15 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <199712022223.OAA13476@chimp.juniper.net>, Tony Li writes: > > Curtis, > > Didn't Barrnet have 6-8 peers with enss128 at Hayward in the old > NSFNET days and send tons of third party routes? I thought for a > while you wrote the BGP code on the Barrnet side of this and I wrote > the BGP code on the NSFNET side. (Senility? Yours or mine? :) > > Well, it's definitely senility cause I don't know of an ENSS that was ever > at Hayward. Stanford, yes.... ;-) Oops. Off by one hop. > I don't dispute that the code is out there to support it. I just don't > know of people using it. > > Still goes on today. > > Ok, I sit educated. ;-) The problems with partial connectivity in bridged or switched level 2 broadcast media have prompted many to disable third party routing using next-hop-self. Where problems have not occurred (for example, single level 2 switch without this sort of bug or physical level 2 segment. It is probably worth mentioning that it is a good idea to have a per peer configurable option to disable third party routing and substitute ones own interface address. Doesn't hurt to call that option next-hop-self since people are used to that name. > Tony Curtis From owner-idr@merit.edu Thu Dec 4 15:38:56 1997 Delivery-Date: Thu, 04 Dec 1997 15:38:56 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA25553 for ; Thu, 4 Dec 1997 15:38:50 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA18503 for ; Thu, 4 Dec 1997 15:41:45 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA25216 for idr-outgoing; Thu, 4 Dec 1997 15:04:30 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA25212 for ; Thu, 4 Dec 1997 15:04:26 -0500 (EST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id MAA24790; Thu, 4 Dec 1997 12:03:54 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id MAA18774; Thu, 4 Dec 1997 12:03:55 -0800 (PST) Date: Thu, 4 Dec 1997 12:03:55 -0800 (PST) Message-Id: <199712042003.MAA18774@chimp.juniper.net> From: Tony Li To: curtis@ans.net CC: ahh@cisco.com, tli@juniper.net, idr@merit.edu, sandy@tis.com In-reply-to: <199712042003.PAA02415@brookfield.ans.net> (message from Curtis Villamizar on Thu, 04 Dec 1997 15:03:05 -0500) Subject: Re: a draft that missed the deadline Sender: owner-idr@merit.edu Precedence: bulk I think the T1 NSS routers had MD4 signatures before that so that probably means we get to blame Yakov for the idea. Oh, whew. ;-) Tony From owner-idr@merit.edu Thu Dec 4 15:44:19 1997 Delivery-Date: Thu, 04 Dec 1997 15:44:19 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA25670 for ; Thu, 4 Dec 1997 15:44:17 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA18516 for ; Thu, 4 Dec 1997 15:47:12 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA25191 for idr-outgoing; Thu, 4 Dec 1997 15:03:21 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA25187 for ; Thu, 4 Dec 1997 15:03:16 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id PAA02415; Thu, 4 Dec 1997 15:03:05 -0500 (EST) Message-Id: <199712042003.PAA02415@brookfield.ans.net> To: Andy Heffernan cc: tli@juniper.net, idr@merit.edu, sandy@tis.com Reply-To: curtis@ans.net Subject: Re: a draft that missed the deadline In-reply-to: Your message of "Mon, 01 Dec 1997 20:34:59 PST." <199712020434.UAA06763@stilton.cisco.com> Date: Thu, 04 Dec 1997 15:03:05 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <199712020434.UAA06763@stilton.cisco.com>, Andy Heffernan writes: > In article <199712012121.NAA10432@chimp.juniper.net> you write: > > > >Sandy, > > > > I am well aware of Andy Heffernan's work (which I thought you also had > > a hand in, judging by our conversations about TCP RST's). I did not > > mention it because, as you said, the work had been dropped from the > > IETF working group active consideration. > > > >Well, I don't believe that it was actively dropped so much as expired by > >entropy. > > The idea of having an MD5 signature for each TCP segment I think was > Tony's, related to me about 4.5 years ago. Don't know if he was > thinking about carrying it in an option, but that's how it turned out. > > The draft has been resubmitted, with an extra paragraph or two about > the use of MD5 as the hash algorithm. We'll see what we can do about > (finally) turning it into an RFC of some flavor. I think the T1 NSS routers had MD4 signatures before that so that probably means we get to blame Yakov for the idea. Curtis From owner-idr@merit.edu Thu Dec 4 21:48:00 1997 Delivery-Date: Thu, 04 Dec 1997 21:48:00 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA00861 for ; Thu, 4 Dec 1997 21:48:00 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA20247 for ; Thu, 4 Dec 1997 21:50:55 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA00911 for idr-outgoing; Thu, 4 Dec 1997 21:16:52 -0500 (EST) Received: from stilton.cisco.com (stilton.cisco.com [171.69.1.161]) by merit.edu (8.8.7/8.8.5) with SMTP id VAA00907 for ; Thu, 4 Dec 1997 21:16:48 -0500 (EST) Received: from cisco.com (localhost.cisco.com [127.0.0.1]) by stilton.cisco.com (8.6.12/8.6.5) with ESMTP id SAA27899; Thu, 4 Dec 1997 18:16:16 -0800 Message-Id: <199712050216.SAA27899@stilton.cisco.com> To: idr@merit.edu cc: ahh@cisco.com Subject: Re: a draft that missed the deadline In-reply-to: Message from Curtis Villamizar of "Thu, 04 Dec 1997 15:03:05 EST." <199712042003.PAA02415@brookfield.ans.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Thu, 04 Dec 1997 18:16:16 -0800 From: Andy Heffernan Sender: owner-idr@merit.edu Precedence: bulk [...] > I think the T1 NSS routers had MD4 signatures before that so that > probably means we get to blame Yakov for the idea. > > Curtis Since we're in the pre-IETF quiet-time period now, here's the TCP MD5 draft as it I plan to submit it after December 7. It's been renamed and revised a bit to make it more obvious that its intended use is to protect BGP sessions. I won't be at the IETF, but Pedro Marques will do a short presentation on this, and should be able to answer questions about it (as will other folks who will be there). INTERNET-DRAFT Andy Heffernan cisco Systems December 1, 1997 Protection of BGP Sessions via the TCP MD5 Signature Option Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any Internet Draft. Abstract This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in a TCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points. Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP. This document specifies an experimental protocol for use in the Internet. 1.0 Introduction The primary motivation for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. Of particular concern are TCP resets. To spoof a connection using the scheme described in this paper, an attacker would not only have to guess TCP sequence numbers, but would also have had to obtain the password included in the MD5 digest. This password never appears in the connection stream, and the actual Heffernan Expires June 1, 1998 [Page 1] INTERNET-DRAFT TCP MD5 Signature Option December 1, 1997 form of the password is up to the application. It could even change during the lifetime of a particular connection so long as this change was synchronized on both ends (although retransmission can become problematical in some TCP implementations with changing passwords). Finally, there is no negotiation for the use of this option in a connection, rather it is purely a matter of site policy whether or not its connections use the option. 2.0 Proposal Every segment sent on a TCP connection to be protected against spoofing will contain the 16-byte MD5 digest produced by applying the MD5 algorithm to these items in the following order: 1. the TCP pseudo-header (in the order: source IP address, destination IP address, zero-padded protocol number, and segment length) 2. the TCP header, excluding options, and assuming a checksum of zero 3. the TCP segment data (if any) 4. an independently-specified key or password, known to both TCPs and presumably connection-specific The header and pseudo-header are in network byte order. The nature of the key is deliberately left unspecified, but it must be known by both ends of the connection. A particular TCP implementation will determine what the application may specify as the key. Upon receiving a signed segment, the receiver must validate it by calculating its own digest from the same data (using its own key) and comparing the two digest. A failing comparison must result in the segment being dropped and must not produce any response back to the sender. Logging the failure is probably advisable. Unlike other TCP extensions (e.g., the Window Scale option [RFC1323])), the absence of the option in the SYN,ACK segment must not cause the sender to disable its sending of signatures. This negotiation is typically done to prevent some TCP implementations from misbehaving upon receiving options in non-SYN segments. This is not a problem for this option, since the SYN,ACK sent during connection negotiation will not be signed and will thus be ignored. The connection will never be made, and non-SYN segments with options will never be sent. More importantly, the sending of signatures must be under the complete control of the application, not at the mercy of the remote host not understanding the option. 3.0 Syntax Heffernan Expires June 1, 1998 [Page 2] INTERNET-DRAFT TCP MD5 Signature Option December 1, 1997 The proposed option has the following format: +---------+---------+-------------------+ | Kind=19 |Length=18| MD5 digest... | +---------+---------+-------------------+ | | +---------------------------------------+ | | +---------------------------------------+ | | +-------------------+-------------------+ | | +-------------------+ The MD5 digest is always 16 bytes in length, and the option would appear in every segment of a connection. 4.0 Some Implications 4.1 Connectionless Resets A connectionless reset will be ignored by the receiver of the reset, since the originator of that reset does not know the key, and so cannot generate the proper signature for the segment. This means, for example, that connection attempts by a TCP which is generating signatures to a port with no listener will time out instead of being refused. Similarly, resets generated by a TCP in response to segments sent on a stale connection will also be ignored. Operationally this can be a problem since resets help BGP recover quickly from peer crashes. 4.2 Performance The performance hit in calculating digests may inhibit the use of this option. Some measurements of a sample implementation showed that on a 100 MHz R4600, generating a signature for simple ACK segment took an average of 0.0268 ms, while generating a signature for a data segment carrying 4096 bytes of data took 0.8776 ms on average. These times would be applied to both the input and output paths, with the input path also bearing the cost of a 16-byte compare. 4.3 TCP Header Size As with other options that are added to every segment, the size of the MD5 option must be factored into the MSS offered to the other Heffernan Expires June 1, 1998 [Page 3] INTERNET-DRAFT TCP MD5 Signature Option December 1, 1997 side during connection negotiation. Specifically, the size of the header to subtract from the MTU (whether it is the MTU of the outgoing interface or IP's minimal MTU of 576 bytes) is now at least 18 bytes larger. The total header size is also an issue. The TCP header specifies where segment data starts with a 4-bit field which gives the total size of the header (including options) in 32-byte words. This means that the total size of the header plus option must be less than or equal to 60 bytes -- this leaves 40 bytes for options. As a concrete example, 4.4BSD defaults to sending window-scaling and timestamp information for connections it initiates. The most loaded segment will be the initial SYN packet to start the connection. With MD5 signatures, the SYN packet will contain the following: -- 4 bytes MSS option -- 4 bytes window scale option (3 bytes padded to 4 in 4.4BSD) -- 12 bytes for timestamp (4.4BSD pads the option as recommended in RFC 1323 Appendix A) -- 18 bytes for MD5 digest -- 2 bytes for end-of-option-list, to pad to a 32-bit boundary. This sums to 40 bytes, which just makes it. 4.4 MD5 as a Hashing Algorithm Since this draft was first issued (under a different title), the MD5 algorithm has been found to be vulnerable to collision search attacks [Dobb], and is considered by some to be insufficiently strong for this type of application. This draft still specifies the MD5 algorithm, however, since the option has already been deployed operationally, and there was no "algorithm type" field defined to allow an upgrade using the same option number. The original draft did not specify a type field since this would require at least one more byte, and it was felt at the time that taking 19 bytes for the complete option (which would probably be padded to 20 bytes in TCP implementations) would be too much of a waste of the already limited option space. This does not prevent the deployment of another similar option which uses another hashing algorithm (like SHA-1). Also, if most implementations pad the 18 byte option as defined to 20 bytes anyway, it would be just as well to define a new option which contains an algorithm type field. This would need to be addressed in another draft, however. Heffernan Expires June 1, 1998 [Page 4] INTERNET-DRAFT TCP MD5 Signature Option December 1, 1997 5.0 References [RFC1321] Rivest, R, "The MD5 Message-Digest Algorithm," RFC 1321, MIT Laboratory for Computer Science, April 1992. [RFC1323] Jacobson, V., Braden, R, and D. Borman, "TCP Extensions for High Performance", RFC 1323, LBL, USC/Information Sciences Institute, Cray Research, May 1992. [Dobb] H. Dobbertin, "The Status of MD5 After a Recent Attack", RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996. http://www.rsa.com/rsalabs/pubs/cryptobytes.html Author's Address Andy Heffernan cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408 526-8115 Email: ahh@cisco.com Heffernan Expires June 1, 1998 [Page 5] From owner-idr@merit.edu Fri Dec 5 01:10:06 1997 Delivery-Date: Fri, 05 Dec 1997 01:10:07 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id BAA09443 for ; Fri, 5 Dec 1997 01:10:06 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id BAA20597 for ; Fri, 5 Dec 1997 01:13:00 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id AAA02752 for idr-outgoing; Fri, 5 Dec 1997 00:47:39 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id AAA02748 for ; Fri, 5 Dec 1997 00:47:34 -0500 (EST) Received: from dakine.juniper.net (dakine.juniper.net [208.197.169.212]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id VAA08304; Thu, 4 Dec 1997 21:47:04 -0800 (PST) Received: from dakine.juniper.net (localhost.juniper.net [127.0.0.1]) by dakine.juniper.net (8.8.7/8.7.3) with ESMTP id VAA20576; Thu, 4 Dec 1997 21:47:03 -0800 (PST) Message-Id: <199712050547.VAA20576@dakine.juniper.net> To: sandy@tis.com, idr@merit.edu Cc: cole@juniper.net Subject: Re: [jnx.ext.ietf.idr] Re: a draft that missed the deadline In-reply-to: Your message of "04 Dec 1997 21:41:12 PST." <74sos8cpon.fsf@dakine.juniper.net> Date: Thu, 04 Dec 1997 21:47:02 -0800 From: Bruce Cole Sender: owner-idr@merit.edu Precedence: bulk > Be that as it may, I saw several messages in September between Ran > Atkinson and Jeff Schiller about that draft, suggesting that it might > be resurrected for publication as an Informational RFC. Do you know > anything more about that? Yes, that discussion would have been in response to the completion of my interoperable implementation of TCP MD5. Last I heard Jeff was supposedly planning to revive Andy's draft. From owner-idr@merit.edu Fri Dec 5 11:51:01 1997 Delivery-Date: Fri, 05 Dec 1997 11:51:02 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA17028 for ; Fri, 5 Dec 1997 11:51:01 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA22145 for ; Fri, 5 Dec 1997 11:53:55 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA08882 for idr-outgoing; Fri, 5 Dec 1997 11:06:17 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA08872 for ; Fri, 5 Dec 1997 11:06:12 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id LAA06116; Fri, 5 Dec 1997 11:06:09 -0500 (EST) Message-Id: <199712051606.LAA06116@brookfield.ans.net> To: Andy Heffernan cc: idr@merit.edu Reply-To: curtis@ans.net Subject: Re: a draft that missed the deadline In-reply-to: Your message of "Thu, 04 Dec 1997 18:16:16 PST." <199712050216.SAA27899@stilton.cisco.com> Date: Fri, 05 Dec 1997 11:06:09 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <199712050216.SAA27899@stilton.cisco.com>, Andy Heffernan writes: > [...] > > I think the T1 NSS routers had MD4 signatures before that so that > > probably means we get to blame Yakov for the idea. > > > > Curtis > > Since we're in the pre-IETF quiet-time period now, here's the TCP MD5 > draft as it I plan to submit it after December 7. It's been renamed > and revised a bit to make it more obvious that its intended use is to > protect BGP sessions. > > I won't be at the IETF, but Pedro Marques will do a short presentation > on this, and should be able to answer questions about it (as will > other folks who will be there). Andy, Thanks for the early copy. It might be good to move this forward as informational of BCP to document an existing implementation and do something a bit stronger later. Curtis From owner-idr@merit.edu Mon Dec 8 16:48:29 1997 Delivery-Date: Mon, 08 Dec 1997 16:48:29 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA16118 for ; Mon, 8 Dec 1997 16:48:24 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA04803 for ; Mon, 8 Dec 1997 16:51:19 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA16801 for idr-outgoing; Mon, 8 Dec 1997 16:01:56 -0500 (EST) Received: from portal.netedge.com (portal.netedge.com [199.170.8.2]) by merit.edu (8.8.7/8.8.5) with SMTP id QAA16789 for ; Mon, 8 Dec 1997 16:01:29 -0500 (EST) Received: from NetEdge.COM by portal.netedge.com id AA29770; Mon, 8 Dec 97 16:00:44 EST Received: from bertha2.NetEdge.COM by NetEdge.COM id AA14298; Mon, 8 Dec 97 16:00:30 EST Received: by bertha2.NetEdge.COM (SMI-8.6/NESCL-5.3) id QAA18633; Mon, 8 Dec 1997 16:00:52 -0500 Date: Mon, 8 Dec 1997 16:00:52 -0500 From: Vivian_Lu@NetEdge.COM (Vivian_Lu) Message-Id: <199712082100.QAA18633@NetEdge.COM> To: idr@merit.edu Subject: Re: third party nexthop X-Sun-Charset: US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Hi all, Thanks to all the feedback to my question. They have been very helpful. Vivian. > From Vivian_Lu@NetEdge.COM Mon Nov 24 16:57:01 1997 > Date: Mon, 24 Nov 1997 16:24:36 -0500 > From: Vivian_Lu@NetEdge.COM (Vivian_Lu) > To: idr@merit.edu > Subject: third party nexthop > Cc: sbar@portal.NetEdge.COM > X-Sun-Charset: US-ASCII > Sender: owner-idr@merit.edu > Content-Length: 2468 > > > Hi, > > We are currently implementing bgp4, and have the following questions. > > In the latest draft, (section 5.1.3 NEXT_HOP) > > "The NEXT_HOP path attribute defines the IP address of the border > router that should be used as the next hop to the destinations listed > in the UPDATE message. When advertising a NEXT_HOP attribute to an > external peer, a router may use one of its own interface addresses in > the NEXT_HOP attribute provided the external peer to which the route > is being advertised shares a common subnet with the NEXT_HOP address. > This is known as a "first party" NEXT_HOP attribute. A BGP speaker > ^^^^^^^^^^^^^ > can advertise to an external peer an interface of any internal peer > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > router in the NEXT_HOP attribute provided the external peer to which > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > the route is being advertised shares a common subnet with the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > NEXT_HOP address. This is known as a "third party" NEXT_HOP > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > attribute. A BGP speaker can advertise any external peer router in > ^^^^^^^^^ > the NEXT_HOP attribute provided that the IP address of this border > router was learned from an external peer and the external peer to > which the route is being advertised shares a common subnet with the > NEXT_HOP address. This is a second form of "third party" NEXT_HOP > attribute." > > It seems to me with the underlined restriction in the "third party" > NEXT_HOP case, the internal peer whose interface address is advertised > in the NEXT_HOP attribute by the BGP speaker must be on the same subnet > as BGP speaker and its external peer. > > My question is when and how does this get used in the real world scenario? > why will there be a need of a IBGP and EBGP running on two different machines > on the same subnet? > and how many vendors actually enforce this checking? > > Your help is very much appreciated. > > Vivian. > ------------------------------------------------------------------------ > Vivian H. Lu E-MAIL: vlu@netedge.com > NetEdge Systems, Inc. PHONE: (508)670-2934 > 85 Rangeway Road, FAX: (508)262-0802 > Billerica, Massachusetts. > ------------------------------------------------------------------------ > > > From owner-idr@merit.edu Thu Dec 11 17:09:01 1997 Delivery-Date: Thu, 11 Dec 1997 17:09:15 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA27699 for ; Thu, 11 Dec 1997 17:09:00 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA18614 for ; Thu, 11 Dec 1997 17:11:55 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA11740 for idr-outgoing; Thu, 11 Dec 1997 16:35:46 -0500 (EST) Received: from palrel3.hp.com (palrel3.hp.com [156.153.255.219]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA11735 for ; Thu, 11 Dec 1997 16:35:22 -0500 (EST) Received: from ptcmtls1.montreal.hp.com (ptcmtls1.montreal.hp.com [15.37.153.205]) by palrel3.hp.com (8.8.5/8.8.5tis) with ESMTP id NAA23722 for ; Thu, 11 Dec 1997 13:35:15 -0800 (PST) Received: (from ken@localhost) by ptcmtls1.montreal.hp.com (8.7.6/8.7.3 TIS 5.0) id QAA17143 for idr@merit.edu; Thu, 11 Dec 1997 16:32:42 -0500 (EST) From: "Ken Rosenfeld" Message-Id: <9712111632.ZM17141@ptcmtls1.montreal.hp.com> Date: Thu, 11 Dec 1997 16:32:41 -0500 X-Mailer: Z-Mail (3.2.1 10oct95) To: idr@merit.edu Subject: Route Dampening: How is a "route" defined? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-idr@merit.edu Precedence: bulk In the context of route dampening, how is a "route" defined? states (p. 13): "A route here is considered to be a tuple containing at least NLRI prefix, next hop, and AS path." I think the cisco IOS 11.2 implementation has a different view. I did the following test: bgp simulator <------------> cisco router ------------- ------------ announce 178.0.0.0 next-hop=192.1.1.3 AS_PATH={2 51 78 34 89} withdraw route penalty assigned announce route penalty incremented withdraw route penalty > suppress limit announce route route suppressed withdraw route announce 178.0.0.0 this new route inherits next-hop=192.1.1.2 penalty of previous route and AS_PATH={2 102 10 101} is suppressed Thanks, Ken From owner-idr@merit.edu Thu Dec 11 22:09:25 1997 Delivery-Date: Thu, 11 Dec 1997 22:09:26 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA28524 for ; Thu, 11 Dec 1997 22:09:25 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA19250 for ; Thu, 11 Dec 1997 22:12:19 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA16569 for idr-outgoing; Thu, 11 Dec 1997 21:45:37 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA16565 for ; Thu, 11 Dec 1997 21:45:32 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id VAA29945; Thu, 11 Dec 1997 21:44:13 -0500 (EST) Message-Id: <199712120244.VAA29945@brookfield.ans.net> To: "Ken Rosenfeld" cc: idr@merit.edu Reply-To: curtis@ans.net Subject: Re: Route Dampening: How is a "route" defined? In-reply-to: Your message of "Thu, 11 Dec 1997 16:32:41 EST." <9712111632.ZM17141@ptcmtls1.montreal.hp.com> Date: Thu, 11 Dec 1997 21:44:13 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <9712111632.ZM17141@ptcmtls1.montreal.hp.com>, "Ken Rosenfeld" write s: > In the context of route dampening, how is a "route" defined? > > states (p. 13): > "A route here is considered to be a tuple containing at least > NLRI prefix, next hop, and AS path." > > I think the cisco IOS 11.2 implementation has a different view. > > I did the following test: > > bgp simulator <------------> cisco router > ------------- ------------ > > announce 178.0.0.0 > next-hop=192.1.1.3 > AS_PATH={2 51 78 34 89} > > withdraw route penalty assigned > announce route penalty incremented > withdraw route penalty > suppress limit > announce route route suppressed > withdraw route > > announce 178.0.0.0 this new route inherits > next-hop=192.1.1.2 penalty of previous route and > AS_PATH={2 102 10 101} is suppressed > > Thanks, > > Ken You are probably correct in pointing out that the definition or route or lack of needs to be more clearly stated in the route flap damping draft. In the beginning of section 4.4.3 the draft states (mid page 11 in the PS version, page 13 in the text version) The following information must be maintained per route. A route here is considered to be a tuple containing at least NLRI prefix, next hop, and AS path. The tuple may also contain other BGP attributes such as MULTI_EXIT_DISCRIMINATOR (MED). This might almost be better conspicuously defined in a separate subsection with: A route is defined as: NLRI prefix required length required AS path required next hop optional MED optional I'm not sure what other BPG attributes you might consider damping on. If someone can't keep a constant MED or next hop it is a likely an indication of instability in their IGP. OTOH you may prefer to not damp on next hop because you don't have to propogate the change further and you amy want to not damp on MED because you either don't have to propagate further if you use MED for only next hop resolution or at worst don't have to propagate the change beyond your own IGP. The draft is clear about only penalizing the down transition and not the up transition. I view Cisco's penalizing the up transition as a bug. I'll forward a message from the IEPG list that supports that assertion. Curtis From owner-idr@merit.edu Fri Dec 12 03:21:40 1997 Delivery-Date: Fri, 12 Dec 1997 03:21:40 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA08296 for ; Fri, 12 Dec 1997 03:21:39 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA19710 for ; Fri, 12 Dec 1997 03:24:30 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA19184 for idr-outgoing; Fri, 12 Dec 1997 02:53:31 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id CAA19180 for ; Fri, 12 Dec 1997 02:53:27 -0500 (EST) Received: from red.juniper.net (localhost.juniper.net [127.0.0.1]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id XAA27319; Thu, 11 Dec 1997 23:51:03 -0800 (PST) Message-Id: <199712120751.XAA27319@red.juniper.net> To: curtis@ans.net cc: "Ken Rosenfeld" , idr@merit.edu Subject: Re: Route Dampening: How is a "route" defined? In-reply-to: Your message of "Thu, 11 Dec 1997 21:44:13 EST." <199712120244.VAA29945@brookfield.ans.net> Date: Thu, 11 Dec 1997 23:51:03 -0800 From: Paul Traina Sender: owner-idr@merit.edu Precedence: bulk From: Curtis Villamizar Subject: Re: Route Dampening: How is a "route" defined? In message <9712111632.ZM17141@ptcmtls1.montreal.hp.com>, "Ken Rosenfeld" wri >>te s: > In the context of route dampening, how is a "route" defined? > > states (p. 13): > "A route here is considered to be a tuple containing at least > NLRI prefix, next hop, and AS path." > > I think the cisco IOS 11.2 implementation has a different view. > > I did the following test: > > bgp simulator <------------> cisco router > ------------- ------------ > > announce 178.0.0.0 > next-hop=192.1.1.3 > AS_PATH={2 51 78 34 89} > > withdraw route penalty assigned > announce route penalty incremented > withdraw route penalty > suppress limit > announce route route suppressed > withdraw route > > announce 178.0.0.0 this new route inherits > next-hop=192.1.1.2 penalty of previous route and > AS_PATH={2 102 10 101} is suppressed > > Thanks, > > Ken You are probably correct in pointing out that the definition or route or lack of needs to be more clearly stated in the route flap damping draft. In the beginning of section 4.4.3 the draft states (mid page 11 in the PS version, page 13 in the text version) The following information must be maintained per route. A route here is considered to be a tuple containing at least NLRI prefix, next hop, and AS path. The tuple may also contain other BGP attributes such as MULTI_EXIT_DISCRIMINATOR (MED). I like your current definition in the draft, and have no objections with clarifying it. I'm glad you made the MED and NEXT_HOP optional -- there are good reasons for including them, but there are some intuitively obvious concerns too. From owner-idr@merit.edu Mon Dec 15 21:41:40 1997 Delivery-Date: Mon, 15 Dec 1997 21:41:40 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA22677 for ; Mon, 15 Dec 1997 21:41:40 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA04894 for ; Mon, 15 Dec 1997 21:44:31 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA29182 for idr-outgoing; Mon, 15 Dec 1997 21:05:39 -0500 (EST) Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA29178 for ; Mon, 15 Dec 1997 21:05:35 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id SAA16234 for ; Mon, 15 Dec 1997 18:05:34 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id RAA25870 for ; Mon, 15 Dec 1997 17:57:12 -0800 (PST) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id RAA29792 for ; Mon, 15 Dec 1997 17:59:58 -0800 (PST) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id SAA18257; Mon, 15 Dec 1997 18:04:32 -0800 (PST) Date: Mon, 15 Dec 1997 18:04:32 -0800 (PST) Message-Id: <199712160204.SAA18257@lookout.nsd.3com.com> To: idr@merit.edu Subject: peering changes in BGP4+ Sender: owner-idr@merit.edu Precedence: bulk I was wondering on the usefulness of providing a mechanism which would allow one to manipulate peering on a per AF basis. If I am peering for multiple Address families on the same TCP connection, I might want to stop, start or reset peering for a particular address family without disrupting active peerings on other AFs. I don't know if such a mechanism would get used very often in practice. It depends on whether people would like to run BGP for more than one AF on the same TCP connection. Any thoughts ? Quaizar From owner-idr@merit.edu Tue Dec 16 14:15:31 1997 Delivery-Date: Tue, 16 Dec 1997 14:15:41 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA06511 for ; Tue, 16 Dec 1997 14:15:21 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA07788 for ; Tue, 16 Dec 1997 14:18:12 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA09704 for idr-outgoing; Tue, 16 Dec 1997 13:48:14 -0500 (EST) Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA09694 for ; Tue, 16 Dec 1997 13:47:56 -0500 (EST) Received: from localhost (enkechen@localhost) by trix.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id KAA14663; Tue, 16 Dec 1997 10:43:56 -0800 (PST) Message-Id: <199712161843.KAA14663@trix.cisco.com> To: "Ken Rosenfeld" cc: idr@merit.edu, enkechen@cisco.com Subject: Re: Route Dampening: How is a "route" defined? In-reply-to: Your message of "Thu, 11 Dec 1997 16:32:41 EST." <9712111632.ZM17141@ptcmtls1.montreal.hp.com> Date: Tue, 16 Dec 1997 10:43:56 -0800 From: Enke Chen Sender: owner-idr@merit.edu Precedence: bulk Ken, > Date: Thu, 11 Dec 1997 16:32:41 -0500 > From: "Ken Rosenfeld" > To: idr@merit.edu > In the context of route dampening, how is a "route" defined? > > states (p. 13): > "A route here is considered to be a tuple containing at least > NLRI prefix, next hop, and AS path." > > I think the cisco IOS 11.2 implementation has a different view. [deleted] It was a bug - a penalty was charged when a withdrawn prefix was re-announced. It has been fixed in 011.002(009.001) and many other versions. The related ddts's are: CSCdj45833 / CSCdj39433. -- Enke From owner-idr@merit.edu Tue Dec 16 18:04:48 1997 Delivery-Date: Tue, 16 Dec 1997 18:04:48 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA09395 for ; Tue, 16 Dec 1997 18:04:48 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA08913 for ; Tue, 16 Dec 1997 18:07:41 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA13622 for idr-outgoing; Tue, 16 Dec 1997 17:43:11 -0500 (EST) Received: from smtp-gw.BayNetworks.COM (ns5.baynetworks.com [194.133.90.101]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA13618 for ; Tue, 16 Dec 1997 17:43:06 -0500 (EST) Received: from mailhost.BayNetworks.COM (occhio.BayNetworks.COM [194.133.90.100]) by smtp-gw.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id XAA11840 for ; Tue, 16 Dec 1997 23:42:12 +0100 (MET) Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id XAA09998 for ; Tue, 16 Dec 1997 23:42:08 +0100 (MET) Received: from greenfield.engeast.baynetworks.com (dhcp139-233 [192.32.139.233]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id RAA19506; Tue, 16 Dec 1997 17:42:07 -0500 for Message-Id: <3.0.1.32.19971216174207.006bd13c@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Tue, 16 Dec 1997 17:42:07 -0500 To: idr@merit.edu From: Dimitry Haskin Subject: Re: Last Call (draft-ietf-idr-bgp4-ipv6-00.txt) Cc: dhaskin@baynetworks.com In-Reply-To: <199712140001.QAA19197@puli.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idr@merit.edu Precedence: bulk Hi, 1) It is not necessary to *mandate* that a global scope address be always present in the Next Hop Network Address field of an IPv6 MP_REACH_NLRI attribute which is sent between external peers that share a common link. In certain peering arrangements a border router re-writes the Next Hop Address with one of its own addresses when disseminating external routes to internal peers. In such cases it is sufficient to advertise only link-local scope addresses between external bgp peers and sending a global scope address in addition to a link-local address serves no purpose and only adds to administrative burden. Rewriting the Next Hop Address by border routers has become a quite common practice in IPv4 BGP deployments and I believe it will be more so in IPv6 since it can make BGP peerings immune to renumbering in peering ASs. To summarize I request that advertising a global scope address in the Next Hop Network Address field of an IPv6 MP_REACH_NLRI attribute which is sent between external peers that share a common link be optional - i.e. a subject to the peering arrangement. 2) A nit: >From section 4: The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity ^^^^^^ identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to. "Subnet" should be replaced with "link". To use link-local addresses it is sufficient to share a link. Dimitry At 04:01 PM 12/13/97 PST, Yakov Rekhter wrote: >Folks, > >This is to start the WG Last Call on >draft-ietf-idr-bgp4-ipv6-00.txt. > >The Last Call ends 12/30. > >Yakov. > > From owner-idr@merit.edu Wed Dec 17 17:37:56 1997 Delivery-Date: Wed, 17 Dec 1997 17:37:57 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA27962 for ; Wed, 17 Dec 1997 17:37:56 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA12667 for ; Wed, 17 Dec 1997 17:40:50 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA27395 for idr-outgoing; Wed, 17 Dec 1997 17:00:47 -0500 (EST) Received: from idrp.merit.net (skh@idrp.merit.edu [198.108.60.89]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA27384; Wed, 17 Dec 1997 17:00:40 -0500 (EST) From: skh@merit.edu Date: Wed, 17 Dec 1997 17:00:39 -0500 (EST) Message-Id: <199712172200.RAA03949@idrp.merit.net> To: idr@merit.edu Subject: 1st draft of notes Cc: skh@merit.edu, yakov@cisco.com Sender: owner-idr@merit.edu Precedence: bulk Hi all: Here's my first rough draft on the working group notes. Please let me know is wrong. I'll be glad to fix it. Sue Hares =========== Notes Agenda: 1) Agenda Bashing 2) Status on Current Documents 3) Route Flap Damping (Curtis Villamizar) 4) BGP-4+ practice and experience for multicast (Dave Meyer) 5) To be Multihomed: Requirements and Definitions Howard Berkowitz 6) MD5 TCP for BGP (Pedro Marques) 7) BGP Security Analysis (Sandy Murphy) 8) Use of MD5 for BGP Authentication (T. Przygienda) 9) BGP-4+ for IPv6 draft-ietf-idr-bgp4-ipv6-00.txt (Pedro Marques, F. Dupont) 10) Capability Negotiation values draft-marques-bgp-cap-mp-00.txt (Pedro Marques, F. Dupont) More Detailed Notes on the working group 1) Agenda Bashing 2) Status of Current Documents: Last Call - Multiprotocol Extensions for BGP-4 Sent to RFC Editor - Guidelines for AS 3) BGP Route Damping draft-ietf-idr-route-damp-00.txt presentation at: http://engr.ans.net/route-damp/route-damp-ietf.ps Discussion: Move to Working Group last call for 2 weeks, Release as Proposed standard. Change "fixed" timer in BGP-4 draft specification from "must" to may. 4) BGP-4+ practice and experience for multicast (Dave Meyer) No document, slides at: http Discussion about the needs of multicast: a) referred to "multicast" group for discussion of SAFI containing MRIB (unicast for Multicast routes) and GRIB (Class D addresses) b) Capability Negotiation request for the particular support of SAFI in multiprotocol option. 5) To Be Multihomed: Requirements and Definitions (H. Berkowitz) [presentation location needed] draft-berkowitz-multirqmt-00.txt Suggestion that the application documents be forwarded to the Operations area for review and publication of RFCs. Other reviews are possible in the following exterior communities: NANOG, IOPS, IEPG. 6) MD5 TCP for BGP (Pedro Marques) draft-heffenan-bgp-tcp-md5-00.txt will be re-issued as a working group draft for progression to Proposed Standard. A two week Last call will be issued after the draft has been publish on the mailing list. 7) BGP Security Analysis (Sandy Murphy) Sandy Murphy presented a security analysis of BGP as presented in RFC 1771. Discussion ensued on presentation. The note taker's high points were: A) for protecting the BGP to bgp authentication the options were: IPSEC TCP over MD5 (item 6) MD5 for BGP Authentication (item 8) IPSEC/TCP over MD5 provided protection against the RESET and SYN attacks. MD5 for BGP Authentication does not protect against RESET and SYN attacks. B) Any security of BGP from creating ISP to final ISP by means of signatures on UPdate packet information (ASPATH, nlri grouping) does: a) also require filtering at each point to ensure the necessary aspath-nlri is correct b) require a substantial investment in authentication administration for "signatures" The note taker requests additional feedback on this section of the meeting prior to producing the final minutes of the meeting. 8) Use of MD5 for BGP Authentication (T. Przygienda) draft-przygienda-bgp-md5-00.txt (presentation location required) 9) BGP-4+ for IPv6 draft-ietf-idr-bgp4-ipv6-00.txt (Pedro Marques, F. Dupont) Discussion: Discussion on the mailing list has raised Dimitry Haskin's concerns about the requirement for Global addresses. There is no clear consensus that this is a problem. Code implementation require the global addresses. The Document will go to Last Call on the Working Group list prior to being forward on Proposed Standard track. 10) Capability Negotiation Option for IPv6 draft-marques-bgp-cap-mp-00.txt Discussion: Capability option seems reasonable, but must await the forwarding of the Capability Options processing to proceed forward along the standards track. Once the Capability Options have been forwarded, this document will go to the working group for last call. From owner-idr@merit.edu Wed Dec 17 18:33:19 1997 Delivery-Date: Wed, 17 Dec 1997 18:33:19 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA28278 for ; Wed, 17 Dec 1997 18:33:18 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA12939 for ; Wed, 17 Dec 1997 18:36:11 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA28351 for idr-outgoing; Wed, 17 Dec 1997 18:08:27 -0500 (EST) Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA28347; Wed, 17 Dec 1997 18:08:23 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id PAA06053; Wed, 17 Dec 1997 15:08:21 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id OAA03758; Wed, 17 Dec 1997 14:59:41 -0800 (PST) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id PAA09516; Wed, 17 Dec 1997 15:02:22 -0800 (PST) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id PAA18821; Wed, 17 Dec 1997 15:07:15 -0800 (PST) Date: Wed, 17 Dec 1997 15:07:15 -0800 (PST) Message-Id: <199712172307.PAA18821@lookout.nsd.3com.com> To: skh@merit.edu Cc: idr@merit.edu Subject: 1st draft of notes In-Reply-To: <199712172200.RAA03949@idrp.merit.net> References: <199712172200.RAA03949@idrp.merit.net> Sender: owner-idr@merit.edu Precedence: bulk skh@merit.edu writes: > > 9) BGP-4+ for IPv6 > draft-ietf-idr-bgp4-ipv6-00.txt > (Pedro Marques, F. Dupont) > > Discussion: > Discussion on the mailing list has raised Dimitry Haskin's > concerns about the requirement for Global addresses. > There is no clear consensus that this is a problem. > Code implementation require the global addresses. > As I could not attend the last ietf meeting, could someone please explain me why code implementation requires global addresses. I would agree that they simplify an implementation by avoiding usage of link local or addresses of other scopes. Also since there are reasons for not making global addresses a requirement it would be more flexible to remove such a requirement till there is an operational experience which neccesitates global addresses. Quaizar From owner-idr@merit.edu Wed Dec 17 19:57:49 1997 Delivery-Date: Wed, 17 Dec 1997 19:57:49 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA29030 for ; Wed, 17 Dec 1997 19:57:45 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA13201 for ; Wed, 17 Dec 1997 20:00:38 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA29350 for idr-outgoing; Wed, 17 Dec 1997 19:26:56 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA29346; Wed, 17 Dec 1997 19:26:52 -0500 (EST) Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id QAA24420; Wed, 17 Dec 1997 16:26:15 -0800 (PST) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id QAA19814; Wed, 17 Dec 1997 16:26:14 -0800 (PST) Message-Id: <199712180026.QAA19814@base.juniper.net> To: Quaizar Vohra cc: skh@merit.edu, idr@merit.edu Subject: Re: 1st draft of notes In-reply-to: Your message of "Wed, 17 Dec 1997 15:07:15 PST." <199712172307.PAA18821@lookout.nsd.3com.com> Date: Wed, 17 Dec 1997 16:26:13 -0800 From: Paul Traina Sender: owner-idr@merit.edu Precedence: bulk There already is operational experience that demonstrates the desire for using addresses that are global throughout one administrative domain with BGP4. Using a global address gives you the ability to directly pin something to a neighbor's egress router instead of your ingress router. Unfortunately, there's no half-way point between LL and global, so the only way to carry this functionality forward is to use a global. Whether or not a global address is required is of interest to the receiving AS. It needs to be under the receiver's control. Therfore if you do not mandate it, you must mandate negotiation with the default being "send the global" which means you have to administratively assign a global address to that interface anyway. Either way you optimize, you lose. So I'd rather optimize in the direction of having more data available rather than worry about renumbering BGPv6 ebgp peers, which can be solved several other ways (such as assigning private (read: 1597) "global" addresses to your neighbors peers. In any case, link-local addresses are a crock that should be taken out back behind the barn and put down like a terminally ill animal. They should only exist when a box is in the process of learning it's place in the world. Thank you for your indulgence, Paul From owner-idr@merit.edu Thu Dec 18 15:59:00 1997 Delivery-Date: Thu, 18 Dec 1997 15:59:00 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA14108 for ; Thu, 18 Dec 1997 15:58:56 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA16534 for ; Thu, 18 Dec 1997 16:01:48 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA13167 for idr-outgoing; Thu, 18 Dec 1997 15:22:02 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA13161 for ; Thu, 18 Dec 1997 15:21:54 -0500 (EST) Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id MAA03451; Thu, 18 Dec 1997 12:21:23 -0800 (PST) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id MAA22909; Thu, 18 Dec 1997 12:21:23 -0800 (PST) Message-Id: <199712182021.MAA22909@base.juniper.net> To: Quaizar Vohra cc: idr@merit.edu Subject: Re: 1st draft of notes In-reply-to: Your message of "Thu, 18 Dec 1997 12:09:51 PST." <199712182009.MAA18961@lookout.nsd.3com.com> Date: Thu, 18 Dec 1997 12:21:23 -0800 From: Paul Traina Sender: owner-idr@merit.edu Precedence: bulk From: Quaizar Vohra Subject: Re: 1st draft of notes Thanks Paul for your explanation. I agree that global addresses makes toubleshooting easier and other scope addresses might make it a little more difficult. But I remember you saying that ingress routers very often change the external nexthop to their own addresses. If they don't extend their IGP to cover the DMZ, yes. That's the way we did it BGP3, but in BGP4 we decided to carry the neighbor's egress router by default because it gave you better shortcutting or metric checking ability. Allowing receiver to control whether xmitter uses global scoped address springs from the above need itself. So if the above need is absolutely neccesary then one should mandate use of global addresses (I don't have much operational experience :-)). I know that mandating of global addresses makes code simpler. I agree that private global addresses will make a better solution than link local addresses. I have one more question. Wouldn't it be useful to be able to disable or enable or reset peering for one address family over a TCP connection without disrupting peering for other address families, if multiple address family peerings are being done over the same TCP connection. As new IPv4 unicast peering takes around 10 to 15 minutes to become stable. Or one can live with this as reconfiguration happens very infrequently.Also in practise many AFs might not be run over the same TCP connecrion. I don't recall there being anything forcing BGP to run on top of IPV4... but I haven't read the spec in ages, so I am not qualified to comment. From owner-idr@merit.edu Thu Dec 18 15:59:07 1997 Delivery-Date: Thu, 18 Dec 1997 15:59:08 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA14114 for ; Thu, 18 Dec 1997 15:59:07 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA16537 for ; Thu, 18 Dec 1997 16:01:59 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA12944 for idr-outgoing; Thu, 18 Dec 1997 15:11:05 -0500 (EST) Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA12934 for ; Thu, 18 Dec 1997 15:10:58 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id MAA18961; Thu, 18 Dec 1997 12:10:56 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id MAA29466; Thu, 18 Dec 1997 12:02:08 -0800 (PST) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id MAA03638; Thu, 18 Dec 1997 12:04:48 -0800 (PST) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id MAA18961; Thu, 18 Dec 1997 12:09:51 -0800 (PST) Date: Thu, 18 Dec 1997 12:09:51 -0800 (PST) Message-Id: <199712182009.MAA18961@lookout.nsd.3com.com> To: Paul Traina CC: idr@merit.edu Subject: Re: 1st draft of notes In-Reply-To: <199712180026.QAA19814@base.juniper.net> References: <199712172307.PAA18821@lookout.nsd.3com.com> <199712180026.QAA19814@base.juniper.net> Sender: owner-idr@merit.edu Precedence: bulk Thanks Paul for your explanation. I agree that global addresses makes toubleshooting easier and other scope addresses might make it a little more difficult. But I remember you saying that ingress routers very often change the external nexthop to their own addresses. Allowing receiver to control whether xmitter uses global scoped address springs from the above need itself. So if the above need is absolutely neccesary then one should mandate use of global addresses (I don't have much operational experience :-)). I know that mandating of global addresses makes code simpler. I agree that private global addresses will make a better solution than link local addresses. I have one more question. Wouldn't it be useful to be able to disable or enable or reset peering for one address family over a TCP connection without disrupting peering for other address families, if multiple address family peerings are being done over the same TCP connection. As new IPv4 unicast peering takes around 10 to 15 minutes to become stable. Or one can live with this as reconfiguration happens very infrequently.Also in practise many AFs might not be run over the same TCP connecrion. Thanks Quaizar From owner-idr@merit.edu Thu Dec 18 16:17:16 1997 Delivery-Date: Thu, 18 Dec 1997 16:17:17 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id QAA14277 for ; Thu, 18 Dec 1997 16:17:16 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA16647 for ; Thu, 18 Dec 1997 16:20:08 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA13553 for idr-outgoing; Thu, 18 Dec 1997 15:47:08 -0500 (EST) Received: from janus.3com.com (janus.3com.com [129.213.128.99]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA13549 for ; Thu, 18 Dec 1997 15:47:03 -0500 (EST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by janus.3com.com (8.8.2/8.8.5) with ESMTP id MAA24003; Thu, 18 Dec 1997 12:47:01 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.2/8.8.5) with ESMTP id MAA05431; Thu, 18 Dec 1997 12:38:13 -0800 (PST) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.2/8.8.5) with ESMTP id MAA05104; Thu, 18 Dec 1997 12:40:52 -0800 (PST) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id MAA18970; Thu, 18 Dec 1997 12:45:54 -0800 (PST) Date: Thu, 18 Dec 1997 12:45:54 -0800 (PST) Message-Id: <199712182045.MAA18970@lookout.nsd.3com.com> To: Paul Traina Cc: Quaizar Vohra , idr@merit.edu Subject: Re: 1st draft of notes In-Reply-To: <199712182021.MAA22909@base.juniper.net> References: <199712182009.MAA18961@lookout.nsd.3com.com> <199712182021.MAA22909@base.juniper.net> Sender: owner-idr@merit.edu Precedence: bulk Paul Traina writes: > > I have one more question. Wouldn't it be useful to be able to disable > or enable or reset peering for one address family over a TCP > connection without disrupting peering for other address families, if > multiple address family peerings are being done over the same TCP > connection. As new IPv4 unicast peering takes around 10 to 15 minutes > to become stable. Or one can live with this as reconfiguration happens > very infrequently.Also in practise many AFs might not be run over the > same TCP connecrion. > > I don't recall there being anything forcing BGP to run on top of IPV4... > but I haven't read the spec in ages, so I am not qualified to comment. I think my question was not very clear. You are running BGP (either on top of IPv4 or IPv6), and you are exchanging, say for example IPv4 unicast as well as IPv6 unicast routes over the same TCP connection. If there are large number of routes, exchanging of these routes on a newly initiated peering can take quite a while (e.g. 10 - 15 minutes for current complete internet routes). So if you are exhanging routes for multiple AFs, it would be nice to enable, disable or reset peering on a per AF basis. Quaizar From owner-idr@merit.edu Thu Dec 18 17:52:33 1997 Delivery-Date: Thu, 18 Dec 1997 17:52:34 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA14935 for ; Thu, 18 Dec 1997 17:52:33 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA17051 for ; Thu, 18 Dec 1997 17:55:25 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA15780 for idr-outgoing; Thu, 18 Dec 1997 17:15:36 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA15776 for ; Thu, 18 Dec 1997 17:15:32 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id RAA23356; Thu, 18 Dec 1997 17:15:21 -0500 (EST) Message-Id: <199712182215.RAA23356@brookfield.ans.net> To: Quaizar Vohra cc: Paul Traina , idr@merit.edu Reply-To: curtis@ans.net Subject: Re: 1st draft of notes In-reply-to: Your message of "Thu, 18 Dec 1997 12:45:54 PST." <199712182045.MAA18970@lookout.nsd.3com.com> Date: Thu, 18 Dec 1997 17:15:21 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <199712182045.MAA18970@lookout.nsd.3com.com>, Quaizar Vohra writes: > > (e.g. 10 - 15 minutes for current complete internet routes). If it takes that long your router is seriously broken. :-( > I think my question was not very clear. You are running BGP > (either on top of IPv4 or IPv6), and you are exchanging, say > for example IPv4 unicast as well as IPv6 unicast routes over the > same TCP connection. If there are large number of routes, exchanging > of these routes on a newly initiated peering can take quite a while > if you are exhanging routes for multiple AFs, it would be nice to > enable, disable or reset peering on a per AF basis. > > Quaizar I do see your point though. This would fall under import or export policy. You should be able to change and export statement on a router and withdraw (or block the announcement of) either IPv4 or IPv6. This is outside of the scope of the protocol itself. Curtis From owner-idr@merit.edu Thu Dec 18 19:32:00 1997 Delivery-Date: Thu, 18 Dec 1997 19:32:00 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA15546 for ; Thu, 18 Dec 1997 19:32:00 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA17278 for ; Thu, 18 Dec 1997 19:34:51 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA17409 for idr-outgoing; Thu, 18 Dec 1997 19:08:58 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA17405 for ; Thu, 18 Dec 1997 19:08:54 -0500 (EST) Received: from base.juniper.net (base.juniper.net [208.197.169.208]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id QAA08142; Thu, 18 Dec 1997 16:08:23 -0800 (PST) Received: from base.juniper.net (localhost.juniper.net [127.0.0.1]) by base.juniper.net (8.8.7/8.7.3) with ESMTP id QAA23539; Thu, 18 Dec 1997 16:08:23 -0800 (PST) Message-Id: <199712190008.QAA23539@base.juniper.net> To: Quaizar Vohra cc: idr@merit.edu Subject: Re: 1st draft of notes In-reply-to: Your message of "Thu, 18 Dec 1997 12:45:54 PST." <199712182045.MAA18970@lookout.nsd.3com.com> Date: Thu, 18 Dec 1997 16:08:23 -0800 From: Paul Traina Sender: owner-idr@merit.edu Precedence: bulk From: Quaizar Vohra Subject: Re: 1st draft of notes Paul Traina writes: > > I have one more question. Wouldn't it be useful to be able to disable > or enable or reset peering for one address family over a TCP > connection without disrupting peering for other address families, if > multiple address family peerings are being done over the same TCP > connection. As new IPv4 unicast peering takes around 10 to 15 minutes > to become stable. Or one can live with this as reconfiguration happens > very infrequently.Also in practise many AFs might not be run over the > same TCP connecrion. > > I don't recall there being anything forcing BGP to run on top of IPV4... > but I haven't read the spec in ages, so I am not qualified to comment. I think my question was not very clear. You are running BGP (either on top of IPv4 or IPv6), and you are exchanging, say for example IPv4 unicast as well as IPv6 unicast routes over the same TCP connection. If there are large number of routes, exchanging of these routes on a newly initiated peering can take quite a while (e.g. 10 - 15 minutes for current complete internet routes). So if you are exhanging routes for multiple AFs, it would be nice to enable, disable or reset peering on a per AF basis. I thought that's what you meant. There's currently no mechanism in BGP to do that other than break the connection. Therefore if you were to want to do that, you'd tend to establish multiple BGP connections, and it would be logical (but not required) to run the IPv6 over the IPv6 connection and the IPv4 over the v4 connection. From owner-idr@merit.edu Fri Dec 19 15:24:50 1997 Delivery-Date: Fri, 19 Dec 1997 15:24:50 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA01245 for ; Fri, 19 Dec 1997 15:24:50 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA19937 for ; Fri, 19 Dec 1997 15:27:41 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA26975 for idr-outgoing; Fri, 19 Dec 1997 12:41:17 -0500 (EST) Received: from smtp-gw.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA26970 for ; Fri, 19 Dec 1997 12:41:13 -0500 (EST) Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by smtp-gw.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id JAA10898 for ; Fri, 19 Dec 1997 09:40:40 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id JAA14813; Fri, 19 Dec 1997 09:40:39 -0800 (PST) Received: from greenfield.engeast.baynetworks.com (dhcp139-233 [192.32.139.233]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id MAA00088; Fri, 19 Dec 1997 12:40:39 -0500 for Message-Id: <3.0.1.32.19971219124040.006c3bc4@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Dec 1997 12:40:40 -0500 To: Dimitry Haskin From: Dimitry Haskin Subject: Re: Last Call (draft-ietf-idr-bgp4-ipv6-00.txt) Cc: idr@merit.edu, dhaskin@baynetworks.com In-Reply-To: <3.0.1.32.19971216174207.006bd13c@pobox> References: <199712140001.QAA19197@puli.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idr@merit.edu Precedence: bulk Let me offer the text that I'd like to have inserted in the draft. Hopefully it will be more acceptable to all sides in the argument. "Implementations should be able to support disabling the advertisement of a global scope address in the Next Hop Network Address field of an IPv6 MP_REACH_NLRI attribute which is sent to an external peer. This capability should be only used when there is explicit knowledge that the external peer does not use the global scope next hop address in it operation (e.g. re-writes the Next Hop Address with one of its own addresses). By default, a global scope address shall be advertised in the Next Hop Network Address field of an IPv6 MP_REACH_NLRI attribute." Dimitry At 05:42 PM 12/16/97 -0500, Dimitry Haskin wrote: >Hi, > >1) It is not necessary to *mandate* that a global scope address be always >present in the Next Hop Network Address field of an IPv6 MP_REACH_NLRI >attribute which is sent between external peers that share a common link. >In certain peering arrangements a border router re-writes the Next Hop >Address with one of its own addresses when disseminating external routes to >internal peers. In such cases it is sufficient to advertise only link-local >scope addresses between external bgp peers and sending a global scope >address in addition to a link-local address serves no purpose and only adds >to administrative burden. > >Rewriting the Next Hop Address by border routers has become a quite common >practice in IPv4 BGP deployments and I believe it will be more so in IPv6 >since it can make BGP peerings immune to renumbering in peering ASs. > >To summarize I request that advertising a global scope address in the Next >Hop Network Address field of an IPv6 MP_REACH_NLRI attribute which is sent >between external peers that share a common link be optional - i.e. a >subject to the peering arrangement. > >2) A nit: > >>From section 4: > > The link-local address shall be included in the Next Hop field if and > only if the BGP speaker shares a common subnet with the entity > ^^^^^^ > identified by the global IPv6 address carried in the Network Address > of Next Hop field and the peer the route is being advertised to. > >"Subnet" should be replaced with "link". To use link-local addresses it is >sufficient to share a link. > >Dimitry > >At 04:01 PM 12/13/97 PST, Yakov Rekhter wrote: >>Folks, >> >>This is to start the WG Last Call on >>draft-ietf-idr-bgp4-ipv6-00.txt. >> >>The Last Call ends 12/30. >> >>Yakov. >> >> > > From owner-idr@merit.edu Fri Dec 19 17:58:36 1997 Delivery-Date: Fri, 19 Dec 1997 17:58:36 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA03221 for ; Fri, 19 Dec 1997 17:58:36 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA20481 for ; Fri, 19 Dec 1997 18:01:28 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA01778 for idr-outgoing; Fri, 19 Dec 1997 17:31:17 -0500 (EST) Received: from rhine.cisco.com (rhine.cisco.com [171.69.43.21]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA01774 for ; Fri, 19 Dec 1997 17:31:13 -0500 (EST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by rhine.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA29722; Fri, 19 Dec 1997 14:13:27 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id OAA05068; Fri, 19 Dec 1997 14:30:42 -0800 (PST) Date: Fri, 19 Dec 1997 14:30:42 -0800 (PST) Message-Id: <199712192230.OAA05068@pedrom-ultra.cisco.com> From: Pedro Marques To: Dimitry Haskin Cc: idr@merit.edu Subject: Re: Last Call (draft-ietf-idr-bgp4-ipv6-00.txt) In-Reply-To: <3.0.1.32.19971219124040.006c3bc4@pobox> References: <199712140001.QAA19197@puli.cisco.com> <3.0.1.32.19971216174207.006bd13c@pobox> <3.0.1.32.19971219124040.006c3bc4@pobox> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk >>>>> "Dimitry" == Dimitry Haskin writes: Dimitry> Let me offer the text that I'd like to have inserted in Dimitry> the draft. Hopefully it will be more acceptable to all Dimitry> sides in the argument. Dimitry> "Implementations should be able to support disabling the Dimitry> advertisement of a global scope address in the Next Hop Dimitry> Network Address field of an IPv6 MP_REACH_NLRI attribute Dimitry> which is sent to an external peer. So what would the nexthop look like ? Pedro. From owner-idr@merit.edu Fri Dec 19 19:15:22 1997 Delivery-Date: Fri, 19 Dec 1997 19:15:23 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA03579 for ; Fri, 19 Dec 1997 19:15:22 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA20686 for ; Fri, 19 Dec 1997 19:18:13 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA02760 for idr-outgoing; Fri, 19 Dec 1997 18:51:38 -0500 (EST) Received: from smtp-gw.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA02754 for ; Fri, 19 Dec 1997 18:51:34 -0500 (EST) Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by smtp-gw.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id PAA01665; Fri, 19 Dec 1997 15:51:00 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id PAA28543; Fri, 19 Dec 1997 15:50:58 -0800 (PST) Received: from greenfield.engeast.baynetworks.com (dhcp139-233 [192.32.139.233]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id SAA22042; Fri, 19 Dec 1997 18:50:57 -0500 for Message-Id: <3.0.1.32.19971219185058.006dc5f0@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Dec 1997 18:50:58 -0500 To: Pedro Marques From: Dimitry Haskin Subject: Re: Last Call (draft-ietf-idr-bgp4-ipv6-00.txt) Cc: Dimitry Haskin , idr@merit.edu In-Reply-To: <199712192230.OAA05068@pedrom-ultra.cisco.com> References: <3.0.1.32.19971219124040.006c3bc4@pobox> <199712140001.QAA19197@puli.cisco.com> <3.0.1.32.19971216174207.006bd13c@pobox> <3.0.1.32.19971219124040.006c3bc4@pobox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idr@merit.edu Precedence: bulk At 02:30 PM 12/19/97 -0800, Pedro Marques wrote: >>>>>> "Dimitry" == Dimitry Haskin writes: > > Dimitry> Let me offer the text that I'd like to have inserted in > Dimitry> the draft. Hopefully it will be more acceptable to all > Dimitry> sides in the argument. > > Dimitry> "Implementations should be able to support disabling the > Dimitry> advertisement of a global scope address in the Next Hop > Dimitry> Network Address field of an IPv6 MP_REACH_NLRI attribute > Dimitry> which is sent to an external peer. > >So what would the nexthop look like ? > In this case in contains a link-local scope address only. In the default case both link-local and global addresses are advertised as in your draft. > Pedro. Dimitry From owner-idr@merit.edu Fri Dec 19 19:30:06 1997 Delivery-Date: Fri, 19 Dec 1997 19:30:06 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id TAA03639 for ; Fri, 19 Dec 1997 19:30:05 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA20718 for ; Fri, 19 Dec 1997 19:32:57 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA02905 for idr-outgoing; Fri, 19 Dec 1997 19:07:36 -0500 (EST) Received: from paleale.cisco.com (paleale.cisco.com [171.69.95.88]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA02901 for ; Fri, 19 Dec 1997 19:07:32 -0500 (EST) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by paleale.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id QAA06399; Fri, 19 Dec 1997 16:07:01 -0800 (PST) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id QAA05121; Fri, 19 Dec 1997 16:07:01 -0800 (PST) Date: Fri, 19 Dec 1997 16:07:01 -0800 (PST) Message-Id: <199712200007.QAA05121@pedrom-ultra.cisco.com> From: Pedro Marques To: Dimitry Haskin Cc: idr@merit.edu Subject: Re: Last Call (draft-ietf-idr-bgp4-ipv6-00.txt) In-Reply-To: <3.0.1.32.19971219185058.006dc5f0@pobox> References: <3.0.1.32.19971219124040.006c3bc4@pobox> <199712140001.QAA19197@puli.cisco.com> <3.0.1.32.19971216174207.006bd13c@pobox> <199712192230.OAA05068@pedrom-ultra.cisco.com> <3.0.1.32.19971219185058.006dc5f0@pobox> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk >>>>> "Dimitry" == Dimitry Haskin writes: Dimitry> "Implementations should be able to support disabling the Dimitry> advertisement of a global scope address in the Next Hop Dimitry> Network Address field of an IPv6 MP_REACH_NLRI attribute Dimitry> which is sent to an external peer. >> So what would the nexthop look like ? >> Dimitry> In this case in contains a link-local scope address only. Dimitry> In the default case both link-local and global addresses Dimitry> are advertised as in your draft. Personally, I see your proposal as a step backwards as it drives us further away from what i see as the desirable objective which is to not have link local addresses in routing protocols or routing tables. My suggestion would be to take the discussion on what is essentially an IPv6 architecture problem to the IPng WG and advance this document to PS. I would really like to abolish the use of link locals altogether but that would need approval from the IPng WG also... Pedro. From owner-idr@merit.edu Fri Dec 19 22:12:59 1997 Delivery-Date: Fri, 19 Dec 1997 22:12:59 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id WAA04361 for ; Fri, 19 Dec 1997 22:12:58 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA20971 for ; Fri, 19 Dec 1997 22:15:51 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA03957 for idr-outgoing; Fri, 19 Dec 1997 20:41:48 -0500 (EST) Received: from smtp-gw.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA03953 for ; Fri, 19 Dec 1997 20:41:43 -0500 (EST) Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by smtp-gw.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id RAA06540; Fri, 19 Dec 1997 17:41:10 -0800 (PST) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id RAA01847; Fri, 19 Dec 1997 17:41:08 -0800 (PST) Received: from dhaskin-pc.engeast.baynetworks.com ([132.245.112.83]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id UAA27713; Fri, 19 Dec 1997 20:41:06 -0500 for Message-Id: <3.0.1.32.19971219204134.006c0b10@pobox.corpeast.baynetworks.com> X-Sender: dhaskin@pobox.corpeast.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 19 Dec 1997 20:41:34 -0500 To: Pedro Marques , Dimitry Haskin From: Dimitry Haskin Subject: Re: Last Call (draft-ietf-idr-bgp4-ipv6-00.txt) Cc: idr@merit.edu In-Reply-To: <199712200007.QAA05121@pedrom-ultra.cisco.com> References: <3.0.1.32.19971219185058.006dc5f0@pobox> <3.0.1.32.19971219124040.006c3bc4@pobox> <199712140001.QAA19197@puli.cisco.com> <3.0.1.32.19971216174207.006bd13c@pobox> <199712192230.OAA05068@pedrom-ultra.cisco.com> <3.0.1.32.19971219185058.006dc5f0@pobox> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-idr@merit.edu Precedence: bulk At 04:07 PM 12/19/97 -0800, Pedro Marques wrote: >>>>>> "Dimitry" == Dimitry Haskin writes: > > > Dimitry> "Implementations should be able to support disabling the > Dimitry> advertisement of a global scope address in the Next Hop > Dimitry> Network Address field of an IPv6 MP_REACH_NLRI attribute > Dimitry> which is sent to an external peer. > > >> So what would the nexthop look like ? > >> > > Dimitry> In this case in contains a link-local scope address only. > Dimitry> In the default case both link-local and global addresses > Dimitry> are advertised as in your draft. > >Personally, I see your proposal as a step backwards as it drives us further >away from what i see as the desirable objective which is to not have >link local addresses in routing protocols or routing tables. > I don't agree but this is a different subject. In any extend at this point link-local addresses are required in forwarding tables and therefore in routing protocols, like it or not. My proposal does not make this requirement any more or any less. >My suggestion would be to take the discussion on what is essentially an >IPv6 architecture problem to the IPng WG and advance this document to PS. > I doubt very much you'll get any where with your architectural disagreement but you welcome to try. As far as the document is concerned, you can't remove requirement for the link-local address at this point. Therefore the use of global next hop addresses is only limited to what is advertised in the Next Hop field. The text that I offered does not modify default behavior that you specified. It only allows some extra flexibility when it is *explicitly* known that the advertised global address is not used by receiving peer in any way. I belive my request is quite reasonable in the context of the current architecture. In the unlikely event that you get to change the IPv6 architecture, it will be completely different ball game and all protocol specs will need to be revisited any way. >I would really like to abolish the use of link locals altogether but that >would need approval from the IPng WG also... > > Pedro. > Dimitry From owner-idr@merit.edu Wed Jan 7 08:49:34 1998 Delivery-Date: Wed, 07 Jan 1998 08:49:48 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA00428 for ; Wed, 7 Jan 1998 08:49:29 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA09490 for ; Wed, 7 Jan 1998 08:52:15 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA25443 for idr-outgoing; Wed, 7 Jan 1998 08:17:48 -0500 (EST) Received: from botafogo.ci.rnp.br (botafogo.ci.rnp.br [200.17.63.107]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA25420 for ; Wed, 7 Jan 1998 08:14:25 -0500 (EST) Received: from botafogo (botafogo [200.17.63.107]) by botafogo.ci.rnp.br (8.8.7/8.8.7) with SMTP id LAA09445; Wed, 7 Jan 1998 11:14:18 -0200 (EDT) Date: Wed, 7 Jan 1998 11:14:18 -0200 (EDT) From: Reinaldo Penno Filho X-Sender: reinaldo@botafogo To: idr@merit.edu cc: Alexandre Subject: Re: How is a "route" defined? In-Reply-To: <9712111632.ZM17141@ptcmtls1.montreal.hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by merit.edu id IAA25438 Sender: owner-idr@merit.edu Precedence: bulk On Thu, 11 Dec 1997, Ken Rosenfeld wrote: vc>In the context of route dampening, how is a "route" defined? vc> vc> states (p. 13): vc> "A route here is considered to be a tuple containing at least vc> NLRI prefix, next hop, and AS path." vc> Hi, Sorry if this is a newbie question but I´m having a hard time understanding the difference between a Route, NLRI and their relation to UPDATE messages. In the is said: --> For purposes of this protocol a route is defined as a unit of information that pairs **a** destination with the attributes of a path that destination: <-- -->An UPDATE message is used to advertise a *single* feasible route<-- Does "a destination" means one AS or NLRI<->path attribute information? Cause if a destination is one NLRI seems to me that a UPDATE message can advertise several routes.. Or.. Does this mean that a collection of NLRIs and their path attributes is a *single* route, even tough some NLRI<-> path attributes tuples advertise different destinations (networks)? Something like this... NLRI 1 --\ \ NLRI 2 ---- Path Attributes / NLRI 3 --/ (NLRI 1, Path At.) (NLRI 2, Path At.) (NLRI 3, Path At.) A many to one relationship. So another update message to the same AS with the same NLRI but other path attribute is another route? Sorry for the long and possible intricate message... Best Regards, Reinaldo ---------------------------------------------------------------------------- Brazilian Reserch Network http://www.rnp.br reinaldo@co.rnp.br ---------------------------------------------------------------------------- From owner-idr@merit.edu Thu Jan 8 21:34:37 1998 Delivery-Date: Thu, 08 Jan 1998 21:34:37 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id VAA00414 for ; Thu, 8 Jan 1998 21:34:36 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id VAA15688 for ; Thu, 8 Jan 1998 21:37:24 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA03098 for idr-outgoing; Thu, 8 Jan 1998 21:08:31 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA03094 for ; Thu, 8 Jan 1998 21:08:27 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id VAA21986; Thu, 8 Jan 1998 21:08:26 -0500 (EST) Message-Id: <199801090208.VAA21986@brookfield.ans.net> To: idr@merit.edu cc: curtis@ans.net Reply-To: curtis@ans.net Subject: Route Flap Damping - changes since last call Date: Thu, 08 Jan 1998 21:08:26 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk There were a few comments in the last call for the Route Flap Damping draft, draft-ietf-idr-route-damp-00.txt. I've made revisions and will submit the revised draft (-01) to the rfc editor. There is a revised I-D http://engr.ans.net/route-damp/ along with complete diffs against the latex source (to avoid having to reread the whole thing). The changes were in response to comments and are: Numerous wording changes and small nits. Spell checked. New subsection named "Per Route State" providing a clarification on what can be considered a "route" for the purpose of damping. This contains a few words on the implications of including some of the BGP attributes that are stated as optional for the purpose of route damping. A few words of clarification intended to make it more clear that the "reuse lists" are used both to identify the reachable routes that are reusable after a waiting time and the unreachable routes that can be completely disposed of after a waiting time. A number of paragraphs were added to the "Implementation Experience" section to reflect the experiences and recommendations of the RIPE routing-wg and the case provided by Alan Barrett on the IEPG mailing list. The "Acknowledgements" section was updated, though I can't list everyone who has provided implementation feedback in the last two years without missing individuals from so I just listed the groups (RIPE routing, IEPG, NANOG, IDR) where discussions occurred. Because of the added paragraphs it might be worth repeating WG last call just in case there are comments about the additions before bothering the IESG. I leave that decision to the WG chairs. Curtis ps- the direct URLs are: http://engr.ans.net/route-damp introductory text, diffs, pointers http://engr.ans.net/route-damp/route-damp.html http://engr.ans.net/route-damp/route-damp.txt http://engr.ans.net/route-damp/route-damp.ps ftp://engr.ans.net/pub/internet-drafts/draft-ietf-idr-route-damp-01.txt ftp://engr.ans.net/pub/internet-drafts/draft-ietf-idr-route-damp-01.ps From owner-idr@merit.edu Fri Jan 9 09:24:31 1998 Delivery-Date: Fri, 09 Jan 1998 09:24:31 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA11328 for ; Fri, 9 Jan 1998 09:24:26 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA16631 for ; Fri, 9 Jan 1998 09:27:13 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA08471 for idr-outgoing; Fri, 9 Jan 1998 08:46:47 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by merit.edu (8.8.7/8.8.5) with SMTP id IAA08465 for ; Fri, 9 Jan 1998 08:46:43 -0500 (EST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id FAA23190; Fri, 9 Jan 1998 05:45:41 -0800 Message-Id: <199801091345.FAA23190@puli.cisco.com> To: curtis@ans.net cc: idr@merit.edu Subject: Re: Route Flap Damping - changes since last call In-reply-to: Your message of "Thu, 08 Jan 98 21:08:26 EST." <199801090208.VAA21986@brookfield.ans.net> Date: Fri, 09 Jan 98 05:45:41 PST From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Curtis, > There is a revised I-D http://engr.ans.net/route-damp/ along with > complete diffs against the latex source (to avoid having to reread the > whole thing). > > The changes were in response to comments and are: > > Numerous wording changes and small nits. Spell checked. > > New subsection named "Per Route State" providing a clarification on > what can be considered a "route" for the purpose of damping. This > contains a few words on the implications of including some of the > BGP attributes that are stated as optional for the purpose of route > damping. > > A few words of clarification intended to make it more clear that the > "reuse lists" are used both to identify the reachable routes that > are reusable after a waiting time and the unreachable routes that > can be completely disposed of after a waiting time. > > A number of paragraphs were added to the "Implementation Experience" > section to reflect the experiences and recommendations of the RIPE > routing-wg and the case provided by Alan Barrett on the IEPG mailing > list. > > The "Acknowledgements" section was updated, though I can't list > everyone who has provided implementation feedback in the last two > years without missing individuals from so I just listed the groups > (RIPE routing, IEPG, NANOG, IDR) where discussions occurred. > > Because of the added paragraphs it might be worth repeating WG last > call just in case there are comments about the additions before > bothering the IESG. I leave that decision to the WG chairs. I would propose we'll have an "abbreviated" WG Last Call till next Friday (Jan 16). In the absence of any objections to the revised version of your document, on Jan 16 we'll ask the IESG to advance the document to a Proposed Standard. Yakov. From adm Mon Jan 12 08:28:43 1998 Delivery-Date: Mon, 12 Jan 1998 08:44:18 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id IAA15866 for ietf-123-outbound.10@ietf.org; Mon, 12 Jan 1998 08:27:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA15811; Mon, 12 Jan 1998 08:23:17 -0500 (EST) Message-Id: <199801121323.IAA15811@ns.ietf.org> To: IETF-Announce: ; Cc: idr@merit.edu From: The IESG SUBJECT: Last Call: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Mon, 12 Jan 1998 08:23:17 -0500 Sender: scoya@cnri.reston.va.us The IESG has received a request from the Inter-Domain Routing Working Group to consider Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 26, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt From owner-idr@merit.edu Mon Jan 12 09:17:00 1998 Delivery-Date: Mon, 12 Jan 1998 09:17:00 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA16595 for ; Mon, 12 Jan 1998 09:17:00 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA02290 for ; Mon, 12 Jan 1998 09:19:46 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA06454 for idr-outgoing; Mon, 12 Jan 1998 08:24:49 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA06450 for ; Mon, 12 Jan 1998 08:24:45 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA15811; Mon, 12 Jan 1998 08:23:17 -0500 (EST) Message-Id: <199801121323.IAA15811@ns.ietf.org> To: IETF-Announce: ; Cc: idr@merit.edu From: The IESG SUBJECT: Last Call: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Mon, 12 Jan 1998 08:23:17 -0500 Sender: owner-idr@merit.edu Precedence: bulk The IESG has received a request from the Inter-Domain Routing Working Group to consider Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by January 26, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-ipv6-00.txt From owner-idr@merit.edu Wed Jan 14 10:29:09 1998 Delivery-Date: Wed, 14 Jan 1998 10:29:09 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA27548 for ; Wed, 14 Jan 1998 10:29:08 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA10431 for ; Wed, 14 Jan 1998 10:31:54 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA17212 for idr-outgoing; Wed, 14 Jan 1998 09:53:14 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA17208 for ; Wed, 14 Jan 1998 09:53:10 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA26251; Wed, 14 Jan 1998 09:53:06 -0500 (EST) Message-Id: <199801141453.JAA26251@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-route-damp-01.txt,.ps Date: Wed, 14 Jan 1998 09:53:05 -0500 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Route Flap Damping Author(s) : C. Villamizar, R. Govindan, R. Chandra Filename : draft-ietf-idr-route-damp-01.txt,.ps Pages : 30 Date : 13-Jan-98 A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes. This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead An excessive rate of update to the advertised reachability of a subset of Internet prefixes has been widespread in the Internet. This observation was made in the early 1990s by many people involved in Internet operations and remains the case. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is ``route flap''. The techniques described here are now widely deployed and are commonly referred to as ``route flap damping''. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-damp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-route-damp-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-damp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980113144706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-damp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-damp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980113144706.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Wed Jan 14 10:47:11 1998 Delivery-Date: Wed, 14 Jan 1998 10:56:22 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA28250 for ietf-123-outbound.10@ietf.org; Wed, 14 Jan 1998 10:47:01 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA26251; Wed, 14 Jan 1998 09:53:06 -0500 (EST) Message-Id: <199801141453.JAA26251@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-route-damp-01.txt,.ps Date: Wed, 14 Jan 1998 09:53:05 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Route Flap Damping Author(s) : C. Villamizar, R. Govindan, R. Chandra Filename : draft-ietf-idr-route-damp-01.txt,.ps Pages : 30 Date : 13-Jan-98 A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes. This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead An excessive rate of update to the advertised reachability of a subset of Internet prefixes has been widespread in the Internet. This observation was made in the early 1990s by many people involved in Internet operations and remains the case. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is ``route flap''. The techniques described here are now widely deployed and are commonly referred to as ``route flap damping''. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-damp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-route-damp-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-damp-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980113144706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-damp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-damp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980113144706.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Thu Jan 15 12:27:32 1998 Delivery-Date: Thu, 15 Jan 1998 12:27:33 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA04573 for ; Thu, 15 Jan 1998 12:27:32 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA15030 for ; Thu, 15 Jan 1998 12:30:17 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA04390 for idr-outgoing; Thu, 15 Jan 1998 11:54:48 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA04386 for ; Thu, 15 Jan 1998 11:54:42 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA03615; Thu, 15 Jan 1998 11:54:26 -0500 (EST) Message-Id: <199801151654.LAA03615@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-multiprotocol-02.txt Date: Thu, 15 Jan 1998 11:54:25 -0500 Sender: owner-idr@merit.edu Precedence: bulk --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 : Multiprotocol Extensions for BGP-4 Author(s) : D. Katz, Y. Rekhter, T. Bates, R. Chandra Filename : draft-ietf-idr-bgp4-multiprotocol-02.txt Pages : 9 Date : 14-Jan-98 Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-multiprotocol-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980115112845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-multiprotocol-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980115112845.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Thu Jan 15 12:37:24 1998 Delivery-Date: Thu, 15 Jan 1998 12:53:23 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id MAA04904 for ietf-123-outbound.10@ietf.org; Thu, 15 Jan 1998 12:37:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA03615; Thu, 15 Jan 1998 11:54:26 -0500 (EST) Message-Id: <199801151654.LAA03615@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-multiprotocol-02.txt Date: Thu, 15 Jan 1998 11:54:25 -0500 Sender: scoya@cnri.reston.va.us --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 : Multiprotocol Extensions for BGP-4 Author(s) : D. Katz, Y. Rekhter, T. Bates, R. Chandra Filename : draft-ietf-idr-bgp4-multiprotocol-02.txt Pages : 9 Date : 14-Jan-98 Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-multiprotocol-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980115112845.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-multiprotocol-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980115112845.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Thu Jan 22 14:32:49 1998 Delivery-Date: Thu, 22 Jan 1998 14:43:41 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id OAA15593 for ietf-123-outbound.10@ietf.org; Thu, 22 Jan 1998 14:32:01 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA15565; Thu, 22 Jan 1998 14:31:25 -0500 (EST) Message-Id: <199801221931.OAA15565@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: idr@merit.edu From: The IESG Subject: Document Action: Using a Dedicated AS for Sites Homed to a Single Provider to Informational Date: Thu, 22 Jan 1998 14:31:25 -0500 Sender: scoya@cnri.reston.va.us The IESG has approved the Internet-Draft 'Using a Dedicated AS for Sites Homed to a Single Provider' as a Informational. This document is the product of the Inter-Domain Routing Working Group. The IESG contact person is Joel Halpern. From owner-idr@merit.edu Thu Jan 22 15:18:00 1998 Delivery-Date: Thu, 22 Jan 1998 15:18:01 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA16300 for ; Thu, 22 Jan 1998 15:18:00 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA15157 for ; Thu, 22 Jan 1998 15:20:45 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA19851 for idr-outgoing; Thu, 22 Jan 1998 14:31:36 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA19846 for ; Thu, 22 Jan 1998 14:31:32 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA15565; Thu, 22 Jan 1998 14:31:25 -0500 (EST) Message-Id: <199801221931.OAA15565@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: idr@merit.edu From: The IESG Subject: Document Action: Using a Dedicated AS for Sites Homed to a Single Provider to Informational Date: Thu, 22 Jan 1998 14:31:25 -0500 Sender: owner-idr@merit.edu Precedence: bulk The IESG has approved the Internet-Draft 'Using a Dedicated AS for Sites Homed to a Single Provider' as a Informational. This document is the product of the Inter-Domain Routing Working Group. The IESG contact person is Joel Halpern. From owner-idr@merit.edu Fri Jan 30 23:38:02 1998 Delivery-Date: Fri, 30 Jan 1998 23:38:02 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id XAA28989 for ; Fri, 30 Jan 1998 23:38:01 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA21233 for ; Fri, 30 Jan 1998 23:40:45 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id XAA26202 for idr-outgoing; Fri, 30 Jan 1998 23:12:14 -0500 (EST) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id XAA26198 for ; Fri, 30 Jan 1998 23:12:10 -0500 (EST) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id XAA14246; Fri, 30 Jan 1998 23:12:10 -0500 (EST) Message-Id: <199801310412.XAA14246@brookfield.ans.net> To: idr@merit.edu cc: curtis@ans.net Reply-To: curtis@ans.net Subject: draft-ietf-idr-bgp4-06.txt Date: Fri, 30 Jan 1998 23:12:09 -0500 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk draft-ietf-idr-bgp4-06.txt is about to expire. Does that concern anyone? What happenned to updating BGP-4? Curtis From owner-idr@merit.edu Sun Feb 1 18:19:28 1998 Delivery-Date: Sun, 01 Feb 1998 18:19:29 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id SAA05475 for ; Sun, 1 Feb 1998 18:19:28 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id SAA00956 for ; Sun, 1 Feb 1998 18:22:10 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA12201 for idr-outgoing; Sun, 1 Feb 1998 17:43:00 -0500 (EST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA12197 for ; Sun, 1 Feb 1998 17:42:56 -0500 (EST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id OAA21219; Sun, 1 Feb 1998 14:41:53 -0800 Message-Id: <199802012241.OAA21219@puli.cisco.com> To: curtis@ans.net cc: idr@merit.edu Subject: Re: draft-ietf-idr-bgp4-06.txt In-reply-to: Your message of "Fri, 30 Jan 98 23:12:09 EST." <199801310412.XAA14246@brookfield.ans.net> Date: Sun, 01 Feb 98 14:41:53 PST From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Curtis, > draft-ietf-idr-bgp4-06.txt is about to expire. > > Does that concern anyone? What happenned to updating BGP-4? I just submitted an updated version. Yakov. From adm Tue Feb 3 09:57:19 1998 Delivery-Date: Tue, 03 Feb 1998 10:02:54 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id JAA02687 for ietf-123-outbound.10@ietf.org; Tue, 3 Feb 1998 09:57:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA01853; Tue, 3 Feb 1998 09:38:28 -0500 (EST) Message-Id: <199802031438.JAA01853@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-07.txt Date: Tue, 03 Feb 1998 09:38:27 -0500 Sender: cclark@cnri.reston.va.us --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 : A Border Gateway Protocol 4 (BGP-4) Author(s) : T. Li, Y. Rekhter Filename : draft-ietf-idr-bgp4-07.txt Pages : 59 Date : 02-Feb-98 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. It is built on experience gained with EGP as defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as described in RFC 1092 [2] and RFC 1093 [3]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-07.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980202151127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980202151127.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Tue Feb 3 10:14:40 1998 Delivery-Date: Tue, 03 Feb 1998 10:14:52 -0500 Return-Path: owner-idr@merit.edu Received: from ns.cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA03706 for ; Tue, 3 Feb 1998 10:14:40 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by ns.cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA07387 for ; Tue, 3 Feb 1998 10:17:22 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA11210 for idr-outgoing; Tue, 3 Feb 1998 09:38:36 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA11206 for ; Tue, 3 Feb 1998 09:38:32 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA01853; Tue, 3 Feb 1998 09:38:28 -0500 (EST) Message-Id: <199802031438.JAA01853@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-07.txt Date: Tue, 03 Feb 1998 09:38:27 -0500 Sender: owner-idr@merit.edu Precedence: bulk --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 : A Border Gateway Protocol 4 (BGP-4) Author(s) : T. Li, Y. Rekhter Filename : draft-ietf-idr-bgp4-07.txt Pages : 59 Date : 02-Feb-98 The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. It is built on experience gained with EGP as defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as described in RFC 1092 [2] and RFC 1093 [3]. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-07.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-07.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-07.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980202151127.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-07.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980202151127.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Fri Feb 6 11:58:30 1998 Delivery-Date: Fri, 06 Feb 1998 12:04:15 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id LAA09001 for ietf-123-outbound.10@ietf.org; Fri, 6 Feb 1998 11:57:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA08879; Fri, 6 Feb 1998 11:54:16 -0500 (EST) Message-Id: <199802061654.LAA08879@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: idr@merit.edu From: The IESG Subject: Protocol Action: Multiprotocol Extensions for BGP-4 to Proposed Standard Date: Fri, 06 Feb 1998 11:54:16 -0500 Sender: scoya@cnri.reston.va.us The IESG has approved the Internet-Draft "Multiprotocol Extensions for BGP-4" as a Proposed Standard. This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons is Joel Halpern. Technical Summary The Multiprotocol Extensions for BGP-4 allow BGP-4 to be used for routing reachability information for protocols other than IPv4. It can be used to carry IPv6 information, and even information for other internetworking protocols. The extensions also allow for the clear handling of multicast RPF Information as a separate set of information from the unicast case. Working Group Summary The working group strongly supports this work as the solution to the need for multiprotocol support in BGP-4. Other solutions were discussed and considered, and it was concluded clearly that this was the best available answer. Protocol Quality This specification has been reviewed by Joel M. Halpern, the Routing Area Director, and is a sound protocol specification. There are multiple implementations of this protocol for supporting IPv6, as well as at least one for IPv4 multicast. Note to RFC Editor: The following text should appended to Section 7 of the document: Subsequent Address Family Identifiers (other than those reserved for vendor specific use) are assigned only by the IETF consensus process and IESG approval. From owner-idr@merit.edu Fri Feb 6 12:41:57 1998 Delivery-Date: Fri, 06 Feb 1998 12:41:57 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA10054 for ; Fri, 6 Feb 1998 12:41:57 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA08009 for ; Fri, 6 Feb 1998 12:44:37 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA01137 for idr-outgoing; Fri, 6 Feb 1998 11:54:26 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA01133 for ; Fri, 6 Feb 1998 11:54:22 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA08879; Fri, 6 Feb 1998 11:54:16 -0500 (EST) Message-Id: <199802061654.LAA08879@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: idr@merit.edu From: The IESG Subject: Protocol Action: Multiprotocol Extensions for BGP-4 to Proposed Standard Date: Fri, 06 Feb 1998 11:54:16 -0500 Sender: owner-idr@merit.edu Precedence: bulk The IESG has approved the Internet-Draft "Multiprotocol Extensions for BGP-4" as a Proposed Standard. This document is the product of the Inter-Domain Routing Working Group. The IESG contact persons is Joel Halpern. Technical Summary The Multiprotocol Extensions for BGP-4 allow BGP-4 to be used for routing reachability information for protocols other than IPv4. It can be used to carry IPv6 information, and even information for other internetworking protocols. The extensions also allow for the clear handling of multicast RPF Information as a separate set of information from the unicast case. Working Group Summary The working group strongly supports this work as the solution to the need for multiprotocol support in BGP-4. Other solutions were discussed and considered, and it was concluded clearly that this was the best available answer. Protocol Quality This specification has been reviewed by Joel M. Halpern, the Routing Area Director, and is a sound protocol specification. There are multiple implementations of this protocol for supporting IPv6, as well as at least one for IPv4 multicast. Note to RFC Editor: The following text should appended to Section 7 of the document: Subsequent Address Family Identifiers (other than those reserved for vendor specific use) are assigned only by the IETF consensus process and IESG approval. From adm Fri Feb 6 13:08:54 1998 Delivery-Date: Fri, 06 Feb 1998 13:16:08 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id NAA10751 for ietf-123-outbound.10@ietf.org; Fri, 6 Feb 1998 13:07:04 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA10724; Fri, 6 Feb 1998 13:06:37 -0500 (EST) Message-Id: <199802061806.NAA10724@ns.ietf.org> To: IETF-Announce: ; Cc: idr@merit.edu From: The IESG SUBJECT: Last Call: Protection of BGP Sessions via the TCP MD5 Signature Option to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Fri, 06 Feb 1998 13:06:37 -0500 Sender: scoya@cnri.reston.va.us The IESG has received a request from the Inter-Domain Routing Working Group to consider Protection of BGP Sessions via the TCP MD5 Signature Option as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 20, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-heffernan-bgp-tcp-md5-00.txt From owner-idr@merit.edu Fri Feb 6 13:37:19 1998 Delivery-Date: Fri, 06 Feb 1998 13:37:20 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA11572 for ; Fri, 6 Feb 1998 13:37:19 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA08336 for ; Fri, 6 Feb 1998 13:40:00 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA03572 for idr-outgoing; Fri, 6 Feb 1998 13:06:49 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA03560 for ; Fri, 6 Feb 1998 13:06:41 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA10724; Fri, 6 Feb 1998 13:06:37 -0500 (EST) Message-Id: <199802061806.NAA10724@ns.ietf.org> To: IETF-Announce: ; Cc: idr@merit.edu From: The IESG SUBJECT: Last Call: Protection of BGP Sessions via the TCP MD5 Signature Option to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Fri, 06 Feb 1998 13:06:37 -0500 Sender: owner-idr@merit.edu Precedence: bulk The IESG has received a request from the Inter-Domain Routing Working Group to consider Protection of BGP Sessions via the TCP MD5 Signature Option as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 20, 1998. Files can be obtained via ftp://ds.internic.net/internet-drafts/draft-heffernan-bgp-tcp-md5-00.txt From owner-idr@merit.edu Tue Feb 10 02:23:02 1998 Delivery-Date: Tue, 10 Feb 1998 02:23:03 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id CAA13576 for ; Tue, 10 Feb 1998 02:23:02 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA06384 for ; Tue, 10 Feb 1998 02:25:41 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id BAA27918 for idr-outgoing; Tue, 10 Feb 1998 01:46:04 -0500 (EST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by merit.edu (8.8.7/8.8.5) with ESMTP id BAA27914 for ; Tue, 10 Feb 1998 01:45:58 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (8.8.5/8.6.10/MOT-3.8) with ESMTP id AAA15061 for ; Tue, 10 Feb 1998 00:45:58 -0600 (CST) Comments: ( Received on motgate.mot.com from client pobox.mot.com, sender anandkg@miel.mot.com ) Received: from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox.mot.com (8.8.5/8.6.10/MOT-3.8) with SMTP id AAA09691 for ; Tue, 10 Feb 1998 00:45:52 -0600 (CST) Received: from rex.miel.mot.com by hpux4.miel.mot.com with SMTP id AA05991 (5.67b/IDA-1.6 for idr@merit.edu); Tue, 10 Feb 1998 12:07:39 +0500 Received: from rex (localhost) by rex.miel.mot.com with SMTP id AA08961 (5.67b/IDA-1.5 for idr@merit.edu); Tue, 10 Feb 1998 12:02:25 +0530 Message-Id: <34DFF476.B6C@miel.mot.com> Date: Tue, 10 Feb 1998 12:02:22 +0530 From: Anand Kumar Goenka X-Mailer: Mozilla 3.01 (X11; I; HP-UX A.09.01 9000/750) Mime-Version: 1.0 To: fred@cisco.com, idr@merit.edu Cc: ssn@miel.mot.com, harsha@miel.mot.com, anandkg@miel.mot.com Subject: Directed Broadcasts in CIDR domain.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Hi All, I am referring to sec 5.3.5 of RFC-1812-"Router Specification" According to this RFC "All subnet directed broadcast" is meaningless in CIDR routing domain and also "Network-prefix directed broadcast" and "subnet Directed Broadcast" has same meaning in CIDR routing domain. But there is problem in the way a CIDR capable ruoter can(or should) interprate an incomming directed broadcast. Scenario Description: Suppose router has the routing table entries for following 3 networks.. 1. 150.1.10.0/23 2. 150.1.16.0/23 3. 150.1.8.0/21 and the router received a packet with destination address 150.1.15.255 . Considering the above routing table entries router can have following directed broadcast interpretation for this packet. a) A directed broadcast to 150.1.8.0/21 - in this case router has to forward the packet to both 150.1.10.0/23 and 150.1.16.0/23 b) A directed broadcast to 150.1.16.0/23 - in this case router has to forward the packet only to 150.1.16.0/23 Question - which one of the above interpretation is correct ? An early reply will be helpfull.. Thanks & Regards, Anand Kumar Goenka, Motorola India Electronics Ltd, Email: anandkg@miel.mot.com From adm Tue Feb 10 10:22:17 1998 Delivery-Date: Tue, 10 Feb 1998 10:29:41 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA20544 for ietf-123-outbound.10@ietf.org; Tue, 10 Feb 1998 10:22:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA20014; Tue, 10 Feb 1998 10:07:53 -0500 (EST) Message-Id: <199802101507.KAA20014@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-ipv6-01.txt Date: Tue, 10 Feb 1998 10:07:52 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing Author(s) : F. Dupont, P. Marques Filename : draft-ietf-idr-bgp4-ipv6-01.txt Pages : 5 Date : 09-Feb-98 BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-ipv6-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-ipv6-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980209105942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-ipv6-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980209105942.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Tue Feb 10 10:40:19 1998 Delivery-Date: Tue, 10 Feb 1998 10:40:19 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA21247 for ; Tue, 10 Feb 1998 10:40:19 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA07415 for ; Tue, 10 Feb 1998 10:42:59 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA02523 for idr-outgoing; Tue, 10 Feb 1998 10:08:01 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA02519 for ; Tue, 10 Feb 1998 10:07:57 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA20014; Tue, 10 Feb 1998 10:07:53 -0500 (EST) Message-Id: <199802101507.KAA20014@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-ipv6-01.txt Date: Tue, 10 Feb 1998 10:07:52 -0500 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing Author(s) : F. Dupont, P. Marques Filename : draft-ietf-idr-bgp4-ipv6-01.txt Pages : 5 Date : 09-Feb-98 BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-ipv6-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-idr-bgp4-ipv6-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980209105942.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-ipv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-ipv6-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980209105942.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Tue Feb 10 12:36:05 1998 Delivery-Date: Tue, 10 Feb 1998 12:36:05 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id MAA23945 for ; Tue, 10 Feb 1998 12:36:05 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA07993 for ; Tue, 10 Feb 1998 12:38:44 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA05090 for idr-outgoing; Tue, 10 Feb 1998 11:47:51 -0500 (EST) Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA05084 for ; Tue, 10 Feb 1998 11:47:44 -0500 (EST) Received: from [171.69.128.118] (fred-hm-dhcp3.cisco.com [171.69.128.118]) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id HAA03832; Tue, 10 Feb 1998 07:53:39 -0800 (PST) X-Sender: fred@stilton.cisco.com Message-Id: In-Reply-To: <34DFF476.B6C@miel.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 10 Feb 1998 07:49:35 -0800 To: Anand Kumar Goenka From: Fred Baker Subject: Re: Directed Broadcasts in CIDR domain.. Cc: idr@merit.edu, ssn@miel.mot.com, harsha@miel.mot.com, anandkg@miel.mot.com Sender: owner-idr@merit.edu Precedence: bulk At 12:02 PM +0530 2/10/98, Anand Kumar Goenka wrote: > a) A directed broadcast to 150.1.8.0/21 - in this case router has >to forward the packet to both 150.1.10.0/23 and 150.1.16.0/23 > b) A directed broadcast to 150.1.16.0/23 - in this case router >has to forward the packet only to 150.1.16.0/23 > >Question - which one of the above interpretation is correct ? since the address is ambiguous, I would think (speaking for myself and nobody else) that the most robust interpretation is (a). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= "The best way to predict the future is to create it" ---Peter Drucker From owner-ietf-rip@BayNetworks.COM Sun Feb 15 02:00:58 1998 Delivery-Date: Sun, 15 Feb 1998 02:00:59 -0500 Return-Path: owner-ietf-rip@BayNetworks.COM Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id CAA03207 for ; Sun, 15 Feb 1998 02:00:58 -0500 (EST) Received: from smtp-gw.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA14872 for ; Sun, 15 Feb 1998 02:03:38 -0500 (EST) Received: from mailhost.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by smtp-gw.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id WAA17755; Sat, 14 Feb 1998 22:37:13 -0800 (PST) Received: from majordomo.BayNetworks.COM ([192.32.253.10] (may be forged)) by mailhost.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id WAA02006; Sat, 14 Feb 1998 22:36:46 -0800 (PST) Received: (from major@localhost) by majordomo.BayNetworks.COM (8.8.6/BNET-SVR4) id BAA06530; Sun, 15 Feb 1998 01:38:38 -0500 (EST) for ietf-rip-outgoing X-Authentication-Warning: majordomo.BayNetworks.COM: major set sender to owner-ietf-rip@majordomo using -f Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by majordomo.BayNetworks.COM (8.8.6/BNET-SVR4) with ESMTP id BAA06526; Sun, 15 Feb 1998 01:38:32 -0500 (EST) for Received: from majordomo.BayNetworks.COM ([192.32.253.10] (may be forged)) by mailhost.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id WAA10881 for ; Sat, 14 Feb 1998 22:31:49 -0800 (PST) Received: from smtp-gw.BayNetworks.COM (ext-ns3.baynetworks.com [192.32.253.3] (may be forged)) by majordomo.BayNetworks.COM (8.8.6/BNET-SVR4) with ESMTP id BAA06522; Sun, 15 Feb 1998 01:37:17 -0500 (EST) for Received: from netcom13.netcom.com (andrade@netcom13.netcom.com [192.100.81.125]) by smtp-gw.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id BAA25537 for ; Sun, 15 Feb 1998 01:33:03 -0500 (EST) Received: (from andrade@localhost) by netcom13.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.02)) id WAA03381; Sat, 14 Feb 1998 22:32:34 -0800 (PST) From: Andrade Software Andrade Networking Message-Id: <199802150632.WAA03381@netcom13.netcom.com> Subject: Routing questions about IPv4 header To: nimrod-wg@bbn.com, idr@merit.edu, isis@merit.edu, ietf-rip@BayNetworks.COM Date: Sat, 14 Feb 1998 22:32:33 -0800 (PST) Cc: andrade@netcom13.netcom.com (Alex Alten) Sender: owner-ietf-rip@BayNetworks.COM Precedence: bulk Andrade Software & Networking Andrad@Netcom.Com X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2111 Pardon me if I've reached the wrong discussion groups. These seemed to be the best ones for answering my questions. My questions are about the behavior of routers as IPv4 datagrams flow through them. These are based on my understanding of RFC 791. I need to understand some subtle issues with the handling of the IPv4 header. In particular I want to know if any of the following will break the proper routing behavior or cause IPv4 packets to be discarded with typical routers now deployed on the Internet. Q1: In byte #7 there are three bits reserved. The highest bit is always set to 0. Can it be set to 1? Q2: Again in byte #7, if the DF bit is 1 is the MF bit ignored? Can it be set to 1? Q3: If the DF bit is 1 are the Offset (13 bits in bytes #7 & #8) and the Identification (16 bits in bytes #5 & #6) fields ignored? Can they be set to any value? Q4: In byte #2 is the Type of Service Field ever used? Can any pattern be set here? Q5: Options can follow byte #20. An option has a two byte header, the 2nd byte is the length in bytes. This means that the data can be up to 254 bytes in length. However the IHL has a maximum value of 15 (= 60 bytes). Does this mean that the option data only has a real maximum of 38 bytes (40 minus the 2 option header bytes)? Q6: Will routers honor datagrams that include an option field that carry routing or neighbor greeting information? For example, if the payload a RIP, LSP or IS-IS data? Or it is an ICMP message? Q7: As a follow on to Q6. Can the option be an option which has not yet been defined in an RFC? E.g. an experimental or unregistered option number? Will a router honor it? Will it allow RIP, LSP, IS-IS, ICMP, etc. to piggyback on it? I appreciate any answers you may have. Please ensure that your response includes my email address (Andrade@Netcom.Com) since I am not a subscriber to your discussion group. Thank you, - Alex Alten -- Alex Alten P.O. Box 11406 Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-idr@merit.edu Sun Feb 15 02:32:28 1998 Delivery-Date: Sun, 15 Feb 1998 02:32:28 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id CAA03293 for ; Sun, 15 Feb 1998 02:32:27 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id CAA14898 for ; Sun, 15 Feb 1998 02:35:08 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id CAA14289 for idr-outgoing; Sun, 15 Feb 1998 02:09:14 -0500 (EST) Received: from netcom13.netcom.com (andrade@netcom13.netcom.com [192.100.81.125]) by merit.edu (8.8.7/8.8.5) with ESMTP id BAA14039; Sun, 15 Feb 1998 01:32:39 -0500 (EST) Received: (from andrade@localhost) by netcom13.netcom.com (8.8.5-r-beta/8.8.5/(NETCOM v1.02)) id WAA03381; Sat, 14 Feb 1998 22:32:34 -0800 (PST) From: Andrade Software Andrade Networking Message-Id: <199802150632.WAA03381@netcom13.netcom.com> Subject: Routing questions about IPv4 header To: nimrod-wg@bbn.com, idr@merit.edu, isis@merit.edu, ietf-rip@baynetworks.com Date: Sat, 14 Feb 1998 22:32:33 -0800 (PST) Cc: andrade@netcom13.netcom.com (Alex Alten) Sender: owner-idr@merit.edu Precedence: bulk Andrade Software & Networking Andrad@Netcom.Com X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2111 Pardon me if I've reached the wrong discussion groups. These seemed to be the best ones for answering my questions. My questions are about the behavior of routers as IPv4 datagrams flow through them. These are based on my understanding of RFC 791. I need to understand some subtle issues with the handling of the IPv4 header. In particular I want to know if any of the following will break the proper routing behavior or cause IPv4 packets to be discarded with typical routers now deployed on the Internet. Q1: In byte #7 there are three bits reserved. The highest bit is always set to 0. Can it be set to 1? Q2: Again in byte #7, if the DF bit is 1 is the MF bit ignored? Can it be set to 1? Q3: If the DF bit is 1 are the Offset (13 bits in bytes #7 & #8) and the Identification (16 bits in bytes #5 & #6) fields ignored? Can they be set to any value? Q4: In byte #2 is the Type of Service Field ever used? Can any pattern be set here? Q5: Options can follow byte #20. An option has a two byte header, the 2nd byte is the length in bytes. This means that the data can be up to 254 bytes in length. However the IHL has a maximum value of 15 (= 60 bytes). Does this mean that the option data only has a real maximum of 38 bytes (40 minus the 2 option header bytes)? Q6: Will routers honor datagrams that include an option field that carry routing or neighbor greeting information? For example, if the payload a RIP, LSP or IS-IS data? Or it is an ICMP message? Q7: As a follow on to Q6. Can the option be an option which has not yet been defined in an RFC? E.g. an experimental or unregistered option number? Will a router honor it? Will it allow RIP, LSP, IS-IS, ICMP, etc. to piggyback on it? I appreciate any answers you may have. Please ensure that your response includes my email address (Andrade@Netcom.Com) since I am not a subscriber to your discussion group. Thank you, - Alex Alten -- Alex Alten P.O. Box 11406 Pleasanton, CA 94588 USA Andrade@Netcom.Com (510) 417-0159 Fax/Voice From owner-idr@merit.edu Wed Feb 18 08:44:02 1998 Delivery-Date: Wed, 18 Feb 1998 08:44:03 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA28533 for ; Wed, 18 Feb 1998 08:44:01 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id IAA11803 for ; Wed, 18 Feb 1998 08:46:40 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA08694 for idr-outgoing; Wed, 18 Feb 1998 08:12:56 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA08690 for ; Wed, 18 Feb 1998 08:12:52 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA27286; Wed, 18 Feb 1998 08:12:47 -0500 (EST) Message-Id: <199802181312.IAA27286@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: idr@merit.edu From: The IESG Subject: Protocol Action: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing to Proposed Standard Date: Wed, 18 Feb 1998 08:12:47 -0500 Sender: owner-idr@merit.edu Precedence: bulk The IESG has approved the Internet-Draft 'Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing' as a Proposed Standard. This document is the product of the Inter-Domain Routing Working Group. The IESG contact person is Joel Halpern. Technical Summary This protocol specification defines the extensions to multi-protocol BGP-4 required to support IPv6. It thereby provides the mechanisms need to have an inter-domain routing protocol for IPv6, with all of the proerties of BGP-4. Working Group Summary There was strong consensus in the working group in support of this document. Alternatives werediscussed, and this was agreed as the way forward. Protocol Quality The document has been reviewed for the IESG by Joel M. Halpern, the Routing Area Director. Use of this protocol has begun in multiple implementations. From adm Wed Feb 18 08:47:27 1998 Delivery-Date: Wed, 18 Feb 1998 08:57:17 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id IAA28639 for ietf-123-outbound.10@ietf.org; Wed, 18 Feb 1998 08:47:04 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA27286; Wed, 18 Feb 1998 08:12:47 -0500 (EST) Message-Id: <199802181312.IAA27286@ns.ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: idr@merit.edu From: The IESG Subject: Protocol Action: Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing to Proposed Standard Date: Wed, 18 Feb 1998 08:12:47 -0500 Sender: scoya@cnri.reston.va.us The IESG has approved the Internet-Draft 'Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing' as a Proposed Standard. This document is the product of the Inter-Domain Routing Working Group. The IESG contact person is Joel Halpern. Technical Summary This protocol specification defines the extensions to multi-protocol BGP-4 required to support IPv6. It thereby provides the mechanisms need to have an inter-domain routing protocol for IPv6, with all of the proerties of BGP-4. Working Group Summary There was strong consensus in the working group in support of this document. Alternatives werediscussed, and this was agreed as the way forward. Protocol Quality The document has been reviewed for the IESG by Joel M. Halpern, the Routing Area Director. Use of this protocol has begun in multiple implementations. From owner-idr@merit.edu Wed Feb 18 17:33:16 1998 Delivery-Date: Wed, 18 Feb 1998 17:33:17 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id RAA10054 for ; Wed, 18 Feb 1998 17:33:16 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA14824 for ; Wed, 18 Feb 1998 17:35:56 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA18922 for idr-outgoing; Wed, 18 Feb 1998 17:08:05 -0500 (EST) Received: from darling.cs.umd.edu (darling.cs.umd.edu [128.8.128.115]) by merit.edu (8.8.7/8.8.5) with ESMTP id RAA18918 for ; Wed, 18 Feb 1998 17:08:01 -0500 (EST) From: rohit@cs.umd.edu Received: by darling.cs.umd.edu (8.8.5/UMIACS-0.9/04-05-88) id RAA24074; Wed, 18 Feb 1998 17:08:00 -0500 (EST) Date: Wed, 18 Feb 1998 17:08:00 -0500 (EST) Message-Id: <199802182208.RAA24074@darling.cs.umd.edu> To: idr@merit.edu Subject: Cluster-Lists and Originator-ids Sender: owner-idr@merit.edu Precedence: bulk Hi, I had a couple of queries on route reflection which I was hoping someone here could address. [1] RFC 1966 says CLUSTER_LIST When a RR reflects a route from its Clients to a Non-Client peer, it must append the local CLUSTER_ID to the CLUSTER_LIST. If the CLUSTER_LIST is empty, it must create a new one. Using this attribute an RR can identify if the routing information is looped back to the same cluster due to mis-configuration. If the local CLUSTER_ID is found in the cluster-list, the advertisement will be ignored. The RFC doesn't make a statement about attaching a cluster-id on reflecting from a Non-Client/Client to a Client. Are there any known problems if the cluster-id is attached for the non-client/client to client reflections? [2] The use of Originator-ids is not completely clear to me - It seems that they are primarily used in a bogus-update-sending-suppression capacity. Is it ever the case that a misconfiguration leads to a receiving router discarding an update because its router-id matches the originator-id? On a related note, is it safe for a reflector to set the originator-id as follows : a) Don't overwrite originator-ids already attached to an update. b) Route from EBGP peer - set Originator id to my router-id before sending it out. IBGP peers which do not understand this attribute will ignore it. c) Route from IBGP peer - set Originator-id to the router-id of the IBGP peer. Since the first reflector seeing an update knows the router-id of the IBGP peer it can set this correctly. (router-id is used to denote bgp-identifier.) Thanks in advance for your comments. --rohit. #include /* Opinions mine alone ! */ From adm Tue Feb 24 10:58:53 1998 Delivery-Date: Tue, 24 Feb 1998 11:04:50 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id KAA21206 for ietf-123-outbound.10@ietf.org; Tue, 24 Feb 1998 10:57:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA21015; Tue, 24 Feb 1998 10:55:28 -0500 (EST) Message-Id: <199802241555.KAA21015@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-route-damp-02.txt,.ps Date: Tue, 24 Feb 1998 10:55:28 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Route Flap Damping Author(s) : C. Villamizar, R. Govindan, R. Chandra Filename : draft-ietf-idr-route-damp-02.txt,.ps Pages : 33 Date : 23-Feb-98 A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes. This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead An excessive rate of update to the advertised reachability of a subset of Internet prefixes has been widespread in the Internet. This observation was made in the early 1990s by many people involved in Internet operations and remains the case. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is ``route flap''. The techniques described here are now widely deployed and are commonly referred to as ``route flap damping''. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-damp-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-route-damp-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-damp-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980223170238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-damp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-damp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980223170238.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Tue Feb 24 11:48:31 1998 Delivery-Date: Tue, 24 Feb 1998 11:48:31 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA24228 for ; Tue, 24 Feb 1998 11:48:31 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07913 for ; Tue, 24 Feb 1998 11:51:09 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA25252 for idr-outgoing; Tue, 24 Feb 1998 10:55:40 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA25246 for ; Tue, 24 Feb 1998 10:55:33 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA21015; Tue, 24 Feb 1998 10:55:28 -0500 (EST) Message-Id: <199802241555.KAA21015@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-route-damp-02.txt,.ps Date: Tue, 24 Feb 1998 10:55:28 -0500 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Route Flap Damping Author(s) : C. Villamizar, R. Govindan, R. Chandra Filename : draft-ietf-idr-route-damp-02.txt,.ps Pages : 33 Date : 23-Feb-98 A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes. This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead An excessive rate of update to the advertised reachability of a subset of Internet prefixes has been widespread in the Internet. This observation was made in the early 1990s by many people involved in Internet operations and remains the case. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is ``route flap''. The techniques described here are now widely deployed and are commonly referred to as ``route flap damping''. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-damp-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-route-damp-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-damp-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980223170238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-damp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-damp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980223170238.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Tue Feb 24 15:06:31 1998 Delivery-Date: Tue, 24 Feb 1998 15:06:31 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA01820 for ; Tue, 24 Feb 1998 15:06:30 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA08789 for ; Tue, 24 Feb 1998 15:09:08 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA29795 for idr-outgoing; Tue, 24 Feb 1998 14:42:29 -0500 (EST) Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by merit.edu (8.8.7/8.8.5) with SMTP id OAA29788 for ; Tue, 24 Feb 1998 14:42:21 -0500 (EST) Received: by iol.unh.edu (4.1/SMI-4.1) id AA03597; Tue, 24 Feb 98 14:39:38 EST Date: Tue, 24 Feb 1998 14:39:36 -0500 (EST) From: "Michael S. Briggs" To: idr@merit.edu Cc: bgp@ans.net, msb@sun4.iol.unh.edu Subject: next hop attribute in BGP multiprotocol packets Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Has a decision been made on whether the v4 Next Hop attribute (attribute type code 3) should be included in BGP MP packets? It appears thatThis attribute is essentially useless in a BGP Multi-Protocol packet, however, according to BGP4 it is a well-known mandatory attribute. Nothing in the BGP MP draft says otherwise. So, should it be included? It would be nice if the draft could be explicit about this. I would appreciate any comments. Thanks, Mike Briggs ------------------------------------------------------------ Michael Briggs UNH InterOperability Lab msb@sun4.iol.unh.edu IP/Routing Consortium ------------------------------------------------------------- From owner-idr@merit.edu Tue Feb 24 15:18:08 1998 Delivery-Date: Tue, 24 Feb 1998 15:18:08 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA02012 for ; Tue, 24 Feb 1998 15:18:08 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA08828 for ; Tue, 24 Feb 1998 15:20:46 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA29799 for idr-outgoing; Tue, 24 Feb 1998 14:42:34 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA29793 for ; Tue, 24 Feb 1998 14:42:27 -0500 (EST) Received: from iol.unh.edu (sun4.iol.unh.edu [132.177.120.114]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id OAA27830 for ; Tue, 24 Feb 1998 14:42:25 -0500 (EST) Received: by iol.unh.edu (4.1/SMI-4.1) id AA03597; Tue, 24 Feb 98 14:39:38 EST Date: Tue, 24 Feb 1998 14:39:36 -0500 (EST) From: "Michael S. Briggs" To: idr@merit.edu Cc: bgp@ans.net, msb@sun4.iol.unh.edu Subject: next hop attribute in BGP multiprotocol packets Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Has a decision been made on whether the v4 Next Hop attribute (attribute type code 3) should be included in BGP MP packets? It appears thatThis attribute is essentially useless in a BGP Multi-Protocol packet, however, according to BGP4 it is a well-known mandatory attribute. Nothing in the BGP MP draft says otherwise. So, should it be included? It would be nice if the draft could be explicit about this. I would appreciate any comments. Thanks, Mike Briggs ------------------------------------------------------------ Michael Briggs UNH InterOperability Lab msb@sun4.iol.unh.edu IP/Routing Consortium ------------------------------------------------------------- From owner-idr@merit.edu Wed Feb 25 03:49:32 1998 Delivery-Date: Wed, 25 Feb 1998 03:49:33 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA22780 for ; Wed, 25 Feb 1998 03:49:28 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA10929 for ; Wed, 25 Feb 1998 03:52:04 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id DAA09001 for idr-outgoing; Wed, 25 Feb 1998 03:26:03 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id DAA08996 for ; Wed, 25 Feb 1998 03:25:58 -0500 (EST) Received: from megalon.rs.itd.umich.edu (0@megalon.rs.itd.umich.edu [141.211.83.27]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id DAA00115 for ; Wed, 25 Feb 1998 03:25:57 -0500 (EST) Received: from merit.edu (pm333-01.dialip.mich.net [141.211.88.141]) by megalon.rs.itd.umich.edu (8.8.5/2.4) with ESMTP id DAA12595; Wed, 25 Feb 1998 03:26:51 -0500 (EST) Message-Id: <199802250826.DAA12595@megalon.rs.itd.umich.edu> To: "Michael S. Briggs" Cc: idr@merit.edu, bgp@ans.net Subject: Re: next hop attribute in BGP multiprotocol packets Date: Wed, 25 Feb 1998 03:25:29 -0500 From: Masaki Hirabaru Sender: owner-idr@merit.edu Precedence: bulk Let me ask more basic question. Can't a BGP4 MP packet carry both IPv4 and IPv6 NRI? Suppose that there are two MP (v4 and v6) routers peering, 1) they need to establish two TCP (v4 and v6) connections? 2) they share a TCP connection, interleaving IPv4 and v6 updates? 3) they may send both IPv4 and IPv6 NRIs in a MP update? Thanks, Masaki >> Date: Tue, 24 Feb 1998 14:39:36 -0500 (EST) >> From: "Michael S. Briggs" >> To: idr@merit.edu >> Cc: bgp@ans.net, msb@sun4.iol.unh.edu >> Subject: next hop attribute in BGP multiprotocol packets >> >> >> Has a decision been made on whether the v4 Next Hop attribute (attribute >> type code 3) should be included in BGP MP packets? It appears thatThis >> attribute is essentially useless in a BGP Multi-Protocol packet, >> however, according to BGP4 it is a well-known mandatory attribute. >> Nothing in the BGP MP draft says otherwise. So, should it be >> included? It would be nice if the draft could be explicit about this. I >> would appreciate any comments. >> >> Thanks, >> Mike Briggs >> ------------------------------------------------------------ >> Michael Briggs UNH InterOperability Lab >> msb@sun4.iol.unh.edu IP/Routing Consortium >> ------------------------------------------------------------- From owner-idr@merit.edu Wed Feb 25 03:54:20 1998 Delivery-Date: Wed, 25 Feb 1998 03:54:20 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id DAA22886 for ; Wed, 25 Feb 1998 03:54:19 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id DAA10938 for ; Wed, 25 Feb 1998 03:56:56 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id DAA08997 for idr-outgoing; Wed, 25 Feb 1998 03:25:59 -0500 (EST) Received: from megalon.rs.itd.umich.edu (0@megalon.rs.itd.umich.edu [141.211.83.27]) by merit.edu (8.8.7/8.8.5) with ESMTP id DAA08991; Wed, 25 Feb 1998 03:25:54 -0500 (EST) Received: from merit.edu (pm333-01.dialip.mich.net [141.211.88.141]) by megalon.rs.itd.umich.edu (8.8.5/2.4) with ESMTP id DAA12595; Wed, 25 Feb 1998 03:26:51 -0500 (EST) Message-Id: <199802250826.DAA12595@megalon.rs.itd.umich.edu> To: "Michael S. Briggs" Cc: idr@merit.edu, bgp@ans.net Subject: Re: next hop attribute in BGP multiprotocol packets Date: Wed, 25 Feb 1998 03:25:29 -0500 From: Masaki Hirabaru Sender: owner-idr@merit.edu Precedence: bulk Let me ask more basic question. Can't a BGP4 MP packet carry both IPv4 and IPv6 NRI? Suppose that there are two MP (v4 and v6) routers peering, 1) they need to establish two TCP (v4 and v6) connections? 2) they share a TCP connection, interleaving IPv4 and v6 updates? 3) they may send both IPv4 and IPv6 NRIs in a MP update? Thanks, Masaki >> Date: Tue, 24 Feb 1998 14:39:36 -0500 (EST) >> From: "Michael S. Briggs" >> To: idr@merit.edu >> Cc: bgp@ans.net, msb@sun4.iol.unh.edu >> Subject: next hop attribute in BGP multiprotocol packets >> >> >> Has a decision been made on whether the v4 Next Hop attribute (attribute >> type code 3) should be included in BGP MP packets? It appears thatThis >> attribute is essentially useless in a BGP Multi-Protocol packet, >> however, according to BGP4 it is a well-known mandatory attribute. >> Nothing in the BGP MP draft says otherwise. So, should it be >> included? It would be nice if the draft could be explicit about this. I >> would appreciate any comments. >> >> Thanks, >> Mike Briggs >> ------------------------------------------------------------ >> Michael Briggs UNH InterOperability Lab >> msb@sun4.iol.unh.edu IP/Routing Consortium >> ------------------------------------------------------------- From owner-idr@merit.edu Wed Feb 25 10:26:36 1998 Delivery-Date: Wed, 25 Feb 1998 10:26:36 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA28666 for ; Wed, 25 Feb 1998 10:26:35 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA11866 for ; Wed, 25 Feb 1998 10:29:13 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA12007 for idr-outgoing; Wed, 25 Feb 1998 09:56:48 -0500 (EST) Received: from gate2.sprintlink.net (gate2.sprintlink.net [199.0.233.3]) by merit.edu (8.8.7/8.8.5) with SMTP id JAA11997; Wed, 25 Feb 1998 09:56:38 -0500 (EST) Received: from iscserv.res.sprintlink.net by gate2.sprintlink.net via smtpd (for merit.edu [198.108.1.42]) with SMTP; 25 Feb 1998 14:56:38 UT Received: from localhost (rdasilva@localhost) by iscserv.res.sprintlink.net (8.8.5/8.6.12) with SMTP id JAA11207; Wed, 25 Feb 1998 09:46:28 -0500 (EST) X-Authentication-Warning: iscserv.res.sprintlink.net: rdasilva owned process doing -bs Date: Wed, 25 Feb 1998 09:46:27 -0500 (EST) From: Ron da Silva X-Sender: rdasilva@iscserv.res.sprintlink.net To: Masaki Hirabaru cc: "Michael S. Briggs" , idr@merit.edu, bgp@ans.net Subject: Re: next hop attribute in BGP multiprotocol packets In-Reply-To: <199802250826.DAA12595@megalon.rs.itd.umich.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk from a protocol standpoint, either can be introduced in an update msg using a different type code. bgp speakers that don't recognize the type code should drop the update. different tcp connections would be implementation specific. at least that's the way i understood the rfc. -ron On Wed, 25 Feb 1998, Masaki Hirabaru wrote: > Let me ask more basic question. > Can't a BGP4 MP packet carry both IPv4 and IPv6 NRI? > > Suppose that there are two MP (v4 and v6) routers peering, > 1) they need to establish two TCP (v4 and v6) connections? > 2) they share a TCP connection, interleaving IPv4 and v6 updates? > 3) they may send both IPv4 and IPv6 NRIs in a MP update? > > Thanks, > Masaki > > >> Date: Tue, 24 Feb 1998 14:39:36 -0500 (EST) > >> From: "Michael S. Briggs" > >> To: idr@merit.edu > >> Cc: bgp@ans.net, msb@sun4.iol.unh.edu > >> Subject: next hop attribute in BGP multiprotocol packets > >> > >> > >> Has a decision been made on whether the v4 Next Hop attribute (attribute > >> type code 3) should be included in BGP MP packets? It appears thatThis > >> attribute is essentially useless in a BGP Multi-Protocol packet, > >> however, according to BGP4 it is a well-known mandatory attribute. > >> Nothing in the BGP MP draft says otherwise. So, should it be > >> included? It would be nice if the draft could be explicit about this. I > >> would appreciate any comments. > >> > >> Thanks, > >> Mike Briggs > >> ------------------------------------------------------------ > >> Michael Briggs UNH InterOperability Lab > >> msb@sun4.iol.unh.edu IP/Routing Consortium > >> ------------------------------------------------------------- From owner-idr@merit.edu Wed Feb 25 10:32:56 1998 Delivery-Date: Wed, 25 Feb 1998 10:32:56 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA28966 for ; Wed, 25 Feb 1998 10:32:55 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA11908 for ; Wed, 25 Feb 1998 10:35:33 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA12018 for idr-outgoing; Wed, 25 Feb 1998 09:56:59 -0500 (EST) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id JAA12012 for ; Wed, 25 Feb 1998 09:56:53 -0500 (EST) Received: from gate2.sprintlink.net (gate2.sprintlink.net [199.0.233.3]) by mail.nyp.ans.net (8.8.7/8.8.7) with SMTP id JAA15353 for ; Wed, 25 Feb 1998 09:56:49 -0500 (EST) Received: from iscserv.res.sprintlink.net by gate2.sprintlink.net via smtpd (for mail.nyp.ans.net [147.225.190.25]) with SMTP; 25 Feb 1998 14:56:48 UT Received: from localhost (rdasilva@localhost) by iscserv.res.sprintlink.net (8.8.5/8.6.12) with SMTP id JAA11207; Wed, 25 Feb 1998 09:46:28 -0500 (EST) X-Authentication-Warning: iscserv.res.sprintlink.net: rdasilva owned process doing -bs Date: Wed, 25 Feb 1998 09:46:27 -0500 (EST) From: Ron da Silva X-Sender: rdasilva@iscserv.res.sprintlink.net To: Masaki Hirabaru cc: "Michael S. Briggs" , idr@merit.edu, bgp@ans.net Subject: Re: next hop attribute in BGP multiprotocol packets In-Reply-To: <199802250826.DAA12595@megalon.rs.itd.umich.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk from a protocol standpoint, either can be introduced in an update msg using a different type code. bgp speakers that don't recognize the type code should drop the update. different tcp connections would be implementation specific. at least that's the way i understood the rfc. -ron On Wed, 25 Feb 1998, Masaki Hirabaru wrote: > Let me ask more basic question. > Can't a BGP4 MP packet carry both IPv4 and IPv6 NRI? > > Suppose that there are two MP (v4 and v6) routers peering, > 1) they need to establish two TCP (v4 and v6) connections? > 2) they share a TCP connection, interleaving IPv4 and v6 updates? > 3) they may send both IPv4 and IPv6 NRIs in a MP update? > > Thanks, > Masaki > > >> Date: Tue, 24 Feb 1998 14:39:36 -0500 (EST) > >> From: "Michael S. Briggs" > >> To: idr@merit.edu > >> Cc: bgp@ans.net, msb@sun4.iol.unh.edu > >> Subject: next hop attribute in BGP multiprotocol packets > >> > >> > >> Has a decision been made on whether the v4 Next Hop attribute (attribute > >> type code 3) should be included in BGP MP packets? It appears thatThis > >> attribute is essentially useless in a BGP Multi-Protocol packet, > >> however, according to BGP4 it is a well-known mandatory attribute. > >> Nothing in the BGP MP draft says otherwise. So, should it be > >> included? It would be nice if the draft could be explicit about this. I > >> would appreciate any comments. > >> > >> Thanks, > >> Mike Briggs > >> ------------------------------------------------------------ > >> Michael Briggs UNH InterOperability Lab > >> msb@sun4.iol.unh.edu IP/Routing Consortium > >> ------------------------------------------------------------- From owner-idr@merit.edu Fri Mar 13 11:56:46 1998 Delivery-Date: Fri, 13 Mar 1998 11:56:47 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA07669 for ; Fri, 13 Mar 1998 11:56:46 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA24094 for ; Fri, 13 Mar 1998 11:59:20 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA25215 for idr-outgoing; Fri, 13 Mar 1998 11:11:42 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA25211 for ; Fri, 13 Mar 1998 11:11:39 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA04381; Fri, 13 Mar 1998 11:11:34 -0500 (EST) Message-Id: <199803131611.LAA04381@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp-tcp-md5-00.txt Date: Fri, 13 Mar 1998 11:11:33 -0500 Sender: owner-idr@merit.edu Precedence: bulk --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 : Protection of BGP Sessions via the TCP MD5 Signature Option Author(s) : A. Heffernan Filename : draft-ietf-idr-bgp-tcp-md5-00.txt Pages : 5 Date : 13-Mar-98 This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in a TCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points. Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP. This document specifies an experimental protocol for use in the Internet. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-tcp-md5-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-tcp-md5-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-tcp-md5-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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980313084254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-tcp-md5-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-tcp-md5-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313084254.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Fri Mar 13 14:09:32 1998 Delivery-Date: Fri, 13 Mar 1998 14:09:34 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA20875 for ; Fri, 13 Mar 1998 14:09:31 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA24943 for ; Fri, 13 Mar 1998 14:12:04 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA27326 for idr-outgoing; Fri, 13 Mar 1998 13:26:44 -0500 (EST) Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA27320 for ; Fri, 13 Mar 1998 13:26:40 -0500 (EST) Received: by relay.hq.tis.com; id NAA05340; Fri, 13 Mar 1998 13:23:55 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma005298; Fri, 13 Mar 98 13:22:56 -0500 Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id NAA18593; Fri, 13 Mar 1998 13:19:50 -0500 (EST) Date: Fri, 13 Mar 1998 13:19:50 -0500 (EST) From: Sandy Murphy Message-Id: <199803131819.NAA18593@clipper.hq.tis.com> To: idr@merit.edu Subject: comment on protecting BGP update security Cc: sandy@tis.com Sender: owner-idr@merit.edu Precedence: bulk At the DC IETF, I presented a draft discussing different protections for the security of BGP updates. I promised a new draft with some increased emphasis on issues I did not cover thoroughly. But I've not been able to break free and this last all important week I've been at a meeting with connection problems, so I doubt I'll be able to meet the deadline today. But there is one point that I wanted to make. Someone who was at the meeting told me that I left the group with some confusion about the vulnerabilities in the various approaches. One of the protections was to sign the original announcement of a network by the announcing AS. This can help protect against spurious announcements of networks by AS's that have no business doing so IF you couple checking the singature with checking an authority that can attest that the AS is authorized to speak for that address. But. Anyone can cut and paste this signed announcement into their update. So you know that the announcement is genuine and authorized, but you do not know that the path in between is genuine. Another protection was to sign the original announcement but to also sign the AS-PATH at each router that passes the route on. It was suggested to me that I left the impression that this is also subject to the cut and paste attack. It's not - what you sign at each router is the AS-PATH you're exporting *AND* the neighbor you are sending it to. So you can check the path against the nested signatures to guard against anyone snipping a piece out of the path and attempting to paste it into a path they export. Clear as mud? Send mail. Finally, I'd like to point to the work that got posted last week that proposes how to add authorization protection to the routing registries. (This is not me, it's mostly Curtis Villamizer and Carol Orange.) An authenticated authorized routing registry is yet another (probably more palatable) technique to judging the validity of received updates. --Sandy Murphy From adm Fri Mar 13 16:36:31 1998 Delivery-Date: Fri, 13 Mar 1998 16:40:42 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id QAA28736 for ietf-123-outbound.10@ietf.org; Fri, 13 Mar 1998 16:35:03 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA04381; Fri, 13 Mar 1998 11:11:34 -0500 (EST) Message-Id: <199803131611.LAA04381@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp-tcp-md5-00.txt Date: Fri, 13 Mar 1998 11:11:33 -0500 Sender: cclark@cnri.reston.va.us --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 : Protection of BGP Sessions via the TCP MD5 Signature Option Author(s) : A. Heffernan Filename : draft-ietf-idr-bgp-tcp-md5-00.txt Pages : 5 Date : 13-Mar-98 This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in a TCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points. Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP. This document specifies an experimental protocol for use in the Internet. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-tcp-md5-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-tcp-md5-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-tcp-md5-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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980313084254.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-tcp-md5-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-tcp-md5-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313084254.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Mon Mar 16 09:45:16 1998 Delivery-Date: Mon, 16 Mar 1998 09:45:17 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA19602 for ; Mon, 16 Mar 1998 09:45:16 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA02716 for ; Mon, 16 Mar 1998 09:47:50 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA02006 for idr-outgoing; Mon, 16 Mar 1998 08:56:36 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA02001 for ; Mon, 16 Mar 1998 08:56:32 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA16327; Mon, 16 Mar 1998 08:56:28 -0500 (EST) Message-Id: <199803161356.IAA16327@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-aggregation-tutorial-01.txt Date: Mon, 16 Mar 1998 08:56:27 -0500 Sender: owner-idr@merit.edu Precedence: bulk --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 : Route Aggregation Tutorial Author(s) : E. Chen, J. Stewart III Filename : draft-ietf-idr-aggregation-tutorial-01.txt Pages : 8 Date : 13-Mar-98 Route aggregation is critical to the long-term viability of the Internet. This document presents practical information that network managers can use to both understand the concepts of aggregation as well as put those concepts into use in order to do their part to make the Internet stable and allow its continued growth. The intended audience for this document is anyone responsible for configuring a network which has its own Autonomous System Number (ASN) and exchanges routing information with its Internet Service Provider(s) (ISP(s)) using the Border Gateway Protocol (BGP). This document does not cover multi-homing, though multi-homed sites can still benefit from understanding this material. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aggregation-tutorial-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-aggregation-tutorial-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aggregation-tutorial-01.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980313112052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aggregation-tutorial-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aggregation-tutorial-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313112052.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Mon Mar 16 09:49:35 1998 Delivery-Date: Mon, 16 Mar 1998 09:49:35 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA19900 for ; Mon, 16 Mar 1998 09:49:34 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA02730 for ; Mon, 16 Mar 1998 09:52:08 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA01998 for idr-outgoing; Mon, 16 Mar 1998 08:56:26 -0500 (EST) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA01994 for ; Mon, 16 Mar 1998 08:56:22 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA16289; Mon, 16 Mar 1998 08:56:18 -0500 (EST) Message-Id: <199803161356.IAA16289@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-aggregation-framework-02.txt Date: Mon, 16 Mar 1998 08:56:17 -0500 Sender: owner-idr@merit.edu Precedence: bulk --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 : A Framework for Inter-Domain Route Aggregation Author(s) : J. Stewart, E. Chen Filename : draft-ietf-idr-aggregation-framework-02.txt Pages : 14 Date : 13-Mar-98 This document presents a framework for inter-domain route aggregation and shows an example router configuration which ''implement'' this framework. This framework is flexible and scales well as it emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers, and it also strongly encourages the use of the ''no-export'' BGP community to balance the provider-subscriber need for more granular routing information with the Internet's need for scalable inter-domain routing. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aggregation-framework-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-aggregation-framework-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aggregation-framework-02.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980313111822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aggregation-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aggregation-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313111822.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Mon Mar 16 17:16:29 1998 Delivery-Date: Mon, 16 Mar 1998 17:22:07 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id RAA19478 for ietf-123-outbound.10@ietf.org; Mon, 16 Mar 1998 17:15:02 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA16289; Mon, 16 Mar 1998 08:56:18 -0500 (EST) Message-Id: <199803161356.IAA16289@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-aggregation-framework-02.txt Date: Mon, 16 Mar 1998 08:56:17 -0500 Sender: cclark@cnri.reston.va.us --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 : A Framework for Inter-Domain Route Aggregation Author(s) : J. Stewart, E. Chen Filename : draft-ietf-idr-aggregation-framework-02.txt Pages : 14 Date : 13-Mar-98 This document presents a framework for inter-domain route aggregation and shows an example router configuration which ''implement'' this framework. This framework is flexible and scales well as it emphasizes the philosophy of aggregation by the source, both within routing domains as well as towards upstream providers, and it also strongly encourages the use of the ''no-export'' BGP community to balance the provider-subscriber need for more granular routing information with the Internet's need for scalable inter-domain routing. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aggregation-framework-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-aggregation-framework-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aggregation-framework-02.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980313111822.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aggregation-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aggregation-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313111822.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Mon Mar 16 17:26:35 1998 Delivery-Date: Mon, 16 Mar 1998 17:30:06 -0500 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.7/8.8.7a) id RAA21139 for ietf-123-outbound.10@ietf.org; Mon, 16 Mar 1998 17:25:05 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id IAA16327; Mon, 16 Mar 1998 08:56:28 -0500 (EST) Message-Id: <199803161356.IAA16327@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-aggregation-tutorial-01.txt Date: Mon, 16 Mar 1998 08:56:27 -0500 Sender: cclark@cnri.reston.va.us --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 : Route Aggregation Tutorial Author(s) : E. Chen, J. Stewart III Filename : draft-ietf-idr-aggregation-tutorial-01.txt Pages : 8 Date : 13-Mar-98 Route aggregation is critical to the long-term viability of the Internet. This document presents practical information that network managers can use to both understand the concepts of aggregation as well as put those concepts into use in order to do their part to make the Internet stable and allow its continued growth. The intended audience for this document is anyone responsible for configuring a network which has its own Autonomous System Number (ASN) and exchanges routing information with its Internet Service Provider(s) (ISP(s)) using the Border Gateway Protocol (BGP). This document does not cover multi-homing, though multi-homed sites can still benefit from understanding this material. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-aggregation-tutorial-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-aggregation-tutorial-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-aggregation-tutorial-01.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980313112052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-aggregation-tutorial-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-aggregation-tutorial-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980313112052.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Fri Mar 20 07:06:50 1998 Delivery-Date: Fri, 20 Mar 1998 07:06:50 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA12771 for ; Fri, 20 Mar 1998 07:06:49 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA22016 for ; Fri, 20 Mar 1998 07:09:20 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id GAA16938 for idr-outgoing; Fri, 20 Mar 1998 06:21:56 -0500 (EST) Received: from rs.digital-magic.co.jp (rs.digital-magic.co.jp [203.181.89.7]) by merit.edu (8.8.7/8.8.5) with ESMTP id GAA16934 for ; Fri, 20 Mar 1998 06:21:52 -0500 (EST) Received: (from kunihiro@localhost) by rs.digital-magic.co.jp (8.8.5/8.7.3) id UAA26873; Fri, 20 Mar 1998 20:24:18 +0900 (JST) Date: Fri, 20 Mar 1998 20:24:18 +0900 (JST) Message-Id: <199803201124.UAA26873@rs.digital-magic.co.jp> From: Kunihiro Ishiguro To: idr@merit.edu Subject: Comments on RFC2283 Sender: owner-idr@merit.edu Precedence: bulk Hi this is Kunihiro Ishiguro. I know before I-D becomes RFC, there was a period of time to read and comment about it. But after RFC2283 Multiprotocol Extentions for BGP-4 was published we (me and Mr. Ikuo Nakagawa) carefully reread it and realize we have to comment on one of the part of it. At the end of section 4 of RFC2283. > If such a message is received from an > external peer, the local system shall check whether the leftmost AS > in the AS_PATH attribute is equal to the autonomous system number of > the peer than sent the message. If that is not the case, the local > system shall send the NOTIFICATION message with Error Code UPDATE > Message Error, and the Error Subcode set to Malformed AS_PATH. In case of one of the peer is BGP Route Server, this may be always happen. Some BGP Route Server doesn't insert it's own AS number in the AS path to emulate direct peering. This may become a obstacle to those who are developing BGP protocol Route Server like us. I'm not sure the original intent of this part is security consideration or preventing masquerading other AS number but I think sometimes leftmost AS number is different case exists. 'shall' can be taken various means I hope people take it as optional and configurable. P.S. If the day every router implementation take above strategy come, we can rid all of the left most AS from update packet's AS_PATH value because receiver already knows it. Sorry for very late comment. -- Kunihiro Ishiguro From owner-idr@merit.edu Wed Mar 25 06:22:01 1998 Delivery-Date: Wed, 25 Mar 1998 06:22:02 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id GAA29402 for ; Wed, 25 Mar 1998 06:21:57 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id GAA10690 for ; Wed, 25 Mar 1998 06:24:27 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA23150 for idr-outgoing; Wed, 25 Mar 1998 05:52:23 -0500 (EST) Received: from vsnl-relay.iucaa.ernet.in (vsnl-relay.iucaa.ernet.in [202.141.155.2]) by merit.edu (8.8.7/8.8.5) with SMTP id FAA23146 for ; Wed, 25 Mar 1998 05:52:17 -0500 (EST) Received: by vsnl-relay.iucaa.ernet.in; id AA18249; Wed, 25 Mar 1998 16:23:13 +0500 Received: from ece.iisc.ernet.in by iisc.ernet.in (ERNET-IISc/SMI-4.1) id QAA07356; Wed, 25 Mar 1998 16:20:17 +0530 Received: by ece.iisc.ernet.in (4.1/SMI-4.1) id AA23547; Wed, 25 Mar 98 16:20:16+0530 Date: Wed, 25 Mar 1998 16:18:50 +0530 (GMT+05:30) From: "Vadapalli.V.V.J.Raghu" Subject: Route Aggregation. To: idr@merit.edu Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk Dear All Are there any documents related to Quality of Service support to BGP4. With Regards -Raghu. IISC Bangalore INDIA From owner-idr@merit.edu Thu Apr 2 15:07:20 1998 Delivery-Date: Thu, 02 Apr 1998 15:07:20 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id PAA12474 for ; Thu, 2 Apr 1998 15:07:20 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA26282 for ; Thu, 2 Apr 1998 15:09:49 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA25757 for idr-outgoing; Thu, 2 Apr 1998 14:38:26 -0500 (EST) Received: from merit.edu (skh@idrp.merit.edu [198.108.60.89]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA25753; Thu, 2 Apr 1998 14:38:21 -0500 (EST) Message-Id: <199804021938.OAA25753@merit.edu> To: idr@merit.edu cc: skh@merit.edu Subject: Notes for IDR working group Date: Thu, 02 Apr 1998 14:38:20 -0500 From: Susan Hares Sender: owner-idr@merit.edu Precedence: bulk Rough and ready notes 1) Agenda Bashing 2) Aggregations I-Ds - draft-ietf-idr-aggregation-framework-02.txt - draft-ietf-idr-aggregation-tutorial-01.txt 3) BGP-4 over ATM and Proxy PAR 4) DNS-based NLRI origin AS verification in BGP 5) DNS-based NLRI origin AS verification in BGP 6) RR RFC status 7) Confederation ---------- 1)Aggregation Framework Presentation: draft-ietf-idr-aggregation-framework-01.txt Successful proxy aggregation requires coordination on a very large scale (i.e., between draft-ietf-idr-aggregation-framework-02.txt Proxy aggregation may be appropriate on a small scale where the necessary coordination is tractable. However, on a large scale, experience has shown that proxy aggregation is problematic because the coordination is tractable. Discussion Coordination is possible. [Curtis V.] Coordination is done, but unfeasbile. [Tony Li] Discussion will continue on the mailing list. 2) Proxy par (draft-droz-proxypar-arch-00.txt) Draft was explained. Slides are available at: Automatic detection of peers across ATM clouds. Depends on the PNNI flooding within the ATM cloud. BGP work entails: Each BGP peer registers with its ATM cloud - ATM address, - IP instance - IP address, - IP mask, - BGP Identifier, - Route reflector type as one of: - Reflector of a certain cluster or - client of a certain cluster or - non-client Each BGP queries for - BGP peers in different ASes to form E-BGP adjacencies - BGP Peers in the same AS to form i_BGP adjacencies to (works with route reflectors) Misc - Security issues, - Implict address resolution for ATM Discussion: Discussion of OSPF LSAs or ISIS TLVs to do auto-configuration for BGP peers. Questions if auto-configuration is necessary in the ISP/NSP environment. [Curtis, Enke Chen] The trust level of the NSP/ISPs does not extend to Autoconfiguration. [Peter Lothberg] The "plug-in" auto-configuration feature is unwise for external BGP peers. [Yakov Rekhter] Problem that you are trying to solve is the discovery of of ATM edge devices. [Dino F.] The scope of ATM PAR may not be Jay Hawkinson [GTE networking]. Autoconfiguration in this draft has not address the "shared" secret provided by TCP MD5 draft. [Sandy Murphy] 3) Route Reflector Move Route Reflector to Proposed Standard. 4) Confederation Suggestion that the changes are folded into the draft. The changed BGP confederation draft will be forwarded into the mailing group. 5) Deployed code versus I-D for BGP No MED, treat at 2**32. One vendor's implementation will treat missing MED as zero. Routing loops might be created in networks if the missing MED interpretation occurs. Like to see a clear example of the MED being zero causing loops. [Andrew Partan] We are going to leave the draft at 2**32 for missing MED. Rich Woundy loaded a draft was that proposed this change. We agreed to this change in Montreal and mail archive. Curtis recommends we stand on the draft. Clear consensus on the draft. 6) Draft Standard on MIB MIB caught in 7) Origin Authentication for BGP slides: http://psg.com/~randy/980402.idr/ This can be obviated by a IRR fast and scalable IRR. Randy needs a problem solution now. Discussion ensued. It is a non-goal for this proposal to protect from malcious attack. Jay Hawkinson - Please do not overload the AS syntax in the DNS. Other suggestions were given to randy and the other authors on implementation or clarification of the draft. This does not replace the registry? No it is intended to solve the problem that filter lists do not scale the list. No router vendors can put full access list into box. It is important to have both the allocation hierarchy and the routing prefix hierarchy. Email on this topic can be sent to authors or the mailing group. 8) Suggestion from the floor - no more IDR meetings in the morning. Notes are ***rough***. No authors have been consulted. Please send flames and comments to skh@merit.edu. I'll fix the notes. Sue Hares From owner-idr@merit.edu Fri Apr 3 16:09:08 1998 Delivery-Date: Fri, 03 Apr 1998 16:09:08 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id QAA03824 for ; Fri, 3 Apr 1998 16:09:07 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA18485 for ; Fri, 3 Apr 1998 16:11:39 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA14521 for idr-outgoing; Fri, 3 Apr 1998 15:41:41 -0500 (EST) Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA14517 for ; Fri, 3 Apr 1998 15:41:38 -0500 (EST) Received: by relay.hq.tis.com; id PAA01192; Fri, 3 Apr 1998 15:39:00 -0500 (EST) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma001178; Fri, 3 Apr 98 15:38:04 -0500 Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id PAA26341; Fri, 3 Apr 1998 15:38:19 -0500 (EST) Date: Fri, 3 Apr 1998 15:38:19 -0500 (EST) From: Sandy Murphy Message-Id: <199804032038.PAA26341@clipper.hq.tis.com> To: idr@merit.edu, randy@psg.com Subject: DNS AS origin verification - authorization, authentication, and DNSSEC Cc: sandy@tis.com Sender: owner-idr@merit.edu Precedence: bulk Yakov, Tony, and Randy: I'm still confused about something: - DNS provides a tree in which to store the authorization to announce a prefix. - DNSSEC is used to ensure that the authorization data received from the tree is authentic (received from the authentic source). - BGP Updates are not signed, so anyone could put valid, authorized origin data in their BGP Update - but that is not considered a drawback, because this technique is intended to stop damage from the recurring, frequent misconfiguration problems. This technique is not attempting to prevent deliberate and malicious threats. So this technique is using DNSSEC to prevent malicious people from spoofing the authorization data - but it is not attempting to prevent malicious people from inserting authentic authorization data in their updates. Put another way - if we are excluding malicious evil-doers from the threats this technique protects against, why do we care that DNSSEC is available? I don't think there are huge problems with accidental misconfigurations in the domain name space. Of course, I've been wrong before. --Sandy Murphy From owner-idr@merit.edu Sat Apr 4 04:38:04 1998 Delivery-Date: Sat, 04 Apr 1998 04:38:05 -0500 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id EAA18358 for ; Sat, 4 Apr 1998 04:38:04 -0500 (EST) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id EAA20384 for ; Sat, 4 Apr 1998 04:40:32 -0500 (EST) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id EAA21520 for idr-outgoing; Sat, 4 Apr 1998 04:09:55 -0500 (EST) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id EAA21516 for ; Sat, 4 Apr 1998 04:09:51 -0500 (EST) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id BAA04108; Sat, 4 Apr 1998 01:09:20 -0800 (PST) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id BAA29121; Sat, 4 Apr 1998 01:09:05 -0800 (PST) To: sandy@tis.com (Sandy Murphy) cc: idr@merit.edu Subject: Re: DNS AS origin verification - authorization, authentication, and DNSSEC References: <199804032038.PAA26341@clipper.hq.tis.com> From: Tony Li Date: 04 Apr 1998 01:09:05 -0800 In-Reply-To: sandy@tis.com's message of 3 Apr 98 20:38:19 GMT Message-ID: <821zve0x8u.fsf@chimp.juniper.net> Lines: 21 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-idr@merit.edu Precedence: bulk sandy@tis.com (Sandy Murphy) writes: > I'm still confused about something: > So this technique is using DNSSEC to prevent malicious people from > spoofing the authorization data - but it is not attempting to prevent > malicious people from inserting authentic authorization data in their > updates. Sandy, The proposed technique does NOT (repeat NOT) provide security. It is half a loaf, which as we all know when it comes to security, is not better than no loaf. However, this proposal is a reasonable sanity check against accidents. The point about designing in DNSSEC now is so that when we DO get around to signing paths (which as you have noted we must do and I do concur) we will THEN have a full loaf. Tony From owner-idr@merit.edu Sat Apr 11 07:35:59 1998 Delivery-Date: Sat, 11 Apr 1998 07:35:59 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id HAA12372 for ; Sat, 11 Apr 1998 07:35:59 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA13180 for ; Sat, 11 Apr 1998 07:38:28 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id HAA18726 for idr-outgoing; Sat, 11 Apr 1998 07:04:15 -0400 (EDT) Received: from mr.tuwien.ac.at (mr.tuwien.ac.at [128.130.2.10]) by merit.edu (8.8.7/8.8.5) with ESMTP id HAA18722 for ; Sat, 11 Apr 1998 07:04:10 -0400 (EDT) Received: from logo (actually logo.ikn.tuwien.ac.at) by mr.tuwien.ac.at with SMTP (PP); Sat, 11 Apr 1998 13:03:22 +0200 Message-Id: <3.0.3.32.19980411125619.009f57b0@mail.zserv.tuwien.ac.at> X-Sender: vanas@mail.zserv.tuwien.ac.at X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 11 Apr 1998 12:56:19 +0200 To: idr@merit.edu From: "Harmen R. van As" Subject: 8th IFIP Conference on High Performance Networking (HPN'98) Mime-Version: 1.0 Content-Type: text/enriched; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-idr@merit.edu Precedence: bulk Dear member of the Internet Inter-Domain Routing community We still are looking for some papers for the HPN'98 Conference in Vienna. Would there be any change that you or somebody else would be able to submit a contribution within the next two weeks? Please notify coming submission With best regards Harmen R. van As
CALL FOR TUTORIALS CALL FOR PAPERS DEADLINE EXTENDED BUT NOTIFY COMING SUBMISSION ----------------------------------------------------------- 8th IFIP Conference on High Performance Networking (HPN'98) The Millennium Push of Internet =20 Vienna University of Technology, Vienna, Austria September 21-25, 1998 ------------------------------------------------------------ http://www.ikn.tuwien.ac.at/IKN/events/hpn-cfp.html March 15, 1998: Tutorial proposal March 15, 1998: Paper submission April 15, 1998: Notification May 15, 1998: Camera-ready paper =20 Conference book published by Chapman & Hall
Paper submission: preferably postscript file attached to email=20 otherwise 5 copies of paper by postal mail Topics of interest:=20 - Trends of Internet/Intranet Technologies=20 - Next Generation Internet, Evolutionary approaches=20 - Fast Internet (ADSL, HDSL, VHDSL, PONs)=20 - Cable Network, Wireless and Satellite Access=20 - Next Generation Routers, Tag Switching=20 - Bypass Tunneling (SDH, Photonics) =20 - Network/System Architecture and Design=20 - Cache Server Allocation and Interconnection=20 - Network Availability, Automatic Reconfiguration=20 - Coporate Networks, Global Networking =20 - Security in Internet, Network/System Security=20 - Network Management using Internet=20 - WWW and Java Network Service Management=20 - Distributed Systems Management in Internet=20 - Interworking with ATM, ISDN, and LANs=20 - System Interoperability =20 - Internet Mobility Support, Mobility Management=20 - Mobile-IP, Mobile-IPv6=20 - Mobile Agents, Intelligent/Smart Agents=20 - Flow Control, Traffic Monitoring and Control=20 - Adressing and Routing =20 - Advanced Internet Protocols (RTP, RSVP)=20 - Multicast Protocols=20 - Protocol Design, Combined ATM and IP=20 - Secure Protocols (S-HTTP, SSL, SET)=20 - Internet Tunneling =20 - Quality of Service, Service Level Guarantees=20 - Resource Management=20 - Real-Time Services over Internet=20 - IP Telephony, Voice over Internet=20 - Teleconferencing, Broadband Internet=20 - Integrated Services Internet=20 - Internet in Multimedia Environments=20 - Heterogenous Distributed Environments =20 - Internet Groupware and Cooperative Work=20 - Information Management over Internet=20 - Electronic Commerce, Online-Marketing=20 - Internet Payment Systems, Webcasting=20 - WWW Servers, Tele-Service-Systems=20 - Internet Servers (Data-Base, Cache, Archive)=20 - High-Performance Tele-Activities=20 - Social Impacts, Opportunities and Threats=20 INTERNATIONAL PROGRAM COMMITTEE:=20 General Chair:=20 Harmen R. van As, Vienna University of Technology, Austria=20 Ian Akyildiz, Georgia Tech, USA=20 Torsten Braun, Univ. of Berne, CH=20 Augusto Casaca, INESC, Portugal=20 Andre Danthine, Univ. Liege, Belgium=20 Michel Diaz, Univ. Toulouse, France=20 Christophe Diot, INRIA, France=20 Otto Duarte, Univ. Fed. Rio de Janeiro, Brazil=20 J=F6rg Ebersp=E4cher, Techn. Univ. Munich, Germany=20 Serge Fdida, Univ. Paris VI, France=20 Zygmunt Haas, Cornell University, USA=20 Marjory Johnson, NASA-RIACS, USA=20 Paul K=FChn, Univ. Stuttgart, Germany=20 Ralf Lehnert, Dresden Univ. of Technology, Germany=20 Helmut Leopold, Alcatel, Austria=20 Kurt Maly, Old Dominion Univ., USA=20 Olli Martikainen, Helsinki Univ. of Technology, Finland=20 Georg Mittenecker, Vienna Univ. of Technology, Austria=20 Hussein Mouftah, Queens Univ., Canada=20 Ignas Niemegeers, Univ. of Twente, The Netherlands=20 Guru Parulkar, Washington U. St. Louis, USA=20 Stephen Pink, SICS, Sweden=20 Radu Popescu-Zeletin, GMD Fokus, Germany=20 Ramon Puigjanier, Univ. Illes Balears, Spain=20 Guy Pujolle, Univ. Versailles, France=20 Doug Shepherd, Univ. Lancaster, UK=20 Thomas Sommer, Vienna Univ. of Technology, Austria=20 Otto Spaniol, Univ. Aachen, Germany=20 Ralf Steinmetz, Techn. Univ. Darmstadt, Germany=20 Ahmed Tantawi, IBM Res., Yorktown Heights, USA=20 Fouad Tobagi, Stanford Univ., USA=20 Samir Tohm=E9, ENST, France=20 Giorgio Ventre, Univ. Napoli, Italy=20 Martina Zitterbart, Univ. Braunschweig, Germany=20 ---------------------------------------------------------------------------- Prof.Dr. Harmen R. van As Institute of Communication Networks Vienna University of Technology Tel +43-1-58801-5246 Gusshausstrasse 25/388 Fax +43-1-5870583 A-1040 Vienna, Austria email: Harmen.R.van-As@tuwien.ac.at http://www.ikn.tuwien.ac.at=20 ---------------------------------------------------------------------------- From owner-idr@merit.edu Tue Apr 14 11:44:04 1998 Delivery-Date: Tue, 14 Apr 1998 11:44:04 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (cnri [132.151.1.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id LAA26618 for ; Tue, 14 Apr 1998 11:44:04 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA07812 for ; Tue, 14 Apr 1998 11:46:34 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA09543 for idr-outgoing; Tue, 14 Apr 1998 10:57:30 -0400 (EDT) Received: from ns.ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA09539 for ; Tue, 14 Apr 1998 10:57:24 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA25073; Tue, 14 Apr 1998 10:56:34 -0400 (EDT) Message-Id: <199804141456.KAA25073@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-cap-neg-01.txt Date: Tue, 14 Apr 1998 10:56:34 -0400 Sender: owner-idr@merit.edu Precedence: bulk --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 : Capabilities Negotiation with BGP-4 Author(s) : J. Scudder, R. Chandra Filename : draft-ietf-idr-bgp4-cap-neg-01.txt Pages : 4 Date : 10-Apr-98 Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an OPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP. This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability negotiation without requiring that BGP peering be terminated. The proposed parameter is backward compatible - a router that supports the parameter can maintain BGP peering with a router that doesn't support the parameter. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-cap-neg-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp4-cap-neg-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-cap-neg-01.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980410161014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-cap-neg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-cap-neg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980410161014.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Tue Apr 14 12:07:48 1998 Delivery-Date: Tue, 14 Apr 1998 12:19:34 -0400 Return-Path: adm Received: (from adm@localhost) by ns.ietf.org (8.8.5/8.8.7a) id MAA27272 for ietf-123-outbound.10@ietf.org; Tue, 14 Apr 1998 12:05:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.5/8.8.7a) with ESMTP id KAA25073; Tue, 14 Apr 1998 10:56:34 -0400 (EDT) Message-Id: <199804141456.KAA25073@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-cap-neg-01.txt Date: Tue, 14 Apr 1998 10:56:34 -0400 Sender: cclark@cnri.reston.va.us --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 : Capabilities Negotiation with BGP-4 Author(s) : J. Scudder, R. Chandra Filename : draft-ietf-idr-bgp4-cap-neg-01.txt Pages : 4 Date : 10-Apr-98 Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an OPEN message with one or more unrecognized Optional Parameters, the speaker must terminate BGP peering. This complicates introduction of new capabilities in BGP. This document defines new Optional Parameter, called Capabilities, that is expected to facilitate introduction of new capabilities in BGP by providing graceful capability negotiation without requiring that BGP peering be terminated. The proposed parameter is backward compatible - a router that supports the parameter can maintain BGP peering with a router that doesn't support the parameter. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-cap-neg-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp4-cap-neg-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-cap-neg-01.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980410161014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-cap-neg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-cap-neg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980410161014.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Mon May 4 12:58:22 1998 Delivery-Date: Mon, 04 May 1998 12:58:27 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA09613 for ; Mon, 4 May 1998 12:58:20 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA03786 for ; Mon, 4 May 1998 13:00:46 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA15139 for idr-outgoing; Mon, 4 May 1998 12:24:03 -0400 (EDT) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id MAA15133 for ; Mon, 4 May 1998 12:23:53 -0400 (EDT) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id MAA17933; Mon, 4 May 1998 12:22:40 -0400 (EDT) Message-Id: <199805041622.MAA17933@brookfield.ans.net> To: Paul Traina cc: curtis@ans.net, huitema@bellcore.com (Christian Huitema), Quaizar Vohra , Dimitry Haskin , ipng@sunroof.Eng.Sun.COM, idr@merit.edu Reply-To: curtis@ans.net Subject: Re: (IPng 4522) Re: BGP and renumbering.. was /126 or /127 -- neither! In-reply-to: Your message of "Thu, 25 Sep 1997 17:10:44 PDT." <199709260010.RAA05909@base.juniper.net> Date: Mon, 04 May 1998 12:22:40 -0400 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <199709260010.RAA05909@base.juniper.net>, Paul Traina writes: > > From: Curtis Villamizar > Subject: Re: (IPng 4522) Re: BGP and renumbering.. was /126 or /127 -- neit > he > >>r! > > > This could be done with IPv4 as long as there is a way to send a CEASE > that results in putting the routes on a withdrawl timer rather than > immmediately withdrawing them. You could even static configure the > BGP peering for this behavior and not change the protocol at all. > > A cease with a sanely limited short timer is a damn fine swiss-army knife > for solving a lot of problems. > > I feel an ID coming on. :-) John, This was in ftp://ftp.merit.edu/mail.archives/idr/idr.96.09.gz The rest of the conversation seems to be in this archive file. Curtis - - - - - - - - - - - - - - - - - >From owner-idr@merit.edu Sat Sep 14 00:19:57 1996 Received: from merit.edu by nic.merit.edu (8.7.1/nic-1.0) id AAA06209; Sat, 14 Sep 1996 00:19:56 -0400 (EDT) Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id AAA12492 for idr-outgoing; Sat, 14 Sep 1996 00:21:21 -0400 (EDT) Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by merit.edu (8.7.5/merit-2.0) with SMTP id AAA12486 for ; Sat, 14 Sep 1996 00:21:17 -0400 (EDT) Received: by interlock.ans.net id AA00588 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Sat, 14 Sep 1996 00:21:04 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sat, 14 Sep 1996 00:21:04 -0400 Message-Id: <199609140420.AAA21003@brookfield.ans.net> To: bgp@ans.net Cc: curtis@ans.net Reply-To: curtis@ans.net Subject: diffs to draft-ietf-idr-bgp4-03.txt Date: Sat, 14 Sep 1996 00:20:09 -0400 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk Yakov et al. Here are some suggested changes to the BGP4 draft. Briefly, there are a few separable issues: 1. Some wording changes (ie: hunk 1, 6, 7, 8, 14) 2. Proposing "BGP resynchronization". See below. 3. Replace descriptions of route selection with something more clear and accurate. 4. Replace some text about route overlap that is wrong and reflects earlier indecision on the part of the WG. The "BGP resynchronization" warents further mention. The idea was to make something 100% compatible with current BGP4 implementations that addresses the following: 1. Allows a better recovery if running a hosed implementation. No more clearing the BGP conection. 2. Allows a cheap policy reconfig (maybe less desirable than a true dynamic reconfig) that doesn't involve clearing the BGP conection. 3. Reduces the impact of occasional loss of BGP connections. Might even allow you to squeeze in a reload if it was real fast. 4. Reduces the exposure to TCP RST attacks. Given some of the talk on the NANOG list, #4 might not be a bad feature. Fixing BGP to use UDP is a bigger job and this and a good TCP PCB hashing and long listen queue for TCP SYN attack could prove very valuable changes. Curtis Just apply the diffs to draft-ietf-idr-bgp4-03.txt to get the new document. The diff hunks are: 1 an attempt to clear up wording regarding IBGP, EBGP, and IGP and the role of IBGP. 2 First mention of BGP resynchronization 3 I couldn't resist. Might want to leave this one out. 4 Add RESYNCHRONIZATION message type 5 Define RESYNCHRONIZATION message format 6 Clarifying sentence - path attributes are for the purpose of supporting a protocol extension mechanism. 7 Added the table with discresionary, required, or disallowed, etc. 8 Clarification of MULTI_EXIT_DISC usage. 9 Add BGP resynchronization to Error Handling section. 10 Allow marking routes for withdrawl on disconnect. 11 BGP Resynchronization section 12&13 Fixed overlap route jabber that was just plain wrong. 14 Clarified setting LOCAL_PREF. 16 Replaced description of route slection with one that is much more concise and clear and covers the route loop avoidance, including a brief description of the reasons loops can form. 17 Got rid of unclear tie breaker section. 18&19 Replaced the route overlap section with one that reflects reality now that we have plenty of experience with BGP4. 20&21 Eliminated a great deal of repitition and referred back to 9.1.2. btw- why can't 9.2.1 be as simple as 9.2.2 - or does 9.2.2 need to spell things out in detail like 9.2.1? *** draft-ietf-idr-bgp4-03.txt Sat Aug 17 08:34:53 1996 --- draft-ietf-idr-bgp4-03.txt.new Sat Sep 14 00:01:33 1996 *************** *** 205,230 **** router in another Autonomous System. The implications and applications of this architecture are for further study. If a particular AS has multiple BGP speakers and is providing transit service for other ASs, then care must be taken to ensure a consistent view of routing within the AS. A consistent view of the interior routes of the AS is provided by the interior routing protocol. A consistent view of the routes exterior to the AS can be provided by ! having all BGP speakers within the AS maintain direct BGP connections ! with each other. Using a common set of policies, the BGP speakers ! arrive at an agreement as to which border routers will serve as ! exit/entry points for particular destinations outside the AS. This ! information is communicated to the AS's internal routers, possibly ! via the interior routing protocol. Care must be taken to ensure that ! the interior routers have all been updated with transit information ! before the BGP speakers announce to other ASs that transit service is ! being provided. ! ! Connections between BGP speakers of different ASs are referred to as ! "external" links. BGP connections between BGP speakers within the ! same AS are referred to as "internal" links. Similarly, a peer in a ! different AS is referred to as an external peer, while a peer in the ! same AS may be described as an internal peer. --- 205,231 ---- router in another Autonomous System. The implications and applications of this architecture are for further study. + Connections between BGP speakers of different ASs are referred to as + "external" links. BGP connections between BGP speakers within the + same AS are referred to as "internal" links. Similarly, a peer in a + different AS is referred to as an external peer, while a peer in the + same AS may be described as an internal peer. Internal BGP and + external BGP are commonly abbreviated IBGP and EBGP. + If a particular AS has multiple BGP speakers and is providing transit service for other ASs, then care must be taken to ensure a consistent view of routing within the AS. A consistent view of the interior routes of the AS is provided by the interior routing protocol. A consistent view of the routes exterior to the AS can be provided by ! having all BGP speakers within the AS maintain direct IBGP connections ! with each other. Alternately the interior routing protocol can ! pass BGP information among routers within an AS, taking care not to ! lose BGP attributes that will be needed by EBGP speakers if transit ! connectivity is being providided. For the purpose of discussion, ! it is assumed that BGP information is passed within an AS using ! IBGP. Care must be taken to ensure that the interior routers have ! all been updated with transit information before the EBGP speakers ! announce to other ASs that transit service is being provided. *************** *** 282,291 **** Information can be advertised, or c) the BGP speaker - BGP speaker connection can be closed, which ! implicitly removes from service all routes which the pair of ! speakers had advertised to each other. ! ! --- 283,297 ---- Information can be advertised, or c) the BGP speaker - BGP speaker connection can be closed, which ! implicitly marks all routes hte pair of speakers had advertised ! to each other for removal from service if a connection is not ! reestablished and the routes readvertised before a resynchronization ! completed message or before a configured expiration timer elapses. ! ! d) the BGP speaker or listenner may request a resynchronization ! which explicitly marks all routes for removal from service if not ! readvertised before a resynchronization completed message or before ! a configured expiration timer elapses. *************** *** 333,339 **** implementation must maintain three separate copies of the routing information. The choice of implementation (for example, 3 copies of the information vs 1 copy with pointers) is not constrained by the ! protocol. 4. Message Formats --- 339,346 ---- implementation must maintain three separate copies of the routing information. The choice of implementation (for example, 3 copies of the information vs 1 copy with pointers) is not constrained by the ! protocol. And in fact you'd be pretty stupid to maintain separate ! copies though it has been tried. 4. Message Formats *************** *** 435,440 **** --- 442,448 ---- 2 - UPDATE 3 - NOTIFICATION 4 - KEEPALIVE + 5 - RESYNCHRONIZATION 4.2 OPEN Message Format *************** *** 1127,1135 **** --- 1135,1182 ---- + 4.5 RESYNCHRONIZATION Message Format + + + A RESYNCHRONIZATION message is sent when there is reason to believe + that routing information in either the speaker of the listenner is + not correct or routing policy has been changed and the speaker is + unable to process the routing policy change without readvertising + the full set of routes. A RESYNCHRONIZATION message should never + be required except where a policy change has occurred or unless + either the speaker of listenner implementation is in error. + + + In addition to the fixed-size BGP header, the RESYNCHRONIZATION + message contains the following fields: + + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Request Type | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Request Type: + + This 1-octet unsigned integer indicates the type of + RESYNCHRONIZATION request. The following Request Codes have + been defined: + + Request Code Symbolic Name Reference + + 1 Sender Resynchronizing Request Section 6.9 + + 2 Receiver Resynchronize Request Section 6.9 + + 3 Resynchronizion Completed Section 6.9 + + The length of the RESYNCHRONIZATION message is 21 octets (including + message header). + + Expiration Date February 1996 [Page 19] *************** *** 1145,1151 **** This section discusses the path attributes of the UPDATE message. ! Path attributes fall into four separate categories: 1. Well-known mandatory. 2. Well-known discretionary. --- 1192,1199 ---- This section discusses the path attributes of the UPDATE message. ! Path attributes fall into four separate categories for the purpose ! of supporting a protocol extension mechanism: 1. Well-known mandatory. 2. Well-known discretionary. *************** *** 1208,1213 **** --- 1256,1275 ---- The same attribute cannot appear more than once within the Path Attributes field of a particular UPDATE message. + The manditory category refers to a field which must be present in + both IBGP and EBGP exchanges. Attributes classified as optional + for the purpose of the protocol extension mechanism may be purely + discresionary, or discresionary, required, or disallowed in certain + contexts. + + attribute EBGP IBGP + ORIGIN manditory manditory + AS_PATH manditory manditory + NEXT_HOP discresionary discresionary + MULTI_EXIT_DISC discresionary discresionary + LOCAL_PREF disallowed required + ATOMIC_AGGREGATE discresionary discresionary + AGGREGATOR discresionary discresionary 5.1 Path Attribute Usage *************** *** 1342,1348 **** preferred. If received over external links, the MULTI_EXIT_DISC attribute may be propagated over internal links to other BGP speakers within the same AS. The MULTI_EXIT_DISC attribute is never ! propagated to other BGP speakers in neighboring AS's. 5.1.5 LOCAL_PREF --- 1404,1410 ---- preferred. If received over external links, the MULTI_EXIT_DISC attribute may be propagated over internal links to other BGP speakers within the same AS. The MULTI_EXIT_DISC attribute is never ! propagated from IBGP to other BGP speakers in neighboring AS's. 5.1.5 LOCAL_PREF *************** *** 1411,1423 **** attribute which shall contain its own AS number and IP address. ! 6. BGP Error Handling. This section describes actions to be taken when errors are detected ! while processing BGP messages. ! When any of the conditions described here are detected, a NOTIFICATION message with the indicated Error Code, Error Subcode, and Data fields is sent, and the BGP connection is closed. If no Error Subcode is specified, then a zero must be used. --- 1473,1485 ---- attribute which shall contain its own AS number and IP address. ! 6. BGP Error and Resynchronization Handling. This section describes actions to be taken when errors are detected ! while processing BGP messages or during resynchronization. ! When any erro conditions described here are detected, a NOTIFICATION message with the indicated Error Code, Error Subcode, and Data fields is sent, and the BGP connection is closed. If no Error Subcode is specified, then a zero must be used. *************** *** 1425,1431 **** The phrase "the BGP connection is closed" means that the transport protocol connection has been closed and that all resources for that BGP connection have been deallocated. Routing table entries ! 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. --- 1487,1494 ---- The phrase "the BGP connection is closed" means that the transport protocol connection has been closed and that all resources for that BGP connection have been deallocated. Routing table entries ! associated with the remote peer are either marked as invalid or ! optionally marked as if a resynchronization had occurred. The fact that the routes have become invalid is passed to other BGP peers before the routes are deleted from the system. *************** *** 1754,1759 **** --- 1817,1888 ---- message with the Error Code Cease. + 6.9 BGP Resynchronization + + + BGP implementation may optionally support a form of graceful + resynchronization rather than closing the BGP connection in certain + conditions and may optionally allow resynchronization rather than + immediate route withdrawl when a BGP connection is closed. BGP + implementation which support resynchronization must be prepared to + detect and interoperate with implementations which do not. + + A resynchronization request will generally be made in response to + operator intervention. A resynchronization request can also be + made when conditions indicate internal inconsistency, such as + failure of a coded assertion. Implementations which require + resynchronization should be considered in error, however the BGP + protocol accomodates the possibility that errant implementation may + exist (transiently) and provides resynchronization as a means to + restore operational integrity with minimal disruption. + + After sending a RESYNCHRONIZATION message with a Sender + Resynchronizing Request (Request Code 1) or receiving a + RESYNCHRONIZATION message with a Receiver Resynchronize Request + (Request Code 2), the sender must empty the associated Adj-RIBs-Out + and readvertise all route in its Loc-RIB to its peer as described + in section 9.1.3, as if no routes had ever been advertised to that + peer. + + After receiving a RESYNCHRONIZATION message with a Sender + Resynchronizing Request (Request Code 1) or sending a + RESYNCHRONIZATION message with a Receiver Resynchronize Request + (Request Code 2), the receiver must mark all entries in the Loc-RIB + for removal and empty the Adj-RIBs-In. As the Adj-RIBs-In is + repopulated the marks in the associated Loc-RIB entires are + removed. After a configured expiration timer has elapsed or a + RESYNCHRONIZATION message with a Resynchronizion Completed (Request + Code 3) is received, all entries in the Loc-RIB still marked are + removed as it they had been withdrawn. + + Optionally when a BGP connection is closed the Loc-RIB entries may + be treated in the same way they would be when receiving a + RESYNCHRONIZATION message with a Sender Resynchronizing Request. + It should be possible to configure a different expiration timer + value for this condition or disable it entirely. + + Optionally a BGP speaker may send a RESYNCHRONIZATION message with + a Resynchronizion Completed after a connection has been + established, in effect treating the entry to the established state + as an implied RESYNCHRONIZATION message with a Receiver Resynchronize + Request from the peer. + + An implementation which does not support BGP Resynchronization must + send a NOTIFICATION with a Message Header Error (Error Code 1) and a + Bad Message Type (Error subcode 3). + + An implementation which does support BGP Resynchronization must + have the ability to configure a peer as not supporting BGP + Resynchronization and not send any form of RESYNCHRONIZATION + message to such a peer. It must also be able to record the fact + that a peer has sent a NOTIFICATION in response to a + RESYNCHRONIZATION message and disable sending any further + RESYNCHRONIZATION messages to that peer, even after the BGP + connection if broken and reestablished, unless that peer later + sends a RESYNCHRONIZATION message (which would be interpretted as a + code update adding support for BGP Resynchronization). + + 7. BGP Version Negotiation. *************** *** 2085,2095 **** shall run its Decision Process since the older route is no longer available for use. - ii) If the new route is an overlapping route that is included (see - 9.1.4) in an earlier route contained in the Adj-RIB-In, the BGP - speaker shall run its Decision Process since the more specific route - - Expiration Date February 1996 [Page 35] --- 2214,2219 ---- *************** *** 2100,2121 **** INTERNET DRAFT August 1996 ! has implicitly made a portion of the less specific route unavailable ! for use. ! ! iii) If the new route has identical path attributes to an earlier ! route contained in the Adj-RIB-In, and is more specific (see 9.1.4) ! than the earlier route, no further actions are necessary. ! ! iv) If the new route has NLRI that is not present in any of the ! routes currently stored in the Adj-RIB-In, then the new route shall ! be placed in the Adj-RIB-In. The BGP speaker shall run its Decision ! Process. ! ! v) If the new route is an overlapping route that is less specific ! (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the ! BGP speaker shall run its Decision Process on the set of destinations ! described only by the less specific route. 9.1 Decision Process --- 2224,2235 ---- INTERNET DRAFT August 1996 ! ii) If the new route has NLRI that is not present in any of the ! routes currently stored in the Adj-RIB-In, regardless of whether ! the new route overlaps an earlier route contained in the Adj-RIB-In ! that is either more specific or less specific (see 9.1.4), then the ! new route shall be placed in the Adj-RIB-In. The BGP speaker shall ! run its Decision Process. 9.1 Decision Process *************** *** 2199,2213 **** operating on all new or unfeasible routes contained within it. For each newly received or replacement feasible route, the local BGP ! speaker shall determine a degree of preference. If the route is ! learned from a BGP speaker in the local autonomous system, either the value of the LOCAL_PREF attribute shall be taken as the degree of ! preference, or the local system shall compute the degree of ! preference of the route based on preconfigured policy information. If ! the route is learned from a BGP speaker in a neighboring autonomous ! system, then the degree of preference shall be computed based on ! preconfigured policy information. The exact nature of this policy ! information and the computation involved is a local matter. The --- 2313,2327 ---- operating on all new or unfeasible routes contained within it. For each newly received or replacement feasible route, the local BGP ! speaker shall determine a degree of preference. If the route is ! learned from a BGP speaker in the local autonomous system, the value of the LOCAL_PREF attribute shall be taken as the degree of ! preference. If the route is learned from a BGP speaker in a ! neighboring autonomous system, then the degree of preference shall ! be computed based on preconfigured policy information and used as ! the LOCAL_PREF value in any IBGP readvertisement. The exact nature ! of this policy information and the computation involved is a local ! matter. The *************** *** 2243,2259 **** the local BGP speaker doesn't have a route in its Loc-RIB, the BGP route SHOULD be excluded from the Phase 2 decision function. ! For each set of destinations for which a feasible route exists in the ! Adj-RIBs-In, the local BGP speaker shall identify the route that has: ! ! a) the highest degree of preference of any route to the same set ! of destinations, or ! ! b) is the only route to that destination, or ! ! c) is selected as a result of the Phase 2 tie breaking rules ! specified in 9.1.2.1. ! The local speaker SHALL then install that route in the Loc-RIB, replacing any route to the same destination that is currently being --- 2357,2416 ---- the local BGP speaker doesn't have a route in its Loc-RIB, the BGP route SHOULD be excluded from the Phase 2 decision function. ! It is critical that routers within an AS do not make conflicting ! decisions regarding route selection that would cause forwarding ! loops to occur (routers pointing traffic as each other or in a ! cycle). BGP speakers will consider the following attributes in ! determining preference and will consider no others. ! ! 1. NEXT_HOP. The next hop must be reachable, or if NEXT_HOP is ! not provided, the advertising router must be reachable) ! ! 1. LOCAL_PREF. ! ! 2. MULTI_EXIT_DISC. This comparison is applicable only when ! comparing MULTI_EXIT_DISC received from the same ! neighboring AS, including those received from the same ! neighboring AS and passed via IBGP. ! ! 3. Internal routing protocol cost. Lower costs are preferred. ! Select the route that has the lowest cost (interior ! distance) to the entity depicted by the NEXT_HOP attribute ! of the route. ! ! 4. Advertising router BGP Identifier. If at least one of the ! candidate routes was advertised by the BGP speaker in a ! neighboring autonomous system, select the route that was ! advertised by the BGP speaker in a neighboring autonomous ! system whose BGP Identifier has the lowest value among all ! other BGP speakers in neighboring autonomous systems. ! Otherwise, select the route that was advertised by the BGP ! speaker whose BGP Identifier has the lowest value. ! ! The MULTI_EXIT_DISC may be dropped when passing a route via IBGP. ! To prevent routing loops a route with a MULTI_EXIT_DISC (if the ! routes and received from the same neighboring AS and therefore the ! comparison is applicable) is preferred over one without. ! ! The outcome of a comparison must be independent of the order in ! which routes are placed in the Adj-Rib-In and Local-Rib. Due to ! difference in the backlog of propogated routes among IBGP peers, the ! same set of routes may arrive in different orders on differnt ! routers. If routes are compared in arbitrary order, under certain ! conditions routing loops can occur. This is a consequence of the ! use of MULTI_EXIT_DISC in comparing routes received from the same ! neighboring AS but not considering MULTI_EXIT_DISC when comparing ! routes received from differing neighboring AS. ! ! The comparison algorithm must insure a deterministic decision ! outcome. To accomplish this, routes are compared in a constrained ! order. First all routes are checked for feasibility, insuring that ! the NEXT_HOP is reachable. All routes from the same neighboring AS ! are first compared using the criteria above, LOCAL_PREF, ! MULTI_EXIT_DISC, internal routing protocol cost, and Advertising ! router IP address. Then the best route selected from each ! neighboring AS are compared using the criteria, LOCAL_PREF, internal ! routing protocol cost, and Advertising router BGP Identifier. The local speaker SHALL then install that route in the Loc-RIB, replacing any route to the same destination that is currently being *************** *** 2280,2325 **** INTERNET DRAFT August 1996 ! RIBs-In. ! ! ! 9.1.2.1 Breaking Ties (Phase 2) ! ! ! In its Adj-RIBs-In a BGP speaker may have several routes to the same ! destination that have the same degree of preference. The local ! speaker can select only one of these routes for inclusion in the ! associated Loc-RIB. The local speaker considers all equally ! preferable routes, both those received from BGP speakers located in ! neighboring autonomous systems, and those received from other BGP ! speakers located in the local speaker's autonomous system. ! ! The following tie-breaking procedure assumes that for each candidate ! route all the BGP speakers within an autonomous system can ascertain ! the cost of a path (interior distance) to the address depicted by the ! NEXT_HOP attribute of the route. Ties shall be broken according to ! the following algorithm: ! ! a) If the local system is configured to take into account ! MULTI_EXIT_DISC, and the candidate routes differ in their ! MULTI_EXIT_DISC attribute, select the route that has the lowest ! value of the MULTI_EXIT_DISC attribute. A route with ! MULTI_EXIT_DISC shall be preferred to a route without ! MULTI_EXIT_DIST. ! ! b) Otherwise, select the route that has the lowest cost (interior ! distance) to the entity depicted by the NEXT_HOP attribute of the ! route. If there are several routes with the same cost, then the ! tie-breaking shall be broken as follows: ! ! - if at least one of the candidate routes was advertised by the ! BGP speaker in a neighboring autonomous system, select the ! route that was advertised by the BGP speaker in a neighboring ! autonomous system whose BGP Identifier has the lowest value ! among all other BGP speakers in neighboring autonomous systems; ! ! - otherwise, select the route that was advertised by the BGP ! speaker whose BGP Identifier has the lowest value. 9.1.3 Phase 3: Route Dissemination --- 2437,2443 ---- INTERNET DRAFT August 1996 ! RIB-In. 9.1.3 Phase 3: Route Dissemination *************** *** 2425,2451 **** the less specific route. If a BGP speaker receives overlapping routes, the Decision Process ! shall take into account the semantics of the overlapping routes. In ! particular, if a BGP speaker accepts the less specific route while ! rejecting the more specific route from the same peer, then the ! destinations represented by the overlap may not forward along the ASs ! listed in the AS_PATH attribute of that route. Therefore, a BGP ! speaker has the following choices: ! ! a) Install both the less and the more specific routes ! ! b) Install the more specific route only ! ! c) Install the non-overlapping part of the less specific ! route only (that implies de-aggregation) ! ! d) Aggregate the two routes and install the aggregated route ! ! e) Install the less specific route only ! ! f) Install neither route ! If a BGP speaker chooses e), then it should add ATOMIC_AGGREGATE attribute to the route. A route that carries ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the NLRI of this route --- 2543,2554 ---- the less specific route. If a BGP speaker receives overlapping routes, the Decision Process ! shall consider both routes based on configured acceptance policy. ! If both are accepted the Decision Process will install both the ! less and the more specific routes or aggregate the two routes and ! install the aggregated route. ! If a BGP speaker chooses to aggregate, then it should add ATOMIC_AGGREGATE attribute to the route. A route that carries ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the NLRI of this route *************** *** 2462,2470 **** can not be made more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed ! in the AS_PATH attribute of the route. If a BGP speaker chooses a), ! it must not advertise the more general route without the more ! specific route. 9.2 Update-Send Process --- 2565,2573 ---- can not be made more specific. Forwarding along such a route does not guarantee that IP packets will actually traverse only ASs listed ! in the AS_PATH attribute of the route. If a BGP speaker chooses to ! install both routes it must not advertise the more general route ! without the more specific route. 9.2 Update-Send Process *************** *** 2500,2531 **** When a BGP speaker receives a new route from a BGP speaker in a neighboring autonomous system, it shall advertise that route to all other BGP speakers in its autonomous system by means of an UPDATE ! message if any of the following conditions occur: ! ! 1) the degree of preference assigned to the newly received route ! by the local BGP speaker is higher than the degree of preference ! that the local speaker has assigned to other routes that have been ! received from BGP speakers in neighboring autonomous systems, or ! ! 2) there are no other routes that have been received from BGP ! ! ! ! Expiration Date February 1996 [Page 42] ! ! ! ! ! ! INTERNET DRAFT August 1996 ! ! ! speakers in neighboring autonomous systems, or ! ! 3) the newly received route is selected as a result of breaking a ! tie between several routes which have the highest degree of ! preference, and the same destination (the tie-breaking procedure ! is specified in 9.2.1.1). When a BGP speaker receives an UPDATE message with a non-empty WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all --- 2603,2610 ---- When a BGP speaker receives a new route from a BGP speaker in a neighboring autonomous system, it shall advertise that route to all other BGP speakers in its autonomous system by means of an UPDATE ! message if this route has become the best route installed in the ! Local-Rib according to the route selection rules in 9.1.2. When a BGP speaker receives an UPDATE message with a non-empty WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all *************** *** 2554,2598 **** All feasible routes which are advertised shall be placed in the appropriate Adj-RIBs-Out, and all unfeasible routes which are advertised shall be removed from the Adj-RIBs-Out. - - - 9.2.1.1 Breaking Ties (Internal Updates) - - - If a local BGP speaker has connections to several BGP speakers in - neighboring autonomous systems, there will be multiple Adj-RIBs-In - associated with these peers. These Adj-RIBs-In might contain several - equally preferable routes to the same destination, all of which were - advertised by BGP speakers located in neighboring autonomous systems. - The local BGP speaker shall select one of these routes according to - the following rules: - - a) If the candidate routes differ only in their NEXT_HOP and - - - - Expiration Date February 1996 [Page 43] - - - - - - INTERNET DRAFT August 1996 - - - MULTI_EXIT_DISC attributes, and the local system is configured to - take into account the MULTI_EXIT_DISC attribute, select the route - that has the lowest value of the MULTI_EXIT_DISC attribute. A - route with the MULTI_EXIT_DISC attribute shall be preferred to a - route without the MULTI_EXIT_DISC attribute. - - b) If the local system can ascertain the cost of a path to the - entity depicted by the NEXT_HOP attribute of the candidate route, - select the route with the lowest cost. - - c) In all other cases, select the route that was advertised by the - BGP speaker whose BGP Identifier has the lowest value. - 9.2.2 External Updates --- 2633,2638 ---- - - - - - - - - - - - - - - - - - From owner-idr@merit.edu Wed May 6 22:10:09 1998 Delivery-Date: Wed, 06 May 1998 22:10:09 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA27538 for ; Wed, 6 May 1998 22:10:08 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA15635 for ; Wed, 6 May 1998 22:12:33 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA29820 for idr-outgoing; Wed, 6 May 1998 21:36:36 -0400 (EDT) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA29816 for ; Wed, 6 May 1998 21:36:29 -0400 (EDT) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id VAA02525; Wed, 6 May 1998 21:36:28 -0400 (EDT) Message-Id: <199805070136.VAA02525@brookfield.ans.net> To: idr@merit.edu cc: curtis@ans.net Reply-To: curtis@ans.net Subject: BGP Route Flap Damping - reader comments Date: Wed, 06 May 1998 21:36:28 -0400 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk Rob, John, Thanks for the comments. Curtis ------- Forwarded Message Return-Path: curtis@brookfield.ans.net Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id RAA29139; Wed, 6 May 1998 17:47:36 -0400 (EDT) Message-Id: <199805062147.RAA29139@brookfield.ans.net> To: Rob Coltun cc: curtis@brookfield.ans.net, John Scudder Reply-To: curtis@ans.net Subject: Re: more comments on dampening... In-reply-to: Your message of "Fri, 03 Apr 1998 09:39:31 EST." <3.0.32.19980403093927.00a6d224@pophost1.fore.com> Date: Wed, 06 May 1998 17:47:35 -0400 From: Curtis Villamizar In message <3.0.32.19980403093927.00a6d224@pophost1.fore.com>, Rob Coltun write s: > ...from sanjay > > In addition to the last equation in section 4.6 pointed out here > (also had it marked as an error) : John point this section out. According to John the text was OK but the equations were wrong. I'll address this below. Keep in mind that this section was written after the first two implementations so it is not surprising that the 3rd and 4th stumbled on the error. > There is another one that I think might be an error . > Last line on page 8 (section 4.3) : > From either Tmaxok or Tmax-ng a ratio of cutoff to a celing > can be determined. > > I think it should be T-hold rather than T-max. And penalty ceiling > should be related to penalty-reuse rather than penalty-cutoff. I changed that paragraph to read: From the maximum hold time value (\mathortext{$T_{hold}$}{T-hold}), a ratio of the cutoff to a ceiling can be determined. An integer value for the ceiling can then be chosen such that overflow will not be a problem and all other values can be scaled accordingly. If both cutoffs are specified or if multiple parameter sets are used the highest ceiling will be used. Before this the text was saying hold time but had T-max in parens. Good catch. This error was probably there from the start. > I think the equation to determine ceiling should be : > penalty-ceiling = (penalty-reuse) * (exp((T-hold/T) * log 2)) > > (where log is natural-log). > T-hold, T and penalty-reuse are all configurable. > penalty-celing can therefore be determined from the above > equation. Basically this means that penlaty is being limited > to penalty-ceiling so that it can decay to re-use value > in some multiple of half life time. I never actually gave an equation to compute the ceiling. What you have here is not quite right though (just variable name confusion again). You can get the ceiling by going backwards from the reuse value (\epsilon_{reuse}), the max hold time (T_{hold}), and the decay rate (\lambda). In text it is: ceiling = reuse * 2 ^ (T-hold/decay-rate) ceiling = reuse * log(2) * exp(T-hold/decay-rate) In math mode this is: \epsilon_{ceiling} = \epsilon_{cut} * \log 2 e ^ \frac{T_{hold}}{\lambda} Doesn't the latex source clear things up nicely. :-) > Another thing is that the spec talks about putting routes on > the re-use list based on how much time it will take for the > route's current penalty to decay to penalty-reuse. > However when a route becomes re-usable we still have to track > it's penalty till it reaches a value at which we can forget it > i.e. stop tracking it altogether. The route should be put onto > another timer-list (say penalty-remove-list) based on the time > it will take the penalty to decay enough so that we can stop > tracking it. Spec does not talk abt this. Might be more of an > implementation issue, but since they talk about re-use lists > (which is also implementation issue) they can probably indicate > this too. I thought I had covered that but apparently not. It is necessary to clean up unused storage. A second set of reuse arrays, maybe we should call them recycle arrays, could be described. Sometimes I think it would have been easier to just provide code. I added the following paragraph: A separate reuse list can be used to hold unreachable routes for the purpose of later recovering storage if they remain unreachable too long. This might be more accurately described as a recycling list. The advantage this would provide is making free data structures available as soon as possible. Alternately, the data structures can simply be placed on a queue and the storage recovered when the route hits the front of the queue and if storage is needed. The latter is less optimal but simple. That ought to cover recycling adequately. At least I hope so because adding a recycling array where the math is identical to the reuse array would be a substantial pain and probably would not add to clarity. Back to section 4.6. The best thing at this point is to try out the math on an example, see if it works, fix if necessary, and check the text to see if it matches. The first equation is: max-ratio = min(ceiling/reuse, exp((1 / (half-life/reuse-array-time)) * log(1/2))) Looks like this should be log(2). If: ceiling = 5 reuse = 1.5 half-life = 30*60 reuse-array-time = 300*60 then: max-ratio = min(5/1.5, exp((300/30) * 0.69315)) max-ratio = min(3.3333, 1024) If reuse-array-time is small, for example 45*60: max-ratio = min(3.3333, 2.8284) This seems to work. Next equation is: scale-factor = (max-ratio - 1) / reuse-array-size If reuse-array-size = 32 (and we're back to 300): scale-factor = (3.33 - 1) / 32 = 0.072813 Next and final is: reuse-array[j] = integer(log(1 / (1 + ((j+1) * (max-ratio-1)))) / reuse-time-granularity) Lets use reuse-time-granularity of 5. This is all wrong. We want the property: reuse-array[j] = delay-until-reuse / reuse-time-granularity j = ((X / reuse) - 1) / scale-factor X = reuse * (1 + (j * scale-factor)) D[1] = exp((1 / (decay-rate/delta-t)) * log (1/2)) D[i] = D[1] ** i D[i] = exp(i * ((1 / (decay-rate/delta-t)) * log (1/2))) i = T/delta-t X = 1/D[i] D[i] = 1/X reuse-array[j] = T / reuse-time-granularity Need to solve for T in: 1/X = exp((T/delta-t) * ((1 / (decay-rate/delta-t)) * log (1/2))) T = decay-rate * log(1/X) / log(1/2) T = decay-rate * log(1/(reuse * (1 + (j * scale-factor)))) / log(1/2) Try it: reuse-array[j] = (30*60)/(5*60)*log(1/(1.5*(1+(j*0.072813))))/log(1/2) j reuse-array[j] X 0 3.5 3 1.5 1 4.1 4 1.6 2 4.7 4 1.7 3 5.2 5 1.8 4 5.7 5 1.9 5 6.2 6 2.0 6 6.6 6 2.2 7 7.1 7 2.3 8 7.5 7 2.4 9 7.8 7 2.5 10 8.2 8 2.6 12 8.9 8 2.8 14 9.6 9 3.0 16 10.2 10 3.2 20 11.3 11 3.7 24 12.3 12 4.1 28 13.1 13 4.6 32 13.9 13 5.0 This tells us that the array need only be 16 long for a half life of 30 minutes and evaluation of the reuse array every 5 minutes. When using the array take X, or epsilon elsewhere, multiply by 1/scale-factor to get J, truncate, look up in reuse-array, get an integer index K, put the structure in the Kth list. Now to get that in the draft. Curtis ------- End of Forwarded Message From owner-idr@merit.edu Wed May 6 22:12:16 1998 Delivery-Date: Wed, 06 May 1998 22:12:16 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA27580 for ; Wed, 6 May 1998 22:12:16 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA15647 for ; Wed, 6 May 1998 22:14:41 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA29837 for idr-outgoing; Wed, 6 May 1998 21:38:22 -0400 (EDT) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA29833 for ; Wed, 6 May 1998 21:38:17 -0400 (EDT) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id VAA02542; Wed, 6 May 1998 21:38:16 -0400 (EDT) Message-Id: <199805070138.VAA02542@brookfield.ans.net> To: idr@merit.edu cc: curtis@ans.net Reply-To: curtis@ans.net Subject: Route Flap Damping - more reader comments Date: Wed, 06 May 1998 21:38:15 -0400 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk Jayesh, Thanks for the comments. Curtis ------- Forwarded Message Return-Path: curtis@brookfield.ans.net Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id SAA29231 for ; Wed, 6 May 1998 18:19:08 -0400 (EDT) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id SAA07700 for ; Wed, 6 May 1998 18:19:06 -0400 (EDT) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id SAA29227; Wed, 6 May 1998 18:19:03 -0400 (EDT) Message-Id: <199805062219.SAA29227@brookfield.ans.net> To: jbhatt@BayNetworks.COM (Jayesh Bhatt) cc: curtis@ans.net Reply-To: curtis@ans.net Subject: Re: Route Flap Damping question ... In-reply-to: Your message of "Wed, 08 Apr 1998 19:57:01 EDT." <199804082357.TAA07617@pobox.engeast.BayNetworks.COM> Date: Wed, 06 May 1998 18:19:03 -0400 From: Curtis Villamizar In message <199804082357.TAA07617@pobox.engeast.BayNetworks.COM>, Jayesh Bhatt writes: > Hi, > > I was going through the Route Flap Damping draft: > draft-ietf-idr-route-damp-02.txt > and was wondering if I could ask you some questions > to understand it better since I think it's a really clever > way to manage the penalties without having > to walk all the BGP routes and adjusting penalties. Sorry for the delay in answering this. I've been busy with other science projects. :-) > I was trying to understand some of the equations to > calculate decay-arrays and reuse-lists. I understand > the calculations in concept [if that's possible :-)] > but I had some questions on some of the equations > themselves. We've just found out a few are wrong. Lets see if you've hit on yet another error or just lack of clarity. > I - When you say "log" you mean the natural log correct?? log is natural log and exp is e raised to some power. > II - On page 18 of the draft, I understand that the decay-factor per > decay timer "delta-t" is > > decay[1] = exp( (1/ (decay-rate/delat-t)) * log(1/2) ) > > which reduces to: [e**(ln(a)) = a where ln is log base e] > > (1/2)**( 1/(half-life/delta-t) ) > > OR > > (1/2)**( delta-t/half-life) > > where ** means "to the power of" > > Is my understanding correct?? Yes. This was decay[half-life/delat-t] = 1/2, which is the definition of half life. > III - On page 18 and 19, section 4.6 - "Building the Reuse Index Array": > > max-ratio = min( ceiling/reuse, > exp( (1/(half-life/reuse-array-time))*log(1/2) ) > ) > > ceiling = the max-value the figure-of-merit can reach > > reuse = the value of figure-of-merit below which the route will be > reuseable. > > half-life = time over which the figure-of-merit reduces to half. > > reuse-array-time = total time that reuse lists cover. > i.e. if we have 1024 reuse lists and > reuse-time-granularity is 5 seconds, reuse-array-time > > = 1024*5 = 5120. > > Is this correct??? > Or is > reuse-array-time = the reuse-time-granularity = the time interval after > which the reuse list will be looked up again to move > reuseable routes into reuseable lists. How observant. Rob Coltun (or actually Sanjay) already pointed this out. I can see you are also going through the draft carefully. The short answer is the log(1/2) was supposed to be a log(2). > IV > > So the max-ratio is minumum of ceiling/reuse and > > (1/2)**( 1/(half-life/reuse-array-time) ) > OR > (1/2)**( reuse-array-time/half-life) ) > > If I use the reuse-array-time to be the total time (e.g. 1024 above) > the max-ratio approaches 0 very quickly. > > If I use the reuse-array-time to be the time a single reuse list covers > (i.e. 5 seconds above), the max-ratio remains less than 1 approaching > 1 very slowly. This is not right. See 4.8.6 "Inserting into the Reuse Timer List" and 4.8.7 "Handling Reuse Timer Events". This describes how the reuse data structures are used. These are not decay arrays. > V Further in section 4.6 I am a little confused by the terminology: > > reuse-array-scale-factor, or simply the scale-factor is used to > determine which reuse-list to insert a route into correct? > > This is either 0 or less than 1 from above if > > scale factor is = (max-ratio-1)/reuse-array-size > > Where did I go wrong?? max-ratio is usually a small number. Take 3 for example. If the array has 32 elements, then scale-factor is 1/16. See the message to Rob that I will shortly forward for some clarification on this. I'll also try to make the I-D a bit more clear. Rob got it and John Scudder got it but it is true that the draft could be better here. > VI Is reuse-array-size the number of entries per reuse list and is > reuse-index-array = the array which indexes into the reuse lists based > on current figure-of-merit? The second equation in section 4.6 should use reuse-index-array-size rather than reuse-array-size. You multiply the figure-of-merit by 1/scale-factor (it might have helped to invert the definition). You truncate and look up in reuse-index-array and get an integer. You use that integer to pick a reuse-list. reuse-index-array-size is the size of the reuse-index-array. The third equation is 4.6 is completely wrong. I guess this just proves I can't do algebra reliably. > Thanks and sorry for the loooong mail. Not so long considering that it seems you are going through this is sufficient detail to implement it. If so, that would make yours implementation #5 AFAIK. (Cisco, ISI, IENG, Fore, Bay). > J > > -- > ------------------------------------------------- > Jayesh Bhatt > 600 Technology Park > Mail Stop: 60-304 > Billerica, MA 01821 > Bay Networks FAX (508) 670-8760 > jbhatt@baynetworks.com Direct (508) 916-3566 > ------------------------------------------------- Again. Sorry it took so long to respond. Curtis ------- End of Forwarded Message From owner-idr@merit.edu Wed May 6 22:18:38 1998 Delivery-Date: Wed, 06 May 1998 22:18:38 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA27668 for ; Wed, 6 May 1998 22:18:38 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA15657 for ; Wed, 6 May 1998 22:21:03 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA29984 for idr-outgoing; Wed, 6 May 1998 21:49:40 -0400 (EDT) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA29977 for ; Wed, 6 May 1998 21:49:34 -0400 (EDT) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.5/8.8.5) with ESMTP id VAA02597; Wed, 6 May 1998 21:49:33 -0400 (EDT) Message-Id: <199805070149.VAA02597@brookfield.ans.net> To: idr@merit.edu cc: curtis@ans.net Reply-To: curtis@ans.net Subject: BGP Route Flap Damping -03-preview Date: Wed, 06 May 1998 21:49:33 -0400 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk The web pages were updated at: http://engr.ans.net/route-damp/ The BGP Route Flap Damping is now available in -03-preview flavor. The following summarizes the changes (from the web page): The current (-03-preview) draft in this directory is a preview of the draft about to be resubmitted to the Internet Draft editors. This preview corrects a few errors noted in the prior version in the additional implementation details added after the first two implementations were completed. The errors were noted by individuals during the process of writing what will be the third, fourth, and fifth independent implementations of the draft. And the following was added to the acknowledgements. Thanks to Rob Coltun (Fore Systems), John Scudder (IENG) and Jayesh Bhatt (Bay Networks) for pointing out errors in the math uncovered during coding of more recent implementations. These errors appeared in the details of the implementation suggestion sections written after the first two implementations were completed. If you **really** want to know what changed and just **love** reading unified diffs of latex source, I've included diffs below. :-) Curtis btw- If there are no further comments I'll drop the -preview and send this off to the internet-drafts editor (IETF secretariate). The WG chairs then have the task of deciding how to proceed given that this has already reached the IESG. Start over from the WG last call? Index: route-damp.rfc =================================================================== RCS file: /usr/local/CVS-routing-dev/doc/ietf/route-dampen/route-damp.rfc,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- route-damp.rfc 1998/02/13 19:51:50 1.7 +++ route-damp.rfc 1998/05/07 01:17:24 1.8 @@ -9,7 +9,7 @@ \author{Ramesh Govindan} \address{ISI} \footer{Villamizar, Chandra, Govindan} -\filename{draft-ietf-idr-route-damp-02} +\filename{draft-ietf-idr-route-damp-03-preview} \begin{document} \begin{alltt} \bibliographystyle{plain} @@ -493,9 +493,10 @@ reuse index array is needed for each decay rate in use. The reuse index array is used to estimate which reuse list to place a route when it is suppressed. Proper placement avoids the need to periodically -evaluate decay to determine if a route can be reused. Using the reuse -index array avoids the need to compute a logarithm to determine -placement. One additional system wide parameter can be introduced. +evaluate decay to determine if a route can be reused or when storage +can be recovered. Using the reuse index array avoids the need to +compute a logarithm to determine placement. One additional system +wide parameter can be introduced. \begin{description} \resync @@ -542,12 +543,12 @@ \label{flap-rates} \end{figure} -From either maximum hold time value (\mathortext{$ Tmax _ {ok} $ or $ -Tmax _ {ng} $}{Tmax-ok or Tmax-ng}), a ratio of the cutoff to a -ceiling can be determined. An integer value for the ceiling can then -be chosen such that overflow will not be a problem and all other -values can be scaled accordingly. If both cutoffs are specified or if -multiple parameter sets are used the highest ceiling will be used. +From the maximum hold time value (\mathortext{$T_{hold}$}{T-hold}), +a ratio of the cutoff to a ceiling can be determined. An integer +value for the ceiling can then be chosen such that overflow will not +be a problem and all other values can be scaled accordingly. If both +cutoffs are specified or if multiple parameter sets are used the +highest ceiling will be used. \begin{figure} \unitlength=0.8in @@ -609,6 +610,15 @@ used to arrange suppressed routes according to the time remaining until they can be reused. +A separate reuse list can be used to hold unreachable routes for the +purpose of later recovering storage if they remain unreachable too +long. This might be more accurately described as a recycling list. +The advantage this would provide is making free data structures +available as soon as possible. Alternately, the data structures can +simply be placed on a queue and the storage recovered when the route +hits the front of the queue and if storage is needed. The latter is +less optimal but simple. + If multiple sets of configuration parameters are allowed per route, there is a need for some means of associating more than one figure of merit and set of parameters with each route. Building a linked list @@ -668,13 +678,13 @@ \mathortext{( $ Size _ D $ )}{(decay-array-size)} \item decay array - \mathortext{( $ D [ \ ] $ )}{(decay)} + \mathortext{( $ D [ \ ] $ )}{(decay[])} \item reuse index array size \mathortext{( $ Size _ {R_{index}} $ )}{(reuse-index-array-size)} \item reuse index array - \mathortext{( $ R _ {index} [ \ ] $ )}{(reuse-index-array)} + \mathortext{( $ R _ {index} [ \ ] $ )}{(reuse-index-array[])} \end{itemize} For each decay rate specified, an array will be used to store the @@ -792,6 +802,22 @@ number of values that will be used repeatedly and retain these to speed later computations that will be required frequently. +Scaling is usually dependent on the highest value that +\mathortext{$\epsilon$}{figure-of-merit} can attain, referred to here +as the ceiling\mathortext{ ($\epsilon_{ceiling}$)}{}. The real number +value of the ceiling will typically be determined by the following +equation. + +\mathortext{% + \begin{displaymath} + \epsilon_{ceiling} = \epsilon_{cut} e ^ {\frac{T_{hold}}{\lambda} \log 2} + \end{displaymath} +}{\begin{quotation} + \resync + ceiling = reuse * (exp(T-hold/decay-rate) * log(2)) +\end{quotation} +} + The methods of scaled integer arithmetic are not described in detail here. The methods of determining the real values are given. Translation into scaled integer values and the details of scaled @@ -808,7 +834,7 @@ the scaled integers to be multiplied by the scaled decay value and then shifted down. Implementations may prefer to use real numbers or may use any integer scaling deemed appropriate for their - architecture. + architecture. \item{penalty value and thresholds (as proportional scaled integers)} \par The figure of merit penalty for one route withdrawal and the cutoff values must be scaled according to the above scaling factor. @@ -898,13 +924,13 @@ ratio _ {max} = min( \frac{\epsilon _ {ceiling}}{ \epsilon _ {reuse} } , e ^ { \frac{1} { \left( \frac{\lambda}{T_{reuse}} \right) } } - \log { \frac{1}{2} } ) + \log {2} ) \end{displaymath} }{% \begin{quotation} \resync max-ratio = min(ceiling/reuse, - exp((1 / (half-life/reuse-array-time)) * log(1/2))) + exp((1 / (half-life/reuse-array-time)) * log(2))) \end{quotation} } \item{reuse array scale factor @@ -915,16 +941,16 @@ used. \mathortext{% \begin{displaymath} - scale _ {reuse} = \frac{{ ratio _ {max} } - 1 }{ Size _ R } + scale _ {reuse} = \frac{ Size _ {R_{index}} }{{ ratio _ {max} } - 1 } \end{displaymath} }{% \begin{quotation} \resync - scale-factor = (max-ratio - 1) / reuse-array-size + scale-factor = reuse-index-array-size / (max-ratio - 1) \end{quotation} } \item{reuse index array - \mathortext{( $ R_{index} [] $ )}{(reuse)} + \mathortext{( $ R_{index} [\ ] $ )}{(reuse-index-array[])} } \par Each reuse index array entry should contain an index into the reuse list array pointing to one of the list heads. This index should @@ -934,15 +960,15 @@ the the reuse array entry. \mathortext{% \begin{displaymath} - R_{index} [ i ] = integer \left( \log - \frac{ \frac{1}{ { 1 + ( ( j + 1 ) ( { ratio_{max} } - 1 ) ) } } - }{ \Delta { t _ {reuse} } } \right) + R_{index} [ j ] = integer \left( \frac{\lambda}{\Delta{t_{reuse}}} + \log {\left( frac{1}{\epsilon_{reuse}(1+\frac{j}{scale_{reuse}})} \right)} + \log {\frac{1}{2}} \right) \end{displaymath} }{% \begin{quotation} \resync - reuse-array[j] = integer(log(1 / (1 + ((j+1) * (max-ratio-1)))) - / reuse-time-granularity) + reuse-index-array[j] = integer((decay-rate / reuse-time-granularity) + * log(1/(reuse * (1 + (j / scale-factor)))) / log(1/2)) \end{quotation} } \end{description} @@ -950,10 +976,14 @@ To determine which reuse queue to place a route which is being suppressed, the following procedure is used. Divide the current figure of merit by the cutoff. Subtract one. Multiply by the scale -factor. This is the array index. If it is off the end of the array -use the last queue otherwise look in the array and pick the number of -the queue from the array at that index. This is quite fast and -well worth the setup and storage required. +factor. This is the index into the reuse index array \mathortext{( $ +R_{index} [\ ] $ )}{(reuse-index-array[])}. The value fetched from +the reuse index array \mathortext{( $R_{index} [\ ] $ +)}{(reuse-index-array[])} is an index into the array of reuse lists +\mathortext{( $R[\ ]$ )}{(reuse-array[])}. If this index is off the +end of the array use the last queue otherwise look in the array and +pick the number of the queue from the array at that index. This is +quite fast and well worth the setup and storage required. \subsection{A Sample Configuration} @@ -1556,6 +1586,12 @@ comments and implementation feedback were shared by many individuals on the IETF IDR WG and the RIPE Routing Work Group and in NANOG and IEPG. + +Thanks also to Rob Coltun (Fore Systems), John Scudder (IENG) and +Jayesh Bhatt (Bay Networks) for pointing out errors in the math +uncovered during coding of more recent implementations. These errors +appeared in the details of the implementation suggestion sections +written after the first two implementations were completed. % References From owner-idr@merit.edu Thu May 7 09:26:46 1998 Delivery-Date: Thu, 07 May 1998 09:26:46 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA17079 for ; Thu, 7 May 1998 09:26:45 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA16792 for ; Thu, 7 May 1998 09:29:11 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id JAA09413 for idr-outgoing; Thu, 7 May 1998 09:02:42 -0400 (EDT) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by merit.edu (8.8.7/8.8.5) with SMTP id JAA09406 for ; Thu, 7 May 1998 09:02:38 -0400 (EDT) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id GAA08771; Thu, 7 May 1998 06:01:32 -0700 Message-Id: <199805071301.GAA08771@puli.cisco.com> To: curtis@ans.net cc: idr@merit.edu Subject: Re: BGP Route Flap Damping -03-preview In-reply-to: Your message of "Wed, 06 May 98 21:49:33 EDT." <199805070149.VAA02597@brookfield.ans.net> Date: Thu, 07 May 98 06:01:32 PDT From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Curtis, > btw- If there are no further comments I'll drop the -preview and send > this off to the internet-drafts editor (IETF secretariate). The WG Yes, please. > chairs then have the task of deciding how to proceed given that this > has already reached the IESG. Start over from the WG last call? Yes, as soon as the new internet draft will become available. Yakov. From owner-idr@merit.edu Mon May 11 23:21:17 1998 Delivery-Date: Mon, 11 May 1998 23:21:22 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA06789 for ; Mon, 11 May 1998 23:21:16 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA06002 for ; Mon, 11 May 1998 23:23:42 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA06184 for idr-outgoing; Mon, 11 May 1998 22:53:53 -0400 (EDT) Received: from dangle.wins.hrl.com ([206.17.46.85]) by merit.edu (8.8.7/8.8.5) with SMTP id WAA06180 for ; Mon, 11 May 1998 22:53:47 -0400 (EDT) Received: from dhcp-46.wins.hrl.com by dangle.wins.hrl.com (5.65v3.2/1.1.10.5/24Apr98-0905PM) id AA20392; Mon, 11 May 1998 19:51:40 -0700 Message-Id: <3557BA08.FE75B419@isl.hrl.hac.com> Date: Tue, 12 May 1998 02:55:04 +0000 From: Bo Ryu Organization: Hughes Research Labs X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i586) Mime-Version: 1.0 To: TCP-over-Satellite , end2end-interest@isi.edu, int-serv@isi.edu, pint@lists.research.bell-labs.com, qosr@newbridge.com, idmr@cs.ucl.ac.uk, idr@merit.edu, udlr@sophia.inria.fr, ion@sunroof.eng.sun.com, lsma@gmu.edu, ietf-asid@umich.edu, http-wg@cuckoo.hpl.hp.com, mboned@network-services.uoregon.edu, roamops@tdmx.rutgers.edu, ietf-lsd@listserv.umu.se Subject: First CFP for WOSBIS'98 (Mobicom'98 workshop) Content-Type: multipart/mixed; boundary="------------B691B2BF999D8B6F84EBFEBA" Sender: owner-idr@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------B691B2BF999D8B6F84EBFEBA Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Enclosed please find the first CFP for the Third Workshop on Satellite-Based Information Society (WOSBIS'98). Please accept my appology if you receive duplicates. Regards, -Bo -- ----------------------------------- Bo Ryu E-mail:ryu@hrl.com HRL, LLC. (formerly Hughes Research Labs) 3011 Malibu Can. Rd. Tel: +1 (310) 317-5487, Fax: +1 (310) 317-5695 Malibu, CA 90265 URL: http://www.wins.hrl.com/people/ryu --------------B691B2BF999D8B6F84EBFEBA Content-Type: text/plain; charset=iso-2022-kr; name="WOSBIS98-CFP.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="WOSBIS98-CFP.txt" CALL FOR PAPERS 3rd Int'l Workshop on Satellite-based Information Services (WOSBIS'98) October 30, 1998 Dallas , Texas In conjunction with ACM MobiCom'98 Sponsored by ACM Sigmobile and technical co-sponsored by IEEE Scope: We are witnessing that satellites are becoming an integral part of our daily lives in this information-rich and global society. This is evidenced by the systems currently in operation (e.g., DirecTV(TM), DirecPC, GPS, and Iridium) as well as those to offer broadband, interactive, and multimedia Internet services around the next millennium (SpaceWay, Teledesic, Astrolink, Celestri, etc.). In conjunction with MOBICOM'98, this workshop provides a forum for exploratory research contributions on lifting the technological barriers to achieve innovative satellite applications and services, and seamless integration with terrestrial networks. The services are characterized by direct or global broadcast capabilities of LEO/MEO/GEO satellites, high and possibly asymmetric bandwidth, and unconventional network routing/switching. Applications of such services include Internet access, telemedicine, public information services, distance learning, entertainment, digital battlefield, emergency and disaster response, and many more. Topics: Papers are solicited in all research and applied areas related to satellite-based information services (including, but not limited to): * Innovative applications using satellite services * System architectures for hybrid satellite systems (LEO and GEO or MEO and GEO) * Distributed computing using satellite communications * Protocol and service interoperability with terrestrial networks * Software techniques for reducing latency in satellite applications * ATM over satellites * Quality of Service interoperability with terrestrial networks * Medium Access Control protocols for LEO/MEO/GEO or hybrid networks. * Routing protocols in satellite networks * TCP/IP for satellite communications * Internet applications, WWW access and cache through satellites * Direct broadcast and multicast applications * Reliability and scalability in satellite applications * Software for satellite switch control * Mobile computing and location tracking in satellite applications * Inter-satellite communication and network management * Middleware for satellite-based information services development The setting of the workshop will be informal, and will encourage discussion and interaction. We solicit the submission of research papers, position papers, experience papers, and panel proposals. SUBMISSIONS We invite papers for presentation and discussion at the workshop. Send a postscript copy of the paper by email to: ryu@hrl.com. The page limit on all submissions is 5-10 pages, double spaced, 10 pt minimum (approximately 1500-2500 words). If electronic submission is not possible, send three (3) hard copies to: Bo Ryu HRL Laboratories, MA/254/RL96, 3011 Malibu Canyon Road Malibu, CA 90265 PROCEEDINGS: An informal proceedings will be published and distributed at the workshop. The format will be similar to standard ACM proceedings: double column, single spaced and the page limit on each paper is 12. Papers with outstanding merit will be considered for publication in a special issue of ACM MONET. IMPORTANT DATES: * Papers Due: July 1st, 1998 * Acceptance Notification: Sep. 1st, 1998 * Camera ready: Sep. 30, 1998 * Workshop: Oct. 30, 1998 WEB SITE: http://www.wins.hrl.com/conferences/WOSBIS98/ GENERAL CO-CHAIRS: Son K. Dao, HRL Labs., USA Randy Katz, UC Berkeley, USA TECHNICAL PROGRAM CO-CHAIRS: Horst Clausen, U. of Salzburg, Austria Bo Ryu, HRL Labs., USA PUBLICITY: Yongguang Zhang, HRL Labs. TECHNICAL PROGRAM COMMITTEE: Mark Allman, NASA LeRC, USA Rafael Alonso, David Sarnoff Research Center, USA Imrich Chlamtac, U. Texas at Dallas, USA Walid Dabbous, INRIA, France Anthony Ephremides, U. of Maryland, USA Barry G. Evans, U. of Surrey, UK Mike Fitch, British Telecom, UK Raj Jain, Ohio State U., USA Hans Kruse, Ohis U., USA David Lee, Bell Labs, USA Mischa Schwartz, Columbia U., USA Csaba Szabo, Technical U. of Budapest, Hungary Bharghavan Vaduvur, UIUC, USA. Nitin Vaidya, Texas A&M U., USA Thomas VonDeak, NASA LeRC, USA Ouri Wolfson, U. of Illinois at Chicago, USA --------------B691B2BF999D8B6F84EBFEBA-- From owner-qosr@ca.newbridge.com Mon May 11 23:30:02 1998 Delivery-Date: Mon, 11 May 1998 23:30:02 -0400 Return-Path: owner-qosr@ca.newbridge.com Received: from ns.newbridge.com (ns.newbridge.com [192.75.23.67]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA06832 for ; Mon, 11 May 1998 23:30:01 -0400 (EDT) Received: (from smap@localhost) by ns.newbridge.com (8.8.8/8.6.12) id XAA04651; Mon, 11 May 1998 23:26:39 -0400 (EDT) Received: from kanata-gw1(192.75.23.72) by ns via smap (V1.3) id sma004559; Mon May 11 23:25:30 1998 Received: from kanmaster.ca.newbridge.com by kanata-gw1.ca.newbridge.com via smtpd (for ns.newbridge.com [192.75.23.67]) with SMTP; 12 May 1998 03:25:30 UT Received: from distmaster.ca.newbridge.com (distmaster.ca.newbridge.com [138.120.118.27]) by ca.newbridge.com. (8.8.6/8.8.6) with SMTP id XAA14165; Mon, 11 May 1998 23:24:29 -0400 (EDT) Received: by distmaster.ca.newbridge.com (SMI-8.6/SMI-SVR4) id WAA17718; Mon, 11 May 1998 22:54:49 -0400 Message-Id: <3557BA08.FE75B419@isl.hrl.hac.com> Date: Tue, 12 May 1998 02:55:04 +0000 From: Bo Ryu Organization: Hughes Research Labs X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i586) Mime-Version: 1.0 To: TCP-over-Satellite , end2end-interest@isi.edu, int-serv@isi.edu, pint@lists.research.bell-labs.com, qosr@ca.newbridge.com, idmr@cs.ucl.ac.uk, idr@merit.edu, udlr@sophia.inria.fr, ion@sunroof.eng.sun.com, lsma@gmu.edu, ietf-asid@umich.edu, http-wg@cuckoo.hpl.hp.com, mboned@network-services.uoregon.edu, roamops@tdmx.rutgers.edu, ietf-lsd@listserv.umu.se Subject: First CFP for WOSBIS'98 (Mobicom'98 workshop) Content-Type: multipart/mixed; boundary="------------B691B2BF999D8B6F84EBFEBA" Sender: owner-qosr@Newbridge.COM Precedence: bulk Reply-To: qosr@Newbridge.COM X-Info: [Un]Subscribe to qosr-request@newbridge.com This is a multi-part message in MIME format. --------------B691B2BF999D8B6F84EBFEBA Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Enclosed please find the first CFP for the Third Workshop on Satellite-Based Information Society (WOSBIS'98). Please accept my appology if you receive duplicates. Regards, -Bo -- ----------------------------------- Bo Ryu E-mail:ryu@hrl.com HRL, LLC. (formerly Hughes Research Labs) 3011 Malibu Can. Rd. Tel: +1 (310) 317-5487, Fax: +1 (310) 317-5695 Malibu, CA 90265 URL: http://www.wins.hrl.com/people/ryu --------------B691B2BF999D8B6F84EBFEBA Content-Type: text/plain; charset=iso-2022-kr; name="WOSBIS98-CFP.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="WOSBIS98-CFP.txt" CALL FOR PAPERS 3rd Int'l Workshop on Satellite-based Information Services (WOSBIS'98) October 30, 1998 Dallas , Texas In conjunction with ACM MobiCom'98 Sponsored by ACM Sigmobile and technical co-sponsored by IEEE Scope: We are witnessing that satellites are becoming an integral part of our daily lives in this information-rich and global society. This is evidenced by the systems currently in operation (e.g., DirecTV(TM), DirecPC, GPS, and Iridium) as well as those to offer broadband, interactive, and multimedia Internet services around the next millennium (SpaceWay, Teledesic, Astrolink, Celestri, etc.). In conjunction with MOBICOM'98, this workshop provides a forum for exploratory research contributions on lifting the technological barriers to achieve innovative satellite applications and services, and seamless integration with terrestrial networks. The services are characterized by direct or global broadcast capabilities of LEO/MEO/GEO satellites, high and possibly asymmetric bandwidth, and unconventional network routing/switching. Applications of such services include Internet access, telemedicine, public information services, distance learning, entertainment, digital battlefield, emergency and disaster response, and many more. Topics: Papers are solicited in all research and applied areas related to satellite-based information services (including, but not limited to): * Innovative applications using satellite services * System architectures for hybrid satellite systems (LEO and GEO or MEO and GEO) * Distributed computing using satellite communications * Protocol and service interoperability with terrestrial networks * Software techniques for reducing latency in satellite applications * ATM over satellites * Quality of Service interoperability with terrestrial networks * Medium Access Control protocols for LEO/MEO/GEO or hybrid networks. * Routing protocols in satellite networks * TCP/IP for satellite communications * Internet applications, WWW access and cache through satellites * Direct broadcast and multicast applications * Reliability and scalability in satellite applications * Software for satellite switch control * Mobile computing and location tracking in satellite applications * Inter-satellite communication and network management * Middleware for satellite-based information services development The setting of the workshop will be informal, and will encourage discussion and interaction. We solicit the submission of research papers, position papers, experience papers, and panel proposals. SUBMISSIONS We invite papers for presentation and discussion at the workshop. Send a postscript copy of the paper by email to: ryu@hrl.com. The page limit on all submissions is 5-10 pages, double spaced, 10 pt minimum (approximately 1500-2500 words). If electronic submission is not possible, send three (3) hard copies to: Bo Ryu HRL Laboratories, MA/254/RL96, 3011 Malibu Canyon Road Malibu, CA 90265 PROCEEDINGS: An informal proceedings will be published and distributed at the workshop. The format will be similar to standard ACM proceedings: double column, single spaced and the page limit on each paper is 12. Papers with outstanding merit will be considered for publication in a special issue of ACM MONET. IMPORTANT DATES: * Papers Due: July 1st, 1998 * Acceptance Notification: Sep. 1st, 1998 * Camera ready: Sep. 30, 1998 * Workshop: Oct. 30, 1998 WEB SITE: http://www.wins.hrl.com/conferences/WOSBIS98/ GENERAL CO-CHAIRS: Son K. Dao, HRL Labs., USA Randy Katz, UC Berkeley, USA TECHNICAL PROGRAM CO-CHAIRS: Horst Clausen, U. of Salzburg, Austria Bo Ryu, HRL Labs., USA PUBLICITY: Yongguang Zhang, HRL Labs. TECHNICAL PROGRAM COMMITTEE: Mark Allman, NASA LeRC, USA Rafael Alonso, David Sarnoff Research Center, USA Imrich Chlamtac, U. Texas at Dallas, USA Walid Dabbous, INRIA, France Anthony Ephremides, U. of Maryland, USA Barry G. Evans, U. of Surrey, UK Mike Fitch, British Telecom, UK Raj Jain, Ohio State U., USA Hans Kruse, Ohis U., USA David Lee, Bell Labs, USA Mischa Schwartz, Columbia U., USA Csaba Szabo, Technical U. of Budapest, Hungary Bharghavan Vaduvur, UIUC, USA. Nitin Vaidya, Texas A&M U., USA Thomas VonDeak, NASA LeRC, USA Ouri Wolfson, U. of Illinois at Chicago, USA --------------B691B2BF999D8B6F84EBFEBA-- From owner-tcp-over-satellite@achtung.sp.trw.com Tue May 12 00:15:10 1998 Delivery-Date: Tue, 12 May 1998 00:15:10 -0400 Return-Path: owner-tcp-over-satellite@achtung.sp.trw.com Received: from achtung.sp.trw.com (achtung.sp.TRW.COM [129.4.53.140]) by ietf.org (8.8.5/8.8.7a) with SMTP id AAA07385 for ; Tue, 12 May 1998 00:15:09 -0400 (EDT) Received: by achtung.sp.trw.com (4.1/SMI-4.1) id AA28933; Mon, 11 May 98 19:45:55 PDT Received: from mail-relay1.trw.com by achtung (4.1/SMI-4.1) id AA28928; Mon, 11 May 98 19:45:41 PDT Received: from dangle.wins.hrl.com ([206.17.46.85]) by mail-relay1.trw.com (8.8.8/8.8.8) with SMTP id TAA06298 for ; Mon, 11 May 1998 19:49:45 -0700 (PDT) Received: from dhcp-46.wins.hrl.com by dangle.wins.hrl.com (5.65v3.2/1.1.10.5/24Apr98-0905PM) id AA20392; Mon, 11 May 1998 19:51:40 -0700 Message-Id: <3557BA08.FE75B419@isl.hrl.hac.com> Date: Tue, 12 May 1998 02:55:04 +0000 From: Bo Ryu Organization: Hughes Research Labs X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.32 i586) Mime-Version: 1.0 To: TCP-over-Satellite , end2end-interest@isi.edu, int-serv@isi.edu, pint@lists.research.bell-labs.com, qosr@newbridge.com, idmr@cs.ucl.ac.uk, idr@merit.edu, udlr@sophia.inria.fr, ion@sunroof.eng.sun.com, lsma@gmu.edu, ietf-asid@umich.edu, http-wg@cuckoo.hpl.hp.com, mboned@network-services.uoregon.edu, roamops@tdmx.rutgers.edu, ietf-lsd@listserv.umu.se Subject: First CFP for WOSBIS'98 (Mobicom'98 workshop) Content-Type: multipart/mixed; boundary="------------B691B2BF999D8B6F84EBFEBA" Sender: owner-tcp-over-satellite@achtung.sp.trw.com Precedence: bulk This is a multi-part message in MIME format. --------------B691B2BF999D8B6F84EBFEBA Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Enclosed please find the first CFP for the Third Workshop on Satellite-Based Information Society (WOSBIS'98). Please accept my appology if you receive duplicates. Regards, -Bo -- ----------------------------------- Bo Ryu E-mail:ryu@hrl.com HRL, LLC. (formerly Hughes Research Labs) 3011 Malibu Can. Rd. Tel: +1 (310) 317-5487, Fax: +1 (310) 317-5695 Malibu, CA 90265 URL: http://www.wins.hrl.com/people/ryu --------------B691B2BF999D8B6F84EBFEBA Content-Type: text/plain; charset=iso-2022-kr; name="WOSBIS98-CFP.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="WOSBIS98-CFP.txt" CALL FOR PAPERS 3rd Int'l Workshop on Satellite-based Information Services (WOSBIS'98) October 30, 1998 Dallas , Texas In conjunction with ACM MobiCom'98 Sponsored by ACM Sigmobile and technical co-sponsored by IEEE Scope: We are witnessing that satellites are becoming an integral part of our daily lives in this information-rich and global society. This is evidenced by the systems currently in operation (e.g., DirecTV(TM), DirecPC, GPS, and Iridium) as well as those to offer broadband, interactive, and multimedia Internet services around the next millennium (SpaceWay, Teledesic, Astrolink, Celestri, etc.). In conjunction with MOBICOM'98, this workshop provides a forum for exploratory research contributions on lifting the technological barriers to achieve innovative satellite applications and services, and seamless integration with terrestrial networks. The services are characterized by direct or global broadcast capabilities of LEO/MEO/GEO satellites, high and possibly asymmetric bandwidth, and unconventional network routing/switching. Applications of such services include Internet access, telemedicine, public information services, distance learning, entertainment, digital battlefield, emergency and disaster response, and many more. Topics: Papers are solicited in all research and applied areas related to satellite-based information services (including, but not limited to): * Innovative applications using satellite services * System architectures for hybrid satellite systems (LEO and GEO or MEO and GEO) * Distributed computing using satellite communications * Protocol and service interoperability with terrestrial networks * Software techniques for reducing latency in satellite applications * ATM over satellites * Quality of Service interoperability with terrestrial networks * Medium Access Control protocols for LEO/MEO/GEO or hybrid networks. * Routing protocols in satellite networks * TCP/IP for satellite communications * Internet applications, WWW access and cache through satellites * Direct broadcast and multicast applications * Reliability and scalability in satellite applications * Software for satellite switch control * Mobile computing and location tracking in satellite applications * Inter-satellite communication and network management * Middleware for satellite-based information services development The setting of the workshop will be informal, and will encourage discussion and interaction. We solicit the submission of research papers, position papers, experience papers, and panel proposals. SUBMISSIONS We invite papers for presentation and discussion at the workshop. Send a postscript copy of the paper by email to: ryu@hrl.com. The page limit on all submissions is 5-10 pages, double spaced, 10 pt minimum (approximately 1500-2500 words). If electronic submission is not possible, send three (3) hard copies to: Bo Ryu HRL Laboratories, MA/254/RL96, 3011 Malibu Canyon Road Malibu, CA 90265 PROCEEDINGS: An informal proceedings will be published and distributed at the workshop. The format will be similar to standard ACM proceedings: double column, single spaced and the page limit on each paper is 12. Papers with outstanding merit will be considered for publication in a special issue of ACM MONET. IMPORTANT DATES: * Papers Due: July 1st, 1998 * Acceptance Notification: Sep. 1st, 1998 * Camera ready: Sep. 30, 1998 * Workshop: Oct. 30, 1998 WEB SITE: http://www.wins.hrl.com/conferences/WOSBIS98/ GENERAL CO-CHAIRS: Son K. Dao, HRL Labs., USA Randy Katz, UC Berkeley, USA TECHNICAL PROGRAM CO-CHAIRS: Horst Clausen, U. of Salzburg, Austria Bo Ryu, HRL Labs., USA PUBLICITY: Yongguang Zhang, HRL Labs. TECHNICAL PROGRAM COMMITTEE: Mark Allman, NASA LeRC, USA Rafael Alonso, David Sarnoff Research Center, USA Imrich Chlamtac, U. Texas at Dallas, USA Walid Dabbous, INRIA, France Anthony Ephremides, U. of Maryland, USA Barry G. Evans, U. of Surrey, UK Mike Fitch, British Telecom, UK Raj Jain, Ohio State U., USA Hans Kruse, Ohis U., USA David Lee, Bell Labs, USA Mischa Schwartz, Columbia U., USA Csaba Szabo, Technical U. of Budapest, Hungary Bharghavan Vaduvur, UIUC, USA. Nitin Vaidya, Texas A&M U., USA Thomas VonDeak, NASA LeRC, USA Ouri Wolfson, U. of Illinois at Chicago, USA --------------B691B2BF999D8B6F84EBFEBA-- From owner-idr@merit.edu Mon May 18 10:31:48 1998 Delivery-Date: Mon, 18 May 1998 10:31:48 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA23821 for ; Mon, 18 May 1998 10:31:48 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA02986 for ; Mon, 18 May 1998 10:34:13 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA18870 for idr-outgoing; Mon, 18 May 1998 10:04:17 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA18866 for ; Mon, 18 May 1998 10:04:13 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA23151; Mon, 18 May 1998 10:03:36 -0400 (EDT) Message-Id: <199805181403.KAA23151@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-route-damp-03.txt,.ps Date: Mon, 18 May 1998 10:03:36 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Route Flap Damping Author(s) : C. Villamizar, R. Govindan, R. Chandra Filename : draft-ietf-idr-route-damp-03.txt,.ps Pages : 33 Date : 15-May-98 A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes. This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead An excessive rate of update to the advertised reachability of a subset of Internet prefixes has been widespread in the Internet. This observation was made in the early 1990s by many people involved in Internet operations and remains the case. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is ``route flap''. The techniques described here are now widely deployed and are commonly referred to as ``route flap damping''. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-damp-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-route-damp-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-damp-03.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980515162442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-damp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-damp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980515162442.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Mon May 18 10:39:20 1998 Delivery-Date: Mon, 18 May 1998 10:47:02 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id KAA23883 for ietf-123-outbound.10@ietf.org; Mon, 18 May 1998 10:35:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA23151; Mon, 18 May 1998 10:03:36 -0400 (EDT) Message-Id: <199805181403.KAA23151@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-route-damp-03.txt,.ps Date: Mon, 18 May 1998 10:03:36 -0400 Sender: cclark@CNRI.RESTON.VA.US --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Route Flap Damping Author(s) : C. Villamizar, R. Govindan, R. Chandra Filename : draft-ietf-idr-route-damp-03.txt,.ps Pages : 33 Date : 15-May-98 A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes. This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead An excessive rate of update to the advertised reachability of a subset of Internet prefixes has been widespread in the Internet. This observation was made in the early 1990s by many people involved in Internet operations and remains the case. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is ``route flap''. The techniques described here are now widely deployed and are commonly referred to as ``route flap damping''. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-damp-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-route-damp-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-damp-03.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980515162442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-damp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-damp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980515162442.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Fri May 22 12:26:32 1998 Delivery-Date: Fri, 22 May 1998 12:26:32 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA06132 for ; Fri, 22 May 1998 12:26:32 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA21383 for ; Fri, 22 May 1998 12:28:56 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id MAA03885 for idr-outgoing; Fri, 22 May 1998 12:02:32 -0400 (EDT) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by merit.edu (8.8.7/8.8.5) with SMTP id MAA03878 for ; Fri, 22 May 1998 12:02:28 -0400 (EDT) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id JAA13997 for idr@merit.edu; Fri, 22 May 1998 09:01:57 -0700 Message-Id: <199805221601.JAA13997@puli.cisco.com> To: idr@merit.edu Subject: WG last call Date: Fri, 22 May 98 09:01:57 PDT From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, This is to start the WG Last Call on draft-ietf-idr-route-damp-03.txt,.ps. The end of the last call is on June 5. Yakov. ------- Forwarded Message Return-Path: owner-idr@merit.edu Received: from kickme.cisco.com (kickme.cisco.com [198.92.30.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id HAA05334; Mon, 18 May 1998 07:13:01 -0700 Received: from proxy3.cisco.com (proxy3.cisco.com [192.31.7.90]) by kickme.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with ESMTP id HAA01783; Mon, 18 May 1998 07:12:59 -0700 (PDT) Received: (from smap@localhost) by proxy3.cisco.com (8.8.7/8.8.5) id HAA08569; Mon, 18 May 1998 07:12:56 -0700 (PDT) Received: from merit.edu(198.108.1.42) by proxy3.cisco.com via smap (V2.0) id xma008554; Mon, 18 May 98 14:12:53 GMT X-SMAP-Received-From: outside Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA18870 for idr-outgoing; Mon, 18 May 1998 10:04:17 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA18866 for ; Mon, 18 May 1998 10:04:13 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA23151; Mon, 18 May 1998 10:03:36 -0400 (EDT) Message-Id: <199805181403.KAA23151@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-route-damp-03.txt,.ps Date: Mon, 18 May 1998 10:03:36 -0400 Sender: owner-idr@merit.edu Precedence: bulk - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : BGP Route Flap Damping Author(s) : C. Villamizar, R. Govindan, R. Chandra Filename : draft-ietf-idr-route-damp-03.txt,.ps Pages : 33 Date : 15-May-98 A usage of the BGP routing protocol is described which is capable of reducing the routing traffic passed on to routing peers and therefore the load on these peers without adversely affecting route convergence time for relatively stable routes. This technique has been implemented in commercial products supporting BGP. The technique is also applicable to IDRP. The overall goals are: o to provide a mechanism capable of reducing router processing load caused by instability o in doing so prevent sustained routing oscillations o to do so without sacrificing route convergence time for generally well behaved routes. This must be accomplished keeping other goals of BGP in mind: o pack changes into a small number of updates o preserve consistent routing o minimal addition space and computational overhead An excessive rate of update to the advertised reachability of a subset of Internet prefixes has been widespread in the Internet. This observation was made in the early 1990s by many people involved in Internet operations and remains the case. These excessive updates are not necessarily periodic so route oscillation would be a misleading term. The informal term used to describe this effect is ``route flap''. The techniques described here are now widely deployed and are commonly referred to as ``route flap damping''. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-route-damp-03.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-route-damp-03.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-route-damp-03.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980515162442.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-route-damp-03.txt - --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-route-damp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980515162442.I-D@ietf.org> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message From tcplw-relay@services.BSDI.COM Wed Jun 3 07:50:27 1998 Delivery-Date: Wed, 03 Jun 1998 07:53:33 -0400 Return-Path: tcplw-relay@services.BSDI.COM Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA15294 for ; Wed, 3 Jun 1998 07:43:40 -0400 (EDT) Received: from services.BSDI.COM (services.BSDI.COM [205.230.225.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA12429 for ; Wed, 3 Jun 1998 07:45:56 -0400 (EDT) Received: (from daemon@localhost) by services.BSDI.COM (8.8.7/8.8.8) id FAA02933 for tcplw-list@bsdi.com; Wed, 3 Jun 1998 05:39:32 -0600 (MDT) Received: from mailfilter.bsdi.com (mailfilter.BSDI.COM [205.230.225.21]) by services.BSDI.COM (8.8.7/8.8.8) with ESMTP id FAA02930 for ; Wed, 3 Jun 1998 05:39:26 -0600 (MDT) Received: from soleil.uvsq.fr (soleil.uvsq.fr [193.51.24.1]) by mailfilter.bsdi.com (BSDI-MF 1.0) with ESMTP id KAA06938 for env-from (Michelle.Claude@prism.uvsq.fr); Tue, 2 Jun 1998 10:53:17 -0600 (MDT) Received: from guillotin.prism.uvsq.fr (guillotin.prism.uvsq.fr [193.51.25.1]) by soleil.uvsq.fr (8.8.8/jtpda-5.3) with ESMTP id SAA10942 ; Tue, 2 Jun 1998 18:48:51 +0200 (METDST) Received: from bonacieu.prism.uvsq.fr (bonacieu.prism.uvsq.fr [193.51.25.106]) by guillotin.prism.uvsq.fr (8.8.4/jtpda-5.2) with SMTP id SAA06275 ; Tue, 2 Jun 1998 18:46:18 +0200 (MET DST) Message-Id: <1.5.4.32.19980602164754.006b0824@guillotin.prism.uvsq.fr> X-Sender: mic@guillotin.prism.uvsq.fr X-Mailer: Windows Eudora Light Version 1.5.4 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 02 Jun 1998 18:47:54 +0200 To: rabah@auto.emn.fr, rachid@lsa.u-picardie.fr, raczy@lifl.fr, rafaelp@cogs.susx.ac.uk, rafiq@crisv2.univ-pau.fr, raghu@iss.nus.sg, raja@laas.fr, ramak@lifac.ens-cachan.fr, ran@ee.technion.ac.il, rauzy@lumimath.univ-mrs.fr, raynal@irisa.fr, raynaud@irit.fr, raynaud@limhp.univ-paris13.fr, rbb@isid.ernet.in, rcohen@csa.CS.Technion.AC.IL, rdantu@tddcae99.fnts.com, reboulet@jupiter.cert.fr, reed@oboe.cs.uiuc.edu, reeves@eos.ncsu.edu, reinartz@informatik.uni-erlangen.de, reiser@inf.ethz.ch, Remy.Giraud@meteo.fr, richard@univ-tours.fr, rigault@res.enst.fr, rjp@ncp.gpt.co.uk, rlfike@aol.com, rlozano@hds.univ-compiegne.fr, rne@hybrid.com, rnelson@ox.com, robert@mic.laas.fr, roberto.saracco@cselt.stet.it, Roland.Balter@imag.fr, rom@ee.technion.ac.il, Romeo.Ortega@hds.univ-compiegne.fr, Ron.Horn.0090874@nt.com, roro@titan.enst-bretagne.fr, roubella@laas.fr, rouchon@cas.ensmp.fr, roux@laas.fr, rst@kom.e-technik.th-darmstadt.de, rtsai@e0sun3.ccl.itri.org.tw, rubino@irisa.fr, ruget@chorus.fr, saito@hashi.ntt.jp, saive@idris.fr, sal@Mozart1.INSL.McGill.CA, sallet@ilm.loria.fr, salut@laas.fr, samoht@cc.ec-lyon.fr, sanlavil@ucfma.univ-bpclermont.fr, santafecs@aol.com, saracco@cselt.stet.it, sbell@bmth.ac.uk, sbw@ccrl.nj.nec.com, sc@etca.fr, sc6wg4@ntd.comsat.com, schaff@loria.fr, schmid@dfki.uni-kl.de, schnoebelen@imag.fr, schulzrinne@cs.columbia.edu, schuppen@cwi.nl, schwaab@loria.loria.fr, schwartz@ctr.columbia.edu, scott_linke@aus.hp.com, segall@cs.technion.ac.il, serazzi@morgana.elet.polimi.it, Serge.Fdida@masi.ibp.fr, Sergio.Yovine@imag.fr, sericola@irisa.fr, shapiro@prof.inria.fr, shima@hashi.ntt.jp, shimojo@ICS.UCI.EDU, shuli@ee.technion.ac.il, sibilla@irit.fr, sibille@cran.u-nancy.fr, sidou@eurecom.fr, sie@probe.att.com, sigmedia@bellcore.com, silva@etsii.unizar.es, simon@cui.unige.ch, simon@gmc.insa-lyon.fr, simoni@res.enst.fr, simonian@issy.cnet.fr, siron@issy.cnet.fr, skudoh@shako.sk.tsukuba.ac.jp, skumar@cs.columbia.edu, slh@ti.ens-fcl.fr, smith@CS.Berkeley.EDU, snelling@cs.man.ac.uk, sohier@lurpa.ens-cachan.fr, song@loria.fr, soueres@laas.fr, sound@acm.org, soyez@lsa.u-picardie.fr, spaniol@informatik.rwth-aachen.de, ssjoo@tdx.etri.re.kr, sslaven@watson.ibm.com, Stanislaw.Budkowski@hugo.int-evry.fr, stanm@bellcore.com, staples@bnr.ca, stefani@issy.cnet.fr, stelios@csi.forth.gr, Stephane.Gaubert@inria.fr, stephane.michel@der.edf.fr, steve.pollock@umich.edu, steve@o2tech.fr, steve@sics.se, sugi@rd.nacsis.ac.jp, suruagy@di.ufpe.br, svr@shiva.iitm.ernet.in, tabti@inrets.fr, tacquard@univ-tours.fr, takagi@shako.sk.tsukuba.ac.jp, takahasi@nttgoso.ntt.jp, takine@ise.eng.osaka-u.ac.jp, talay@sophia.inria.fr, tandriot@suisse.far.cea.fr, tantawi@watson.ibm.com, tarek@lrps.u-strasbg.fr, tasaka@elcom.nitech.ac.jp, Tayeb.Ben-Meriem@int-evry.fr, tbraun@entropy.inria.fr, tcplw@bsdi.com, tellez@hugo.int-evry.fr, testnet@canarie.ca, thai@masi.ibp.fr, thamel@hds.univ-compiegne.fr, thierry@cert.fr, thom@insa.insa-lyon.fr, thomas.baumann@ia.epfl.ch, thomesse@loria.fr, thuilot@suisse.far.cea.fr, tigli@alto.unice.fr, titli@laas.fr, tjo@bellcore.com, tlp@big.att.com, tmarnet@euriware.fr, tobagi@soe.Stanford.EDU, todd@mcmaster.ca, tohme@res.enst.fr, toinard@fermi.cnam.fr, toinard@labri.u-bordeaux.fr, tomonori@exa.onlab.ntt.jp, tondu@dge.insa-tlse.fr, tony@eng.umd.edu, toure@lagep.univ-lyon1.fr, toutain@rsm.enst-bretagne.fr, towsley@cs.umass.edu, trangia@informatik.uni-wuerzburg.de, treca@urec.fr, trehel@comte.univ-fcomte.fr, tripathi@cs.umd.edu, trobles@dit.upm.es, trystram@imag.fr, tsr@iitk.ernet.in, tsuchida@csl.melco.co.jp, tsuzuki@ccsd.ho.nec.co.jp, tsyum@ie.cuhk.hk, ttlee@ie.cuhk.hk, Tulin.Atmaca@int-evry.fr, uist.chi@Xerox.com, ulfk@tts.lu.se, urban@egd.igd.fhg.de, uriy@math.tau.ac.il, utpal@ece.iisc.ernet.in, valduriez@rodin.inria.fr, vanas@mail.zserv.tuwien.ac.at, vandrome@coria.fr, vberge@hds.univ-compiegne.fr, Vecchi@dassault-elec.fr, venieris@theseas.softlab.ece.ntua.gr, ventre@cps.na.cnr.it, vernadat@poncelet.univ-metz.fr, vernon@cs.wisc.edu, veron@cran.u-nancy.fr, Veronique.Gleize@der.edf.fr, Veronique.Veque@lri.fr, vila@ensam.inra.fr, Vincent.Dumas@inria.fr, virot@univ-orleans.fr, vivalda@ilm.loria.fr, voicu@zeus.genie.uottawa.ca, wagneur@auto.emn.fr, waisum@buckaroo.ho.att.com, wakid@nist.gov, walkup@cs.washington.edu, walter@lss.supelec.fr, wbu@zurich.ibm.com, weber@psc.informatik.uni-frankfurt.de, wertz@auto.ucl.ac.be, westphal@inf.ufsc.br, WGODWIN@chelt.ac.uk, whs@crhc.uiuc.edu, willink@rrl.co.uk, wolfson@ouri.eecs.uic.edu, wonham@odin.control.utoronto.ca, wow@research.att.com, wz@first.gmd.de, xrjo@atc.boeing.com, xu@ilm.loria.fr, yabe@kouken.csl.melco.co.jp, yakov@buckaroo.ho.att.com, yamamoto@comm.eng.osaka-u.ac.jp, yamamoto@cs.umass.edu, yamanouc@trl.ibm.co.jp, yang@nice.etri.re.kr, yang@trix.genie.uottawa.ca, yavatkar@ideal.jf.intel.com, yemini@cs.columbia.edu, yevin@sam.imash.ras.ru, yim@ec-lille.fr, yolande@cs.kuleuven.ac.be, yoshida@netwk.ntt-at.co.jp, youcef@lagep.univ-lyon1.fr, yrobert@lip.ens-lyon.fr, yutaka@kuamp.kyoto-u.ac.jp, Yves.Fouquet@der.edf.fr, yves.quenechdu@supelec.fr, Yves.Sorel@inria.fr, yy@smarts.com, Zack.lakdari@lacp.ismra.fr, zahorjan@cs.washington.edu, zaninotti@korrigan.cea.fr, zapata@lirmm.lirmm.fr, zeyons@onera.fr, zig@atri.curtin.edu.au, ziram@etna.int-evry.fr, zit@ibr.cs.tu-bs.de, zjh1@cornell.edu, zoran@cs.uq.oz.au, zouaoui@masi.ibp.fr, Guy.Pujolle@prism.uvsq.fr From: =?iso-8859-1?Q?Michelle_Claud=E9_=3CMichelle.Claude=40prism.uvsq.fr=3E?=@prism.uvsq.fr Subject: MMNS98 Second IFIP/IEEE International Conference on Management of Multimedia Networks and Services '98 MMNS'98 ************************************** CALL FOR PAPERS EXTENDED TO JUNE 26 ************************************** Versailles, FRANCE November 16-18, 1998 Organized by: DNAC & PRISM Lab., University of Versailles Co-sponsored by: IFIP Working Group 6.4 and 6.6 and IEEE Communications Society see our web page at : http://www.prism.uvsq.fr/~mmns98 From owner-idr@merit.edu Thu Jun 4 10:36:17 1998 Delivery-Date: Thu, 04 Jun 1998 10:36:18 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA14467 for ; Thu, 4 Jun 1998 10:36:17 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA18497 for ; Thu, 4 Jun 1998 10:38:40 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA08096 for idr-outgoing; Thu, 4 Jun 1998 10:13:16 -0400 (EDT) Received: from ietf.org (ietf.org [132.151.1.19]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA08092 for ; Thu, 4 Jun 1998 10:13:11 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA13982; Thu, 4 Jun 1998 10:12:34 -0400 (EDT) Message-Id: <199806041412.KAA13982@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-multiprotocol-v2-00.txt Date: Thu, 04 Jun 1998 10:12:33 -0400 Sender: owner-idr@merit.edu Precedence: bulk --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 : Multiprotocol Extensions for BGP-4 Author(s) : D. Katz, Y. Rekhter, T. Bates, R. Chandra Filename : draft-ietf-idr-bgp4-multiprotocol-v2-00.txt Pages : 10 Date : 03-Jun-98 Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-multiprotocol-v2-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980603142118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-multiprotocol-v2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980603142119.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Thu Jun 4 11:27:04 1998 Delivery-Date: Thu, 04 Jun 1998 11:42:02 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA15951 for ietf-123-outbound.10@ietf.org; Thu, 4 Jun 1998 11:25:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA13982; Thu, 4 Jun 1998 10:12:34 -0400 (EDT) Message-Id: <199806041412.KAA13982@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-multiprotocol-v2-00.txt Date: Thu, 04 Jun 1998 10:12:33 -0400 Sender: cclark@CNRI.RESTON.VA.US --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 : Multiprotocol Extensions for BGP-4 Author(s) : D. Katz, Y. Rekhter, T. Bates, R. Chandra Filename : draft-ietf-idr-bgp4-multiprotocol-v2-00.txt Pages : 10 Date : 03-Jun-98 Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-multiprotocol-v2-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980603142118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-multiprotocol-v2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980603142119.I-D@ietf.org> --OtherAccess-- --NextPart-- From 4n6n61@sprint.com Wed Jun 10 23:00:21 1998 Delivery-Date: Wed, 10 Jun 1998 23:00:22 -0400 Return-Path: 4n6n61@sprint.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA29647 for ; Wed, 10 Jun 1998 23:00:21 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.19]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id XAA16506 for ; Wed, 10 Jun 1998 23:02:45 -0400 (EDT) Received: from gw.shannon-dev.ie (firewall-user@gw.shannon-dev.ie [193.120.120.129]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA29552 for ; Wed, 10 Jun 1998 23:00:17 -0400 (EDT) Received: by gw.shannon-dev.ie; id DAA11087; Thu, 11 Jun 1998 03:44:08 +0100 (BST) Date: Thu, 11 Jun 1998 03:44:08 +0100 (BST) Received: from pool-207-205-159-143.lsan.grid.net(207.205.159.143) by gw.shannon-dev.ie via smap (4.1) id xmap10779; Thu, 11 Jun 98 03:43:25 +0100 From: 4n6n61 <4n6n61@sprint.com> To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Thursday, April 23rd, 1998 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Tuesday, April 21st, 1998 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Sunday, April 19th, 1998 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Saturday, April 18th, 1998 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Friday, April 24th, 1998 Reply-To: 4n6n61@sprint.com Authenticated sender is <4n6n61@sprint.com> Subject: 44 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit EMAIL MARKETING WORKS!! Bull's Eye Gold is the PREMIER email address collection tool. This program allows you to develop TARGETED lists of email addresses. Doctors, florists, MLM, biz opp,...you can collect anything...you are only limited by your imagination! You can even collect email addresses for specific states, cities, and even countries! All you need is your web browser and this program. Our software utilizes the latest in search technology called "spidering". By simply feeding the spider program a starting website it will collect for hours. The spider will go from website to targeted website providing you with thousands upon thousands of fresh TARGETED email addresses. When you are done collecting, the spider removes duplicates and saves the email list in a ready to send format. No longer is it necessary to send millions of ads to get a handful of responses...SEND LESS...EARN MORE!!! A terrific aspect of the Bull's Eye software is that there is no difficult set up involved and no special technical mumbo-jumbo to learn. All you need to know is how to search for your targeted market in one of the many search engines and let the spider do the rest! Not familiar with the search engines? No problem, we provide you with a list of all the top search engines. Just surf to the location of a search engine on your browser then search for the market you wish to reach...it's that easy! For instance if you were looking for email addresses of Doctors in New York all you would do is: 1) Do a search using your favorite search engine by typing in the words doctor(s) and New York 2) Copy the URL (one or more)...that's the stuff after the http://... for instance it might look like http://www.yahoo.com/?doctor(s)/?New+York 3) Press the START button THAT's IT!!! The Bull's Eye spider will go to all the websites that are linked, automatically extracting the email addresses you want. The spider is passive too! That means you can let it run all day or all night while you are working on important things or just having fun on your computer. There is no need to keep a constant watch on it, just feed it your target market and give it praise when it delivers thousands of email addresses at the end of the day! Features of the Bull's Eye Software: * Does TARGETED searches of websites collecting the email addresses you want! * Collects Email addresses by City, State, even specific Countries * Runs Automatically...simply enter the Starting information, press The Start Button, and it does the rest * Filters out duplicates * Keeps track of URLs already visited * Can run 24 hours per day, 7 days per week * Fast and Easy List Management * Also has built in filtering options...you can put in words that it "Must" have while searching,...you can even put in criteria that it "Must NOT Have"...giving you added flexibility * Also imports email addresses from any kind of files (text files, binary files, database files) * List editor handles Multiple files to work on many lists simultaneously * Has a Black-Book feature... avoid sending emails to people who do not want to receive it * Built-in Mail program...send email directly on the internet with just a click of your mouse * Personalized Emails...if the email address has the user's name when it is collected,..you can send Personalized emails!!! * Sort by Location, Server, User Name, Contact Name * Advanced Operations: · Email address lists export in many different formats (HTML, Comma delimited, text file) · Advanced editing...Transfer, Copy, Addition, Delete, Crop, Move to Top/Bottom · Operations between lists...Union, Subtraction, Comparison * Program is Passive,...meaning you can run other programs at the same time CALL FOR MORE INFORMATION 213-969-4930 CALL FOR MORE INFORMATION 213-969-4930 ORDERING INFORMATION Customer Name Company Name Address City State Zip Phone Fax Email Address ______ BULL'S EYE SOFTWARE $259.00 Includes Software, Instructions, Technical Support ______ Shipping & Handling (2-3 Day Fedex) $10.00 (Fedex Overnite) $20.00 ______ TOTAL (CA Residents add applicable sales tax) *All orders are for Win 95 and Win NT *****CREDIT CARDS ACCEPTED***** MASTERCARD VISA AMEX PLEASE CALL 213-969-4930 to process your order 9am-5pm Pacific Time Checks or Money Orders send to: WorldTouch Network Inc. 5670 Wilshire Blvd. Suite 2170 Los Angeles, CA 90036 Please note: Allow 5 business days for all checks to clear before order is shipped. From owner-idr@merit.edu Fri Jun 12 05:39:50 1998 Delivery-Date: Fri, 12 Jun 1998 05:39:50 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id FAA11429 for ; Fri, 12 Jun 1998 05:39:50 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id FAA23297 for ; Fri, 12 Jun 1998 05:42:12 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id FAA18548 for idr-outgoing; Fri, 12 Jun 1998 05:11:25 -0400 (EDT) Received: from indovax.ui.ac.id (indovax.ui.ac.id [152.118.2.35]) by merit.edu (8.8.7/8.8.5) with ESMTP id FAA18541 for ; Fri, 12 Jun 1998 05:11:11 -0400 (EDT) Received: (from root@localhost) by indovax.ui.ac.id (8.8.5/8.6.12) id QAA18908; Fri, 12 Jun 1998 16:13:55 +0700 Received: from ietf.org (ietf.org [132.151.1.19]) by kembara.extern.ui.ac.id (8.8.5/8.6.12) with ESMTP id XAA15686 for ; Thu, 4 Jun 1998 23:54:21 +0700 Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id LAA15948 for ietf-123-outbound.07@ietf.org; Thu, 4 Jun 1998 11:25:01 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA13982; Thu, 4 Jun 1998 10:12:34 -0400 (EDT) Message-Id: <199806041412.KAA13982@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp4-multiprotocol-v2-00.txt Date: Thu, 04 Jun 1998 10:12:33 -0400 Sender: owner-idr@merit.edu Precedence: bulk --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 : Multiprotocol Extensions for BGP-4 Author(s) : D. Katz, Y. Rekhter, T. Bates, R. Chandra Filename : draft-ietf-idr-bgp4-multiprotocol-v2-00.txt Pages : 10 Date : 03-Jun-98 Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp4-multiprotocol-v2-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980603142118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp4-multiprotocol-v2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980603142119.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Mon Jun 29 10:58:05 1998 Delivery-Date: Mon, 29 Jun 1998 10:58:05 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA13742 for ; Mon, 29 Jun 1998 10:58:04 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA04308 for ; Mon, 29 Jun 1998 11:00:24 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA19984 for idr-outgoing; Mon, 29 Jun 1998 10:33:19 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA19963 for ; Mon, 29 Jun 1998 10:33:00 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA13095; Mon, 29 Jun 1998 10:32:25 -0400 (EDT) Message-Id: <199806291432.KAA13095@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp-tcp-md5-01.txt Date: Mon, 29 Jun 1998 10:32:25 -0400 Sender: owner-idr@merit.edu Precedence: bulk --NextPart IESG Note: This document describes currrent existing practice for securing BGP against certain simple attacks. It is understood to have security weaknesses against concerted attacks. Note: This revision reflects comments received during the last call period. 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 : Protection of BGP Sessions via the TCP MD5 Signature Option Author(s) : A. Heffernan Filename : draft-ietf-idr-bgp-tcp-md5-01.txt Pages : 5 Date : 26-Jun-98 This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in a TCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points. Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-tcp-md5-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-tcp-md5-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-tcp-md5-01.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980626165629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-tcp-md5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-tcp-md5-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980626165629.I-D@ietf.org> --OtherAccess-- --NextPart-- From adm Mon Jun 29 14:16:39 1998 Delivery-Date: Mon, 29 Jun 1998 14:31:22 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id OAA20880 for ietf-123-outbound.10@ietf.org; Mon, 29 Jun 1998 14:15:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA13095; Mon, 29 Jun 1998 10:32:25 -0400 (EDT) Message-Id: <199806291432.KAA13095@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: idr@merit.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idr-bgp-tcp-md5-01.txt Date: Mon, 29 Jun 1998 10:32:25 -0400 Sender: cclark@ns.cnri.reston.va.us --NextPart IESG Note: This document describes currrent existing practice for securing BGP against certain simple attacks. It is understood to have security weaknesses against concerted attacks. Note: This revision reflects comments received during the last call period. 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 : Protection of BGP Sessions via the TCP MD5 Signature Option Author(s) : A. Heffernan Filename : draft-ietf-idr-bgp-tcp-md5-01.txt Pages : 5 Date : 26-Jun-98 This memo describes a TCP extension to enhance security for BGP. It defines a new TCP option for carrying an MD5 [RFC1321] digest in a TCP segment. This digest acts like a signature for that segment, incorporating information known only to the connection end points. Since BGP uses TCP as its transport, using this option in the way described in this paper significantly reduces the danger from certain security attacks on BGP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idr-bgp-tcp-md5-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-bgp-tcp-md5-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idr-bgp-tcp-md5-01.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="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19980626165629.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idr-bgp-tcp-md5-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idr-bgp-tcp-md5-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980626165629.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idr@merit.edu Thu Jul 2 13:58:29 1998 Delivery-Date: Thu, 02 Jul 1998 13:58:29 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA08734 for ; Thu, 2 Jul 1998 13:58:28 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA22527 for ; Thu, 2 Jul 1998 14:00:48 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA03724 for idr-outgoing; Thu, 2 Jul 1998 13:39:23 -0400 (EDT) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA03720 for ; Thu, 2 Jul 1998 13:39:18 -0400 (EDT) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id KAA03597; Thu, 2 Jul 1998 10:38:40 -0700 Message-Id: <199807021738.KAA03597@puli.cisco.com> To: rcoltun@fore.com cc: idr@merit.edu Subject: draft-ietf-idr-bgp-tcp-md5-01.txt to PS Date: Thu, 02 Jul 98 10:38:40 PDT From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Rob, The IDR WG would like to ask the IESG to advance draft-ietf-idr-bgp-tcp-md5-01.txt to a Proposed Standard. Yakov. From owner-idr@merit.edu Mon Jul 6 13:40:02 1998 Delivery-Date: Mon, 06 Jul 1998 13:40:02 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA26010 for ; Mon, 6 Jul 1998 13:40:02 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id NAA04266 for ; Mon, 6 Jul 1998 13:42:22 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA19907 for idr-outgoing; Mon, 6 Jul 1998 13:24:34 -0400 (EDT) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by merit.edu (8.8.7/8.8.5) with SMTP id NAA19902 for ; Mon, 6 Jul 1998 13:24:30 -0400 (EDT) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id KAA05086 for idr@merit.edu; Mon, 6 Jul 1998 10:23:56 -0700 Message-Id: <199807061723.KAA05086@puli.cisco.com> To: idr@merit.edu Subject: IDR WG meeting schedule Date: Mon, 06 Jul 98 10:23:55 PDT From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Folks, Here are the dates for the WG meeting: Wednesday, August 26 at 0900-1130 other groups scheduled at that time: ipfc, OPS Area Meeting, smime, diffserv Thursday, August 27 at 1300-1500 other groups scheduled at that time: hubmib, saag, rtfm Please send me and Sue proposals for the agenda items. Yakov. From owner-idr@merit.edu Fri Jul 10 17:27:33 1998 Delivery-Date: Fri, 10 Jul 1998 17:27:33 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA04913 for ; Fri, 10 Jul 1998 17:27:32 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id RAA22751 for ; Fri, 10 Jul 1998 17:27:30 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id RAA20463 for idr-outgoing; Fri, 10 Jul 1998 17:08:16 -0400 (EDT) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by merit.edu (8.8.7/8.8.5) with SMTP id RAA20444 for ; Fri, 10 Jul 1998 17:08:06 -0400 (EDT) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id OAA22753; Fri, 10 Jul 1998 14:07:34 -0700 Message-Id: <199807102107.OAA22753@puli.cisco.com> To: rcoltun@fore.com cc: idr@merit.edu Subject: draft-ietf-idr-route-damp-03.txt to PS Date: Fri, 10 Jul 98 14:07:33 PDT From: Yakov Rekhter Sender: owner-idr@merit.edu Precedence: bulk Rob, The IDR WG would like to ask the IESG to advance draft-ietf-idr-route-damp-03.txt to a Proposed Standard. Yakov. From owner-idr@merit.edu Sun Jul 12 15:52:37 1998 Delivery-Date: Sun, 12 Jul 1998 15:52:37 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA08434 for ; Sun, 12 Jul 1998 15:52:37 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA01049 for ; Sun, 12 Jul 1998 15:52:35 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA12428 for idr-outgoing; Sun, 12 Jul 1998 15:37:45 -0400 (EDT) Received: from mail.nyp.ans.net (mail.nyp.ans.net [147.225.190.25]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA12422 for ; Sun, 12 Jul 1998 15:37:39 -0400 (EDT) Received: from skycorp.skynet.be (skycorp.skynet.be [195.238.0.128]) by mail.nyp.ans.net (8.8.7/8.8.7) with ESMTP id PAA18424 for ; Sun, 12 Jul 1998 15:37:38 -0400 (EDT) Received: from login.skynet.be (dialup32.wavre.skynet.be [195.238.10.32]) by skycorp.skynet.be (8.8.8/jovi-relay-1.1-vw) with ESMTP id VAA11303; Sun, 12 Jul 1998 21:36:47 +0200 (MET DST) Message-Id: <199807121936.VAA11303@skycorp.skynet.be> From: "benoit tilmant" To: , Subject: Add idr-request, Add iwg benoit.tilmant@skynet.be Date: Sun, 12 Jul 1998 21:40:21 +0200 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Add idr-request, Add iwg benoit.tilmant@skynet.be From owner-idr@merit.edu Mon Jul 13 15:27:56 1998 Delivery-Date: Mon, 13 Jul 1998 15:27:56 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA05332 for ; Mon, 13 Jul 1998 15:27:55 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id PAA05198 for ; Mon, 13 Jul 1998 15:27:50 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA02814 for idr-outgoing; Mon, 13 Jul 1998 15:09:14 -0400 (EDT) Received: from tofu.ibnets.com (tofu.ironbridgenetworks.com [146.115.140.72]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA02807 for ; Mon, 13 Jul 1998 15:09:05 -0400 (EDT) Received: (from wmesard@localhost) by tofu.ibnets.com (8.8.7/8.8.7) id PAA14018; Mon, 13 Jul 1998 15:06:35 -0400 Date: Mon, 13 Jul 1998 15:06:35 -0400 Message-Id: <199807131906.PAA14018@tofu.ibnets.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Wayne Mesard To: idr@merit.edu Subject: Re: BGP alternate routes Newsgroups: lists.ietf.idr In-Reply-To: Tony Li's message of 12 July 1998 04:46:08 References: <821zrr7c36.fsf@chimp.juniper.net> X-Mailer: VM 6.38 under Emacs 20.2.1 Sender: owner-idr@merit.edu Precedence: bulk tli@juniper.net (Tony Li) writes: > > The question is : IS IT MANDATORY THEN TO STORE ALL ALTERNATE > > ROUTES TO A DESTINATION? > The protocol specification > says NOTHING about what you have to store. If you decided to not store the > route, that's fine. It would be exactly as if you rejected the route for > administrative purposes. Really? RFC-1771, sec 9, par 5 sez: If the UPDATE message contains a feasible route, it shall be placed in the appropriate Adj-RIB-In... ^^^^^ ||||| And sec 3.2, par 5 sez: In summary, the Adj-RIBs-In contain unprocessed routing information ^^^^^^^^^^^ that has been advertised to the local BGP speaker by its peers; Wayne(); From owner-idr@merit.edu Wed Jul 15 09:18:50 1998 Delivery-Date: Wed, 15 Jul 1998 09:18:51 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA13851 for ; Wed, 15 Jul 1998 09:18:50 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id JAA14076 for ; Wed, 15 Jul 1998 09:18:47 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id IAA08904 for idr-outgoing; Wed, 15 Jul 1998 08:58:44 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id IAA08897 for ; Wed, 15 Jul 1998 08:58:37 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA13259; Wed, 15 Jul 1998 08:58:03 -0400 (EDT) Message-Id: <199807151258.IAA13259@ietf.org> To: IETF-Announce: ; Cc: idr@merit.edu From: The IESG SUBJECT: Last Call: BGP Route Flap Damping to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 15 Jul 1998 08:58:03 -0400 Sender: owner-idr@merit.edu Precedence: bulk The IESG has received a request from the Inter-Domain Routing Working Group to consider BGP Route Flap Damping as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 29, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-route-damp-03.txt From adm Wed Jul 15 09:08:09 1998 Delivery-Date: Wed, 15 Jul 1998 09:19:25 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id JAA13459 for ietf-123-outbound.10@ietf.org; Wed, 15 Jul 1998 09:05:03 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA13259; Wed, 15 Jul 1998 08:58:03 -0400 (EDT) Message-Id: <199807151258.IAA13259@ietf.org> To: IETF-Announce: ; Cc: idr@merit.edu From: The IESG SUBJECT: Last Call: BGP Route Flap Damping to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 15 Jul 1998 08:58:03 -0400 Sender: scoya@ns.cnri.reston.va.us The IESG has received a request from the Inter-Domain Routing Working Group to consider BGP Route Flap Damping as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by July 29, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-idr-route-damp-03.txt From owner-idr@merit.edu Mon Jul 27 12:12:13 1998 Delivery-Date: Mon, 27 Jul 1998 12:12:13 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA17822 for ; Mon, 27 Jul 1998 12:12:13 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA04794 for ; Mon, 27 Jul 1998 12:12:01 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA26376 for idr-outgoing; Mon, 27 Jul 1998 11:49:34 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA26371 for ; Mon, 27 Jul 1998 11:49:29 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA17335; Mon, 27 Jul 1998 11:47:08 -0400 (EDT) Message-Id: <199807271547.LAA17335@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: idr@merit.edu From: The IESG Subject: Protocol Action: Protection of BGP Sessions via the TCP MD5 Signature Option to Proposed Standard Date: Mon, 27 Jul 1998 11:47:08 -0400 Sender: owner-idr@merit.edu Precedence: bulk The IESG has approved the Internet-Draft 'Protection of BGP Sessions via the TCP MD5 Signature Option' as a Proposed Standard. This document is the product of the Inter-Domain Routing Working Group. The IESG contact person is Rob Coltun. Technical Summary This protocol extension provide a way for BGP-4 peers to authenticate that the TCP messages they are receiving are actually from their peers. This prevents or increases the difficulty of a number of attacks against the protocol machinery. Working Group Summary The working group strongly supports this as the best current mechanism to address these important security threats. Protocol Quality This specification was reviewed for the IESG by Joel M. Halpern, the Routing Area Director. It is already widely implemented. From adm Mon Jul 27 13:06:30 1998 Delivery-Date: Mon, 27 Jul 1998 13:20:43 -0400 Return-Path: adm Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id NAA19273 for ietf-123-outbound.10@ietf.org; Mon, 27 Jul 1998 13:05:02 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA17335; Mon, 27 Jul 1998 11:47:08 -0400 (EDT) Message-Id: <199807271547.LAA17335@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: idr@merit.edu From: The IESG Subject: Protocol Action: Protection of BGP Sessions via the TCP MD5 Signature Option to Proposed Standard Date: Mon, 27 Jul 1998 11:47:08 -0400 Sender: scoya@ns.cnri.reston.va.us The IESG has approved the Internet-Draft 'Protection of BGP Sessions via the TCP MD5 Signature Option' as a Proposed Standard. This document is the product of the Inter-Domain Routing Working Group. The IESG contact person is Rob Coltun. Technical Summary This protocol extension provide a way for BGP-4 peers to authenticate that the TCP messages they are receiving are actually from their peers. This prevents or increases the difficulty of a number of attacks against the protocol machinery. Working Group Summary The working group strongly supports this as the best current mechanism to address these important security threats. Protocol Quality This specification was reviewed for the IESG by Joel M. Halpern, the Routing Area Director. It is already widely implemented. From owner-idr@merit.edu Mon Jul 27 14:18:58 1998 Delivery-Date: Mon, 27 Jul 1998 14:18:59 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA22240 for ; Mon, 27 Jul 1998 14:18:58 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA05853 for ; Mon, 27 Jul 1998 14:18:44 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id NAA29188 for idr-outgoing; Mon, 27 Jul 1998 13:54:06 -0400 (EDT) Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by merit.edu (8.8.7/8.8.5) with ESMTP id NAA29177 for ; Mon, 27 Jul 1998 13:54:01 -0400 (EDT) Received: by relay.hq.tis.com; id NAA24633; Mon, 27 Jul 1998 13:49:13 -0400 (EDT) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma024567; Mon, 27 Jul 98 13:48:25 -0400 Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id NAA24316; Mon, 27 Jul 1998 13:45:16 -0400 (EDT) Date: Mon, 27 Jul 1998 13:45:16 -0400 (EDT) From: Sandy Murphy Message-Id: <199807271745.NAA24316@clipper.hq.tis.com> To: idr@merit.edu Subject: using the TCP MD5 protection for BGP - Proposed Standard??? Cc: sandy@tis.com Sender: owner-idr@merit.edu Precedence: bulk I just saw an announcement that the Protection of BGP Sessions via the TCP MD5 Signature Option draft was being put forward as a Proposed Standard. I hope that I won't hear a chorus of "For God's sake - where have you been!". But I thought that this was going to be proposed as a BCP, not a PS. If the idr group is going to propose a standard for protecting BGP, then more work needs to be done with the TCP MD5 option. The option documents an existing practice and deservedly so. But the existing practice was put into practice before many of the advances in the use of MD5 for integrity and authentication protection were known. It doesn't use some of the ideas that have developed in the ipsec group like using HMAC and replay protection. And this is somewhat my fault, because I have not revised the draft I presented before the group last December to include more discussion of the differences between doing IPSEC, the TCP MD5 proposal or the proposal that was made at the same time of doing MD5 at the BGP layer. Can someone set me straight here? And I obviously missed the fact in the last call that it was being advanced as Proposed Standard, also. Which troubles me, because I try to pay particular attention to security related standards. --Sandy From owner-idr@merit.edu Mon Jul 27 14:48:29 1998 Delivery-Date: Mon, 27 Jul 1998 14:48:30 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA23135 for ; Mon, 27 Jul 1998 14:48:29 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id OAA05997 for ; Mon, 27 Jul 1998 14:48:15 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id OAA29968 for idr-outgoing; Mon, 27 Jul 1998 14:33:12 -0400 (EDT) Received: from quisp.cisco.com (quisp.cisco.com [171.69.95.82]) by merit.edu (8.8.7/8.8.5) with ESMTP id OAA29961 for ; Mon, 27 Jul 1998 14:33:08 -0400 (EDT) Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.51.29]) by quisp.cisco.com (8.8.4-Cisco.1/8.6.5) with ESMTP id LAA25876; Mon, 27 Jul 1998 11:32:37 -0700 (PDT) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA28916; Mon, 27 Jul 1998 11:32:37 -0700 (PDT) Date: Mon, 27 Jul 1998 11:32:37 -0700 (PDT) Message-Id: <199807271832.LAA28916@pedrom-ultra.cisco.com> From: Pedro Marques To: Sandy Murphy Cc: idr@merit.edu Subject: using the TCP MD5 protection for BGP - Proposed Standard??? In-Reply-To: <199807271745.NAA24316@clipper.hq.tis.com> References: <199807271745.NAA24316@clipper.hq.tis.com> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-idr@merit.edu Precedence: bulk >>>>> "Sandy" == Sandy Murphy writes: Sandy> I just saw an announcement that the Protection of BGP Sandy> Sessions via the TCP MD5 Signature Option draft was being Sandy> put forward as a Proposed Standard. Sandy> I hope that I won't hear a chorus of "For God's sake - Sandy> where have you been!". Sandy, My personal recollection is that the IDR wg has decided that the TCP MD5 document should be advanced as Proposed Standard in the December meeting in D. C. This after considering the alternative of publishing the document has BCP. I believe that the group agreed that publishing this document as PS would not preclude the group to work on another method(s) for authentication. regards, Pedro. From owner-idr@merit.edu Mon Jul 27 16:12:19 1998 Delivery-Date: Mon, 27 Jul 1998 16:12:19 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA25178 for ; Mon, 27 Jul 1998 16:12:18 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA06591 for ; Mon, 27 Jul 1998 16:12:05 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA01330 for idr-outgoing; Mon, 27 Jul 1998 15:40:12 -0400 (EDT) Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by merit.edu (8.8.7/8.8.5) with ESMTP id PAA01326 for ; Mon, 27 Jul 1998 15:40:07 -0400 (EDT) Received: by relay.hq.tis.com; id PAA04203; Mon, 27 Jul 1998 15:35:18 -0400 (EDT) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma004190; Mon, 27 Jul 98 15:35:01 -0400 Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id PAA02996; Mon, 27 Jul 1998 15:31:51 -0400 (EDT) Date: Mon, 27 Jul 1998 15:31:51 -0400 (EDT) From: Sandy Murphy Message-Id: <199807271931.PAA02996@clipper.hq.tis.com> To: idr@merit.edu Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard??? Cc: sandy@tis.com Sender: owner-idr@merit.edu Precedence: bulk Thanks, Pedro. Particularly for being kind. I did what I should have done in the first place and checked the archive. Given that I've muddied the water here, I thought I'd better review the history. The discussion of PS vs BCP took place over a couple of weeks after the Dec 97 IETF. Joel Halpern opened the discussion with a question as to "whether proposed standard is the correct status for this document". The two Tony's (Li and Przygienda) argued that PS was not right, but BCP was reasonable. Curtis argued that this was needed right now and PS "sent a message" that might convince the vendors to implement. No final word was heard from Joel. Yakov transferred the draft to the IESG, which announced a last call in February. In March a new draft was announced (extremely minor changes from the draft discussed in Dec). At the end of June another minor revision was announced (this one our automatic retrieval missed). I was remembering the discussion from early this year and subsequent brief discussions with other folk at the March IETF when I asked about BCP. My apologies for asking instead of finding out for myself. --Sandy Murphy From owner-idr@merit.edu Mon Jul 27 16:12:19 1998 Delivery-Date: Mon, 27 Jul 1998 16:12:19 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA25176 for ; Mon, 27 Jul 1998 16:12:18 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA06590 for ; Mon, 27 Jul 1998 16:12:05 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id PAA01119 for idr-outgoing; Mon, 27 Jul 1998 15:28:06 -0400 (EDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by merit.edu (8.8.7/8.8.5) with SMTP id PAA01111 for ; Mon, 27 Jul 1998 15:28:01 -0400 (EDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Mon Jul 27 15:26:24 EDT 1998 Received: from prz-laptop.dnrc.bell-labs.com (prz-laptop [135.180.130.120]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id PAA08705; Mon, 27 Jul 1998 15:26:23 -0400 (EDT) Message-ID: <35BCD37C.28F017C8@dnrc.bell-labs.com> Date: Mon, 27 Jul 1998 15:22:36 -0400 From: Antoni Przygienda Organization: Bell Labs, Lucent X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: Sandy Murphy CC: idr@merit.edu Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard??? X-Priority: 3 (Normal) References: <199807271745.NAA24316@clipper.hq.tis.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Sandy Murphy wrote: > I just saw an announcement that the Protection of BGP Sessions via the > > TCP MD5 Signature Option draft was being put forward as a Proposed > Standard. > > I hope that I won't hear a chorus of "For God's sake - where have > you been!". But I thought that this was going to be proposed as a > BCP, not a PS. If the idr group is going to propose a standard for > protecting BGP, then more work needs to be done with the TCP MD5 > option. > The option documents an existing practice and deservedly so. But the > existing practice was put into practice before many of the advances > in the use of MD5 for integrity and authentication protection were > known. It doesn't use some of the ideas that have developed in the > ipsec > group like using HMAC and replay protection. > As far I remember, the facts you're stating are correct, Sandy ... but I guess one would have to check the minutes to be sure here. --- tony > And this is somewhat my fault, because I have not revised the draft I > presented before the group last December to include more discussion of > > the differences between doing IPSEC, the TCP MD5 proposal or the > proposal that was made at the same time of doing MD5 at the BGP layer. > > Can someone set me straight here? > > And I obviously missed the fact in the last call that it was being > advanced as Proposed Standard, also. Which troubles me, because I > try to pay particular attention to security related standards. From owner-idr@merit.edu Tue Jul 28 12:01:33 1998 Delivery-Date: Tue, 28 Jul 1998 12:01:34 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA15630 for ; Tue, 28 Jul 1998 12:01:33 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id MAA10897 for ; Tue, 28 Jul 1998 12:01:19 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id LAA14302 for idr-outgoing; Tue, 28 Jul 1998 11:42:34 -0400 (EDT) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id LAA14298 for ; Tue, 28 Jul 1998 11:42:29 -0400 (EDT) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.8/8.8.8) with ESMTP id LAA01328; Tue, 28 Jul 1998 11:42:12 -0400 (EDT) (envelope-from curtis@brookfield.ans.net) Message-Id: <199807281542.LAA01328@brookfield.ans.net> To: Sandy Murphy cc: idr@merit.edu Reply-To: curtis@ans.net Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard??? In-reply-to: Your message of "Mon, 27 Jul 1998 13:45:16 EDT." <199807271745.NAA24316@clipper.hq.tis.com> Date: Tue, 28 Jul 1998 11:42:12 -0400 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <199807271745.NAA24316@clipper.hq.tis.com>, Sandy Murphy writes: > > And I obviously missed the fact in the last call that it was being > advanced as Proposed Standard, also. Which troubles me, because I > try to pay particular attention to security related standards. > > --Sandy We've been back and forth and at the last meeting it was agreed that PS was fine since we can always obsolete it if something better comes along (most likely IPSEC standards get implemented). One argument in favor of PS was that to the extent that IETF has any effect on what vendors do, a PS gives vendors more incentive to do more than nothing while waiting for the ultimate solution. Are there any objections to the content of the draft (holes that need to be plugged other than weakness in MD5?). Curtis From owner-idr@merit.edu Tue Jul 28 16:45:40 1998 Delivery-Date: Tue, 28 Jul 1998 16:45:41 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA22601 for ; Tue, 28 Jul 1998 16:45:40 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id QAA12871 for ; Tue, 28 Jul 1998 16:45:27 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id QAA18684 for idr-outgoing; Tue, 28 Jul 1998 16:17:58 -0400 (EDT) Received: from nutmeg.bbn.com (NUTMEG.bbn.com [128.89.1.112]) by merit.edu (8.8.7/8.8.5) with ESMTP id QAA18680 for ; Tue, 28 Jul 1998 16:17:54 -0400 (EDT) Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.7/8.8.7) id QAA00388; Tue, 28 Jul 1998 16:14:51 GMT (envelope-from lsanchez) From: "Luis A. Sanchez" Message-Id: <199807281614.QAA00388@nutmeg.bbn.com> Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard??? In-Reply-To: <199807281542.LAA01328@brookfield.ans.net> from Curtis Villamizar at "Jul 28, 98 11:42:12 am" To: curtis@ans.net Date: Tue, 28 Jul 1998 16:14:50 +0000 (GMT) Cc: sandy@tis.com, idr@merit.edu, skent@bbn.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk > Are there any objections to the content of the draft (holes that need > to be plugged other than weakness in MD5?). > > Curtis > Curtis, there are some problems with the draft "Protection of BGP Sessions via the TCP MD5 Signature Option" aside from using MD5 as _the_ hash function. I did not check the idr archive so maybe someone already made these suggestions. If so, please accept my apologies for wasting your bandwidth. Some of the suggestions listed below will only affect the draft and others will affect the implementation. First, the easy ones: - I found eight instances (not counting the title) of the word "signature" in the document. This should be changed to "Integrity Check Value (ICV)" or "authenticator" I prefer the latter but both terms will be appropriate in this context. Explanation: The protocol carries a keyed-hash as a TCP option. The keys are pre-established manually and are common (of course) to both ends of the communication. In RSA, a signature consists of a hash encrypted with the sender's private key. In DSA, a signature consists of a hash that has been modified by a signature function that depends on the sender's private key and some other public values known to both principals. This TCP option is only hashing the TCP segment and nothing else. No encryption or modification of the hash is performed on the segment before it flows down the stack. Based on the argument provided above I suggest we change the title of the I-D to TCP MD5 Integrity Check Value (ICV) Option and edit the rest of the document accordingly. - There are some residual vulnerabilities in the protocol that i think should be mentioned. For example, the fact that the keys are configured manually (since there is no automated key management facility) implies that these keys will exist for a reasonable amount of time, certainly longer than a single TCP connection since no-one will be reconfiguring the keys manually after every route flap, hard reset or TCP FIN for that matter. THis means that the opportunity exists for an attacker to replay old traffic that could cause interesting problems. Of particular interest, would be recorded traffic carrying hard resets. This traffic would succesfully pass the ICV validation. The trick is in mapping the sequence numbers, which could be done. Although it is harder than it used to be. This changes will affect section 4.1 and will probably require a new section too. - One would want to specify key sizes and ranges to be used in conjuction with MD5. This will allow one to assess the level of security being offered by this mechanism. Security through obscurity (intentionally or not) has proven to be the wrong approach. Hence, section 4.5 needs some more explanation and clarification. Now, the hard ones: - The use of a hash algorithm in this keyed fashion (Keyed-MD5) has been disparaged in the literature for two years, prompting changes in the IPsec RFCs; it seems inappropriate to promote the use of this sort of authentication technology in a newly issued RFC. Personally, i think we should provide an HMAC with either with the option of using it with either (MD5 or SHA-1). I think that minimum we should modify section 4.4 since it gives the impression that the collison problem of MD5 is the only problem with using this option and, that we add a new section comparing the keyed-MD5 transform used in this protocol versus using an HMAC with MD5. Vendors who choose to implement this option and customers who choose to use it will be able to assess the level of security provided by this feature. Luis From owner-idr@merit.edu Tue Jul 28 19:43:09 1998 Delivery-Date: Tue, 28 Jul 1998 19:43:10 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA23834 for ; Tue, 28 Jul 1998 19:43:09 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA13751 for ; Tue, 28 Jul 1998 19:42:54 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id TAA21741 for idr-outgoing; Tue, 28 Jul 1998 19:31:48 -0400 (EDT) Received: from red.juniper.net (red.juniper.net [208.197.169.254]) by merit.edu (8.8.7/8.8.5) with ESMTP id TAA21728 for ; Tue, 28 Jul 1998 19:31:39 -0400 (EDT) Received: from chimp.juniper.net (chimp.juniper.net [208.197.169.196]) by red.juniper.net (8.8.5/8.8.5) with ESMTP id QAA21966; Tue, 28 Jul 1998 16:31:07 -0700 (PDT) Received: (from tli@localhost) by chimp.juniper.net (8.7.6/8.7.3) id QAA08121; Tue, 28 Jul 1998 16:31:02 -0700 (PDT) To: sandy@tis.com (Sandy Murphy) cc: idr@merit.edu Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard??? References: <199807282155.RAA08050@clipper.hq.tis.com> From: Tony Li Date: 28 Jul 1998 16:31:02 -0700 In-Reply-To: sandy@tis.com's message of 28 Jul 98 21:55:40 GMT Message-ID: <82d8apy2mh.fsf@chimp.juniper.net> Lines: 12 X-Mailer: Gnus v5.3/Emacs 19.34 Sender: owner-idr@merit.edu Precedence: bulk sandy@tis.com (Sandy Murphy) writes: > I think everyone agrees that the best solution would be to run your TCP > session over a suitably protected IPSEC link. The problem is whether > IPSEC is available soon enough and enough places. Given that TCP MD5 has been deployed for quite a while, and IPSEC still isn't, I think that IPSEC wasn't 'soon enough'. ;-) Tony From owner-idr@merit.edu Tue Jul 28 20:25:32 1998 Delivery-Date: Tue, 28 Jul 1998 20:25:33 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA24001 for ; Tue, 28 Jul 1998 20:25:32 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA13847 for ; Tue, 28 Jul 1998 20:25:17 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id UAA22490 for idr-outgoing; Tue, 28 Jul 1998 20:16:40 -0400 (EDT) Received: from nutmeg.bbn.com (NUTMEG.bbn.com [128.89.1.112]) by merit.edu (8.8.7/8.8.5) with ESMTP id UAA22483 for ; Tue, 28 Jul 1998 20:16:35 -0400 (EDT) Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.7/8.8.7) id UAA00698; Tue, 28 Jul 1998 20:13:31 GMT (envelope-from lsanchez) From: "Luis A. Sanchez" Message-Id: <199807282013.UAA00698@nutmeg.bbn.com> Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard??? In-Reply-To: <199807282155.RAA08050@clipper.hq.tis.com> from Sandy Murphy at "Jul 28, 98 05:55:40 pm" To: sandy@tis.com (Sandy Murphy) Date: Tue, 28 Jul 1998 20:13:31 +0000 (GMT) Cc: idr@merit.edu, skent@bbn.com X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk Sandy, I should have read the archive first, my apologies once again. I'm glad to hear these discussions took place in the list although I'm surprised to see that the document didn't reflect the technical outcome of these discussions. I understand implementation concerns, time to market issues, etc. still, it would seem to me that while we all await for the deployment of IPSec in our favorite routers it *might* be prudent to make "minor" modifications to what we have available. Just a thought... Luis > The security weaknesses of the MD5 approach were discussed in the mailing > list last December and January. You can see the archive at > ftp://ftp.merit.edu/mail.archives/idr. The replay problem, the preference > for HMAC rather than plain MD5, the need for rollover of keys, etc were > mentioned there. But others argured that this was good to implement until > a better authentication mechanism was specified and easy to put into > specification because it was already (widely) implemented. From owner-idr@merit.edu Tue Jul 28 20:36:38 1998 Delivery-Date: Tue, 28 Jul 1998 20:36:39 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA24076 for ; Tue, 28 Jul 1998 20:36:38 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA13860 for ; Tue, 28 Jul 1998 20:36:23 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id SAA20235 for idr-outgoing; Tue, 28 Jul 1998 18:04:44 -0400 (EDT) Received: from relay.hq.tis.com (relay.hq.tis.com [192.94.214.100]) by merit.edu (8.8.7/8.8.5) with ESMTP id SAA20231 for ; Tue, 28 Jul 1998 18:04:40 -0400 (EDT) Received: by relay.hq.tis.com; id RAA06142; Tue, 28 Jul 1998 17:59:50 -0400 (EDT) Received: from clipper.hq.tis.com(10.33.1.2) by relay.hq.tis.com via smap (4.0a) id xma006119; Tue, 28 Jul 98 17:58:57 -0400 Received: (from sandy@localhost) by clipper.hq.tis.com (8.7.5/8.7.3) id RAA08050; Tue, 28 Jul 1998 17:55:40 -0400 (EDT) Date: Tue, 28 Jul 1998 17:55:40 -0400 (EDT) From: Sandy Murphy Message-Id: <199807282155.RAA08050@clipper.hq.tis.com> To: idr@merit.edu Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard??? Cc: lsanchez@bbn.com, skent@bbn.com Sender: owner-idr@merit.edu Precedence: bulk Luis, I'm sorry I opened my big mouth. The security weaknesses of the MD5 approach were discussed in the mailing list last December and January. You can see the archive at ftp://ftp.merit.edu/mail.archives/idr. The replay problem, the preference for HMAC rather than plain MD5, the need for rollover of keys, etc were mentioned there. But others argured that this was good to implement until a better authentication mechanism was specified and easy to put into specification because it was already (widely) implemented. Procedure-wise, - the notes of the working group meeting said that it was the consensus that the draft be moved forward as PS - the routing area director questioned that decision - a discussion took place on the mailing list, with (as stated above) some arguing against PS and suggesting BCP because of the vulnerabilities and others arguing for PS to motivate vendors to implement - the working group chair sent it to the IESG requesting PS - two rounds of minor changes to the draft occured - the IESG approved the draft as an RFC at PS and then of course, with an incomplete memory of the outcome of the discussion of Dec/Jan, I brought the whole thing up again. And as a final note, yes, the term "digital signature" is usually reserved in crypto circles to describe a public key technique that exhibits the attribute of "non-repudiation". I have seen the keyed-MD5 technique called "keyed cryptographic hash" and the term "Message Authentication Code" is sometimes used for a symmetric integrity+authentication check. But terminology is not the biggest problem here. I think everyone agrees that the best solution would be to run your TCP session over a suitably protected IPSEC link. The problem is whether IPSEC is available soon enough and enough places. --Sandy From owner-idr@merit.edu Wed Jul 29 10:27:11 1998 Delivery-Date: Wed, 29 Jul 1998 10:27:12 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA06673 for ; Wed, 29 Jul 1998 10:27:11 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id KAA16289 for ; Wed, 29 Jul 1998 10:26:56 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id KAA01380 for idr-outgoing; Wed, 29 Jul 1998 10:05:24 -0400 (EDT) Received: from brookfield.ans.net (brookfield-ef0.brookfield.ans.net [204.148.1.20]) by merit.edu (8.8.7/8.8.5) with ESMTP id KAA01372 for ; Wed, 29 Jul 1998 10:05:18 -0400 (EDT) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.8.8/8.8.8) with ESMTP id KAA22622; Wed, 29 Jul 1998 10:05:05 -0400 (EDT) (envelope-from curtis@brookfield.ans.net) Message-Id: <199807291405.KAA22622@brookfield.ans.net> To: "Luis A. Sanchez" cc: curtis@ans.net, sandy@tis.com, idr@merit.edu, skent@bbn.com Reply-To: curtis@ans.net Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard??? In-reply-to: Your message of "Tue, 28 Jul 1998 16:14:50 -0000." <199807281614.QAA00388@nutmeg.bbn.com> Date: Wed, 29 Jul 1998 10:05:05 -0400 From: Curtis Villamizar Sender: owner-idr@merit.edu Precedence: bulk In message <199807281614.QAA00388@nutmeg.bbn.com>, "Luis A. Sanchez" writes: > > Are there any objections to the content of the draft (holes that need > > to be plugged other than weakness in MD5?). > > - I found eight instances (not counting the title) of the word > "signature" in the document. This should be changed to "Integrity > Check Value (ICV)" or "authenticator" I prefer the latter but both > terms will be appropriate in this context. This strikes me as a wording change but the term authenticator is more accurate. > - There are some residual vulnerabilities in the protocol that i think > should be mentioned. For example, the fact that the keys are > configured manually (since there is no automated key management > facility) implies that these keys will exist for a reasonable amount > of time, certainly longer than a single TCP connection since no-one > will be reconfiguring the keys manually after every route flap, hard > reset or TCP FIN for that matter. THis means that the opportunity > exists for an attacker to replay old traffic that could cause > interesting problems. Of particular interest, would be recorded > traffic carrying hard resets. This traffic would succesfully pass the > ICV validation. The trick is in mapping the sequence numbers, which > could be done. Although it is harder than it used to be. This changes > will affect section 4.1 and will probably require a new section too. You'd also need to match the port pair. Since one end is randomized over the better part of 64k (or at least around 10k for TCP implementations that restrict the range of port values) and the initial sequence number is randomized, the chance of being able to replay is quite small. BTW- BGP sessions do last quite long. Generally months or more. > - One would want to specify key sizes and ranges to be used in > conjuction with MD5. This will allow one to assess the level of > security being offered by this mechanism. Security through obscurity > (intentionally or not) has proven to be the wrong approach. Hence, > section 4.5 needs some more explanation and clarification. OK. > Now, the hard ones: > > - The use of a hash algorithm in this keyed fashion (Keyed-MD5) has > been disparaged in the literature for two years, prompting changes in > the IPsec RFCs; it seems inappropriate to promote the use of this sort > of authentication technology in a newly issued RFC. Personally, i > think we should provide an HMAC with either with the option of using > it with either (MD5 or SHA-1). > > I think that minimum we should modify section 4.4 since it gives the > impression that the collison problem of MD5 is the only problem with > using this option and, that we add a new section comparing the > keyed-MD5 transform used in this protocol versus using an HMAC with > MD5. Vendors who choose to implement this option and customers who > choose to use it will be able to assess the level of security provided > by this feature. > > Luis These seem like reasonable changes. We may need two more TCP option numbers for HMAC with MD5 and HMAC with SHA-1 or one more option and a algorithm type (two bytes is plenty). The TCP option 19 is already in widespread use so we'd need to get another number. The security consideration section could then state that: This document defines a weak but currently practiced security mechanism for BGP using MD5 and a incremental improvement using an HMAC with MD5 or an HMAC with SHA-1. It is anticipated that future work will provide different stronger mechanisms for dealing with these issues. Perhaps the author of the draft should comment rather than me (or someone that knows what they are talking about rather than me :). Curtis ps- for us near crypto illiterates could you point to some consise references that explain HMAC with MD5 and HMAC with SHA-1. From owner-idr@merit.edu Tue Aug 4 22:19:29 1998 Delivery-Date: Tue, 04 Aug 1998 22:19:30 -0400 Return-Path: owner-idr@merit.edu Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA20835 for ; Tue, 4 Aug 1998 22:19:25 -0400 (EDT) Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id WAA13026 for ; Tue, 4 Aug 1998 22:19:06 -0400 (EDT) Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA11147 for idr-outgoing; Tue, 4 Aug 1998 22:03:24 -0400 (EDT) Received: from nutmeg.bbn.com (NUTMEG.bbn.com [128.89.1.112]) by merit.edu (8.8.7/8.8.5) with ESMTP id WAA11143 for ; Tue, 4 Aug 1998 22:03:19 -0400 (EDT) Received: (from lsanchez@localhost) by nutmeg.bbn.com (8.8.7/8.8.7) id VAA00485; Tue, 4 Aug 1998 21:59:59 GMT (envelope-from lsanchez) From: "Luis A. Sanchez" Message-Id: <199808042159.VAA00485@nutmeg.bbn.com> Subject: Re: using the TCP MD5 protection for BGP - Proposed Standard??? In-Reply-To: <199807291405.KAA22622@brookfield.ans.net> from Curtis Villamizar at "Jul 29, 98 10:05:05 am" To: curtis@ans.net Date: Tue, 4 Aug 1998 21:59:59 +0000 (GMT) Cc: idr@merit.edu X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-idr@merit.edu Precedence: bulk > ps- for us near crypto illiterates could you point to some consise > references that explain HMAC with MD5 and HMAC with SHA-1. > try rfc2104 first. It is a concise reference for HMAC (10 pages including sample code). It explains how HMAC operates and how it could be used in conjunction with crypto hash functions such as MD5 and SHA-1. Luis