From rpsec-bounces@ietf.org Sun Apr 02 17:07:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ9mz-0001wS-Mo; Sun, 02 Apr 2006 17:07:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ9my-0001w7-Mw for rpsec@ietf.org; Sun, 02 Apr 2006 17:07:12 -0400 Received: from sequoia.muada.com ([83.149.65.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQ9mx-0002G9-AZ for rpsec@ietf.org; Sun, 02 Apr 2006 17:07:12 -0400 Received: from [82.192.90.27] (alumange.muada.com [82.192.90.27]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id k32L6mCD082704 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 2 Apr 2006 23:06:48 +0200 (CEST) (envelope-from iljitsch@muada.com) In-Reply-To: <200503111545.j2BFj0FA027883@givry.rennes.enst-bretagne.fr> References: <200503111545.j2BFj0FA027883@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <81E92C4D-4173-4EEB-A2C5-68CC25777E1E@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RPSEC] issue: coverage IPv6 Date: Sun, 2 Apr 2006 23:07:04 +0200 To: Francis Dupont X-Mailer: Apple Mail (2.746.3) X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00, ILJQX_SUBJ_NUMINWORD autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org My apologies for replying to a year old message, but if my searches aren't misleading me this issue hasn't been further discussed subsequently, so here goes... On 11-mrt-2005, at 16:45, Francis Dupont wrote: > => there were some proposals for link-local addresses only in > special cases > but IMHO in the context of RPSEC global addresses are required... So > this IPv6 feature (narrow scope addresses) can be ignored and general > considerations for IPv4 apply to IPv6 directly. My understanding of the presence of link local next hop addresses in multiprotocol BGP for IPv6 is that all IPv6 routing protocols are required to exchange link local addresses so that proper redirects can be generated. Redirects for off-link destinations are required to be towards link local addresses as per the IPv6 specs. This probably means that link local next hop addresses in IPv6 multiprotocol BGP can't be ignored for RPSEC purposes. However, since this is a attribute that doesn't propagate across ASes or even routers, this shouldn't be too problematic. I've dabled a bit with modifying these addresses in route maps under IOS and Zebra with various results, but I can't really say to what extent different implementations actually use them in one way or another. Other than the link local next hop address issue and the fact that all the IPv6 stuff is wrapped inside multiprotocol extensions, there aren't any differences between IPv4 and IPv6 routing for unicast in BGP as far as I know. However, things get interesting when IPv6 routes are exchanged over IPv4 transport or the other way around because the next hop address for the non-transport address family may not point to anything valid. In my new book, I recommend that people use separate IPv4 and IPv6 eBGP sessions to carry the respective routes, and I think pretty much everyone does this (although sometimes routes of an unexpected address family propagate unintentionally) but not for iBGP, my view is that it makes more sense to carry both address families over one session here. (No next hop address issues in this case and it saves on additional loopback addresses and redistrution of same in the additional (IPv6) IGP.) I don't know how people generally handle this, though, as the difference isn't visible from the outside. Just 352 messages to go. :-) _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Apr 11 18:50:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRgW-0001Ur-0J; Tue, 11 Apr 2006 18:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRgR-0001UK-UI; Tue, 11 Apr 2006 18:50:03 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTRgQ-0007TN-Mt; Tue, 11 Apr 2006 18:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k3BMo29W007399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Apr 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FTRgP-0007EW-Sq; Tue, 11 Apr 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 11 Apr 2006 18:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: rpsec@ietf.org Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-bgpsecrec-05.txt X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Protocol Security Requirements Working Group of the IETF. Title : BGP Security Requirements Author(s) : B. Christian, T. Tauber Filename : draft-ietf-rpsec-bgpsecrec-05.txt Pages : 18 Date : 2006-4-11 The security of BGP, the Border Gateway Protocol, is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routing system, is more complex. This document describes a set of requirements for securing BGP, including communications between BGP speakers, and the routing information carried within BGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rpsec-bgpsecrec-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rpsec-bgpsecrec-05.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: <2006-4-11151039.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rpsec-bgpsecrec-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rpsec-bgpsecrec-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-11151039.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --NextPart-- From rpsec-bounces@ietf.org Thu Apr 13 12:30:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU4i9-0000Vv-JU; Thu, 13 Apr 2006 12:30:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FU4i7-0000Vq-Ga for rpsec@ietf.org; Thu, 13 Apr 2006 12:30:23 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FU4i6-0002SM-3T for rpsec@ietf.org; Thu, 13 Apr 2006 12:30:23 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k3DGULbd002672 for ; Thu, 13 Apr 2006 09:30:21 -0700 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) with ESMTP id k3DGUL4l002669 for ; Thu, 13 Apr 2006 09:30:21 -0700 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Thu, 13 Apr 2006 09:30:21 -0700 (PDT) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [RPSEC] BGP Sec Requirements 05 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Version 5 of the BGP Security Requirements draft. Has been posted: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-05.txt with different graphical diffs here: http://tools.ietf.org/wg/rpsec/draft-ietf-rpsec-bgpsecrec/draft-ietf-rpsec-bgpsecrec-05-from-04.diff.html and here: http://tools.ietf.org/wg/rpsec/draft-ietf-rpsec-bgpsecrec/draft-ietf-rpsec-bgpsecrec-05-from-04.wdiff.html The changes include many editorial comments received as well as the addition, in Sec 6., Paragraph 2, of text indicating the items related to AS_PATH for which we don't have consensus. Please provide feedback by April 21. I'd like to put this one to bed if possible. Thanks, Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Apr 19 13:43:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWGhv-0002aU-3r; Wed, 19 Apr 2006 13:43:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWGfW-0001wd-4I for rpsec@ietf.org; Wed, 19 Apr 2006 13:40:46 -0400 Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWGTK-0005jP-1G for rpsec@ietf.org; Wed, 19 Apr 2006 13:28:10 -0400 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060308/8.12.11) with ESMTP id k3JHS6t8024409; Wed, 19 Apr 2006 20:28:06 +0300 Date: Wed, 19 Apr 2006 20:28:06 +0300 (EEST) From: Pekka Savola To: saag@mit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.1/1407/Wed Apr 19 00:01:55 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on otso.netcore.fi X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: rpsec@ietf.org Subject: [RPSEC] Backbone attacks and protections (fwd) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Hi, As there was some discussion of TCP-MD5 and revisions at the last SAAG meeting, I claimed on jabber that getting a TCP-MD5 replacement is not really such a critical thing, as TCP-MD5 itself has rather limited applicability (and attack vector). I also promised to write an I-D. Well, here's a short I-D which gives an overview of my operator perspective (inputs from a couple of others have been incorporated) of main threats to backbone routers and their routing protocols in particular. Now would be a good time to read and comment, because I'm going to revise the doc in 2-3 weeks. I suggest directing followups to either: 1) rtgwg list (rtgwg@ietf.org) 2) saag list only 3) myself only ---------- Forwarded message ---------- Date: Fri, 31 Mar 2006 23:27:29 +0300 (EEST) From: Pekka Savola To: rtgwg@ietf.org Subject: Backbone attacks and protections (was: TCP-RST and GTSM) Hi, At IETF65, I raised the TCP-RST attack issue in GTSM, and Alex asked that I should talk with DaveM about it, work it out, and produce a draft. Well, I did.. and soon figured out I'll need to write a more generic but concise draft first on what I believe are the main attack vectors against routing protocols running on backbone networks today, so that we can balance the risks. Feedback is appreciated -- read it, it's only about 10 pages. I'll also send a pointer to RPsec and SAAG a bit later, because there has been some discussion on TCP-MD5 replacements there. http://www.ietf.org/internet-drafts/draft-savola-rtgwg-backbone-attacks-00.txt Abstract A number of protection mechanisms for attacks against service provider backbone network infrastructure have been specified or proposed, each of them usually targeting a subset of the problem space. There has never been a more generic analysis of the actual problems, and which protection techniques are even necessary (and where). This document tries to provide that higher-level view. ... Oh, if you're interested, below is what I suggest we do with GTSM (though I'm very much open to discussion about this -- the attack loses most of its usefulness especially if the router already implements the draft-ietf-tcpm-tcpsecure hack..): The open issue at the moment is how GTSM handles TCP RSTs. I.e., should it require that RSTs for a GTSM-enabled session should be sent with TTL=255 and verified to come with TTL=255 (or a configured value)? Do implementations already do this? Is there a sensible transition plan or need to make a change if any? Note that this has only limited impact on GTSM's security as other TCP RST mitigation techniques still apply. We suggest that the GTSM spec is amended that TCP RSTs relating to to a GTSM-enabled protocol port MUST be sent with TTL=255. (Note that this will require a kernel modification, and a means to specify to the kernel which ports relate to GTSM.). The recipients behaviour SHOULD be configurable, and it is RECOMMENDED that the default be to discard messages where TTL is not 255 (or 255-TrustRadius). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Rtgwg mailing list Rtgwg@ietf.org https://www1.ietf.org/mailman/listinfo/rtgwg _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec