From mailnull@www1.ietf.org Thu Apr 3 06:39:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14720 for ; Thu, 3 Apr 2003 06:39:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33BfR704757 for rpsec-archive@odin.ietf.org; Thu, 3 Apr 2003 06:41:27 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33BfRK04754 for ; Thu, 3 Apr 2003 06:41:27 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14712 for ; Thu, 3 Apr 2003 06:38:42 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33BeGK04709; Thu, 3 Apr 2003 06:40:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33BdZK04640 for ; Thu, 3 Apr 2003 06:39:35 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14600; Thu, 3 Apr 2003 06:36:51 -0500 (EST) Message-Id: <200304031136.GAA14600@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: rpsec@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Apr 2003 06:36:51 -0500 Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-routing-threats-00.txt Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , --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 : Generic Threats to Routing Protocols Author(s) : D. Beard, S. Murphy, Y. Yang Filename : draft-ietf-rpsec-routing-threats-00.txt Pages : 34 Date : 2003-4-2 Routing protocols are subject to attacks that can harm individual users or the network operations as a whole. The lack of a common set of security requirements has led to the use in existing routing protocol of a variety of different security solutions, which provide various levels of security coverage. The RPSEC working group intends to deliver in a separate document a set of security requirements for consideration of routing protocol designers. The first step in developing the security requirements is to analyze the threats that face routing protocols. This document describes the threats, including threat sources and capabilities, threat actions, and threat consequences as well as a breakdown of routing functions that might be separately attacked. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rpsec-routing-threats-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rpsec-routing-threats-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: <2003-4-2123642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rpsec-routing-threats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rpsec-routing-threats-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-4-2123642.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 3 09:34:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21286 for ; Thu, 3 Apr 2003 09:34:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33Eatj19034 for rpsec-archive@odin.ietf.org; Thu, 3 Apr 2003 09:36:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33EatK19031 for ; Thu, 3 Apr 2003 09:36:55 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21280 for ; Thu, 3 Apr 2003 09:34:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33EZsK18924; Thu, 3 Apr 2003 09:35:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33EYcK18817 for ; Thu, 3 Apr 2003 09:34:38 -0500 Received: from mesa.bbnplanet.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21191 for ; Thu, 3 Apr 2003 09:31:48 -0500 (EST) Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h33EYG619357 for ; Thu, 3 Apr 2003 09:34:16 -0500 (EST) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Thu, 3 Apr 2003 09:34:16 -0500 (EST) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: rpsec@ietf.org Subject: Re: [RPSEC] I-D ACTION:draft-ietf-rpsec-routing-threats-00.txt In-Reply-To: <200304031136.GAA14600@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , To clarify, this document is the same as draft-beard-rpsec-routing-threats-01.txt but has been re-submitted with the requisite name change as a WG item. A revised draft ought to be published in the not too distant future. We've also updated the WG milestones to reflect our having accomplished this first one as well as our realistic expectations for the schedule of upcoming work. Tony On Thu, 3 Apr 2003 Internet-Drafts@ietf.org wrote: > 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 : Generic Threats to Routing Protocols > Author(s) : D. Beard, S. Murphy, Y. Yang > Filename : draft-ietf-rpsec-routing-threats-00.txt > Pages : 34 > Date : 2003-4-2 _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 3 14:46:38 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08851 for ; Thu, 3 Apr 2003 14:46:38 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h33Jn1q21830 for rpsec-archive@odin.ietf.org; Thu, 3 Apr 2003 14:49:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33Jn1K21827 for ; Thu, 3 Apr 2003 14:49:01 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08840 for ; Thu, 3 Apr 2003 14:46:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33JlHK21583; Thu, 3 Apr 2003 14:47:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h33Jk5K21502 for ; Thu, 3 Apr 2003 14:46:05 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08759 for ; Thu, 3 Apr 2003 14:42:54 -0500 (EST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h33JjN5w006767 for ; Thu, 3 Apr 2003 14:45:23 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Thu, 3 Apr 2003 14:43:12 -0500 To: From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [RPSEC] an anti-flooding mechanism for consideration Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Folks, At the last RPSEC meeting, a major topic of interest was how to quickly determine if purported management (vs. subscriber) traffic directed to a router was from an authorized source. The traffic of interest includes BGP traffic sent between peers, SNMP traffic between a management station and a router, etc. The goal of the discussion was to find a simple mechanism that allows a router to make a quick determination, probably on a line card, if a packet represents legitimate management traffic, so as to be able to reject bogus traffic that might overwhelm the router's management processor. Ideally, candidate mechanisms should be resistant to man-in-the-middle attacks, however there also was interest in mechanisms that would not provide protection in this worst cast context. One approach to addressing this problem occurred to me after the meeting. It is based on the use of hash chains, the technique that underlies one-time password schemes like S/Key. For this environment the technique could be used as described below. I'll describe the management station to router case; the inter-router case, which is easier in most respects, is left as an exercise ... - Each authorized source of management traffic, identified by source address, generates a hash chain. The chain is generated by selecting a random number as a seed, then applying a one-way hash function to the seed, and then to the result of that application, iteratively. The number of iterations represents the length of the chain, which translates into the number of messages that can be sent before the chain must be re-established. - Using an authentic, integrity-secure channel to the router, (e.g., an SSL connection, a protected SNMP transaction, or a local configuration port), the final value of the hash chain and its length is communicated to the router that is the target of the management traffic.(For the peer router case, one might accept a simpler, less secure initialization mechanism, under some circumstances.) This procedure initializes the hash chain "channel." The router also needs to be configured with a window that represents how much out of order management packets can arrive and still be accepted. More on this below. - Once the channel has been established, the management station can send traffic to the router by tagging it with the current hash chain value and its ordinal position in the chain. If the chain is of length N, the first transmitted value is N-1, then N-2, etc. A management station must use a separate seed for each chain and maintain a separate counter for each device it manages. The station could recompute each hash chain as it progresses, but pre-computation and storage of selected, intermediate chain values would make generation of each tag faster and of constant duration. - A management packet would carry the tag (consisting of the chain value and counter value that it represents), which could be checked by the target router very quickly. The router would maintain a small array of recently received tags, on a per-sender basis, for each authorized sender. The array is needed to allow for out of order arrival, while still rejecting duplicates. The size of the array is a local configuration parameter. The computation is quite fast, since only one or a few (a function of the window size) iterations of the hash function need to be performed, and since the hash function is applied only to the hash value in the tag, not to the whole packet. - The tag is not bound to the packet, so it is not a substitute for a secure end-to-end integrity mechanism. However, the problem we are trying to solve is that of quickly rejecting bogus management packets. An MITM attacker can substitute a bogus packet for a legitimate one, but he can do so only at the rate at which legitimate packets are sent by an authorized sender. Thus, for purposes of fast rejection, the lack of binding to the packet does not seem to be a problem. - If the checking is performed on line cards, then it may not be feasible to maintain synch among multiple cards re the receive windows, or the synch may be imperfect. (This assumes that the same authorized management traffic peer might legitimately send traffic that would arrive via any external interface. For the simpler case of a peer router sending IS-IS, OSPF, or BGP traffic, this is not an issue.) - A residual vulnerability arises in that one might accept as valid a packet that was already accepted via another interface, serviced via a different line card. This is not ideal, but if we eventually synch across cards, the window of vulnerability can be limited, and in any case the replay vulnerability is proportional to the number of non-synched interfaces on a router and the size of the window allowed for each authorized management peer, and the number of such peers. - One open question is where to put the tag. To maximize generality, one might use an IP option (or extension header in v6), since that would allow its use with any higher layer protocol. Is this viable from the perspective of network operators and router vendors, or do we need to find somewhere else to carry the tag? Comments? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 3 20:18:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21972 for ; Thu, 3 Apr 2003 20:18:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h341Kkd17961 for rpsec-archive@odin.ietf.org; Thu, 3 Apr 2003 20:20:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h341KkK17958 for ; Thu, 3 Apr 2003 20:20:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21969 for ; Thu, 3 Apr 2003 20:17:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h341JSK17896; Thu, 3 Apr 2003 20:19:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h341IqK17868 for ; Thu, 3 Apr 2003 20:18:52 -0500 Received: from kc-msxproto2.kc.umkc.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21949 for ; Thu, 3 Apr 2003 20:15:50 -0500 (EST) Received: from KC-MAIL4.kc.umkc.edu ([134.193.143.211] RDNS failed) by kc-msxproto2.kc.umkc.edu with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Apr 2003 19:18:19 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [RPSEC] an anti-flooding mechanism for consideration Date: Thu, 3 Apr 2003 19:18:18 -0600 Message-ID: <5EF7D95E17BDAD4A968C812E5ABC390B02D070@KC-MAIL4.kc.umkc.edu> Thread-Topic: [RPSEC] an anti-flooding mechanism for consideration Thread-Index: AcL6GdwE8YxTkFlWQQCX9w5S5iat8AALMM/w From: "Ayyasamy, Senthilkumar (UMKC-Student)" To: "Stephen Kent" , X-OriginalArrivalTime: 04 Apr 2003 01:18:19.0365 (UTC) FILETIME=[13A03150:01C2FA48] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h341IqK17869 Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > At the last RPSEC meeting, a major topic of interest was how to > quickly determine if purported management (vs. subscriber) traffic > directed to a router was from an authorized source. The traffic of > interest includes BGP traffic sent between peers, SNMP traffic > between a management station and a router, etc. The goal of the > discussion was to find a simple mechanism that allows a router to > make a quick determination, probably on a line card, if a packet > represents legitimate management traffic, so as to be able to reject > bogus traffic that might overwhelm the router's management processor. > > Ideally, candidate mechanisms should be resistant to > man-in-the-middle attacks, however there also was interest in > mechanisms that would not provide protection in this worst cast > context. > > One approach to addressing this problem occurred to me after the > meeting. one more important issue seems to be verifying whether the sucessive information comes from the same authorized source. bradner-pbk-frame seems to propose a solution to the problem. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 4 08:44:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21706 for ; Fri, 4 Apr 2003 08:44:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h34DkkI16754 for rpsec-archive@odin.ietf.org; Fri, 4 Apr 2003 08:46:46 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DkkK16751 for ; Fri, 4 Apr 2003 08:46:46 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21698 for ; Fri, 4 Apr 2003 08:43:29 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DhqK16571; Fri, 4 Apr 2003 08:43:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h34DeQK16470 for ; Fri, 4 Apr 2003 08:40:26 -0500 Received: from aragorn.bbn.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21523 for ; Fri, 4 Apr 2003 08:37:09 -0500 (EST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h34DdU62018999; Fri, 4 Apr 2003 08:39:38 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390B02D070@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390B02D070@KC-MAIL4.kc.umkc.edu> Date: Fri, 4 Apr 2003 08:37:11 -0500 To: "Ayyasamy, Senthilkumar (UMKC-Student)" From: Stephen Kent Subject: RE: [RPSEC] an anti-flooding mechanism for consideration Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 7:18 PM -0600 4/3/03, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > > At the last RPSEC meeting, a major topic of interest was how to >> quickly determine if purported management (vs. subscriber) traffic >> directed to a router was from an authorized source. The traffic of >> interest includes BGP traffic sent between peers, SNMP traffic >> between a management station and a router, etc. The goal of the >> discussion was to find a simple mechanism that allows a router to >> make a quick determination, probably on a line card, if a packet >> represents legitimate management traffic, so as to be able to reject >> bogus traffic that might overwhelm the router's management processor. >> >> Ideally, candidate mechanisms should be resistant to >> man-in-the-middle attacks, however there also was interest in >> mechanisms that would not provide protection in this worst cast >> context. >> >> One approach to addressing this problem occurred to me after the >> meeting. > >one more important issue seems to be verifying whether the sucessive >information comes from the same authorized source. bradner-pbk-frame >seems to propose a solution to the problem. The mechanism I describe has the property you note, since the hash chains are per source/dest pair. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Mon Apr 7 15:29:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03172 for ; Mon, 7 Apr 2003 15:29:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h37JXn005573 for rpsec-archive@odin.ietf.org; Mon, 7 Apr 2003 15:33:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37JXn805570 for ; Mon, 7 Apr 2003 15:33:49 -0400 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03100 for ; Mon, 7 Apr 2003 15:28:56 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37JWZ805502; Mon, 7 Apr 2003 15:32:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h37JVu805476 for ; Mon, 7 Apr 2003 15:31:56 -0400 Received: from mail1.netscreen.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03051 for ; Mon, 7 Apr 2003 15:27:03 -0400 (EDT) Received: from ns-ca.netscreen.com (ns-ca-local [10.100.3.35]) by mail1.netscreen.com (Switch-2.2.5/Switch-2.2.5) with ESMTP id h37JP4W23679 for ; Mon, 7 Apr 2003 12:25:04 -0700 (PDT) Received: by NS-CA.netscreen.com with Internet Mail Service (5.5.2653.19) id <2HMSH77V>; Mon, 7 Apr 2003 12:26:23 -0700 Message-ID: <541402FFDC56DA499E7E13329ABFEA87E66BBD@SARATOGA.netscreen.com> From: Gregory Lebovitz To: RPSEC@ietf.org Date: Mon, 7 Apr 2003 12:24:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [RPSEC] Threat model slides from SF? Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , It appears Alex' slides from IETF56 made it to the "proceedings" page, but not the Threat Model slides that Sandy presented. Can we get Sandy's slides posted? !! NETSCREEN HAS MOVED !! New Contact Info: 408.543.8002 805 11th Ave, Bldg 3 Sunnyvale, CA 94089 +*******************++********************+ Gregory M. Lebovitz Staff Architect, CTO Office NetScreen Technologies, Inc. Ph: 408.543.8002 E: gregory@netscreen.com Pg: page.gregory@netscreen.com NASDAQ: NSCN +*******************++********************+ _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 10 16:42:21 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06079 for ; Thu, 10 Apr 2003 16:42:21 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3AKmBX12434 for rpsec-archive@odin.ietf.org; Thu, 10 Apr 2003 16:48:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AKmB812431 for ; Thu, 10 Apr 2003 16:48:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06043 for ; Thu, 10 Apr 2003 16:41:51 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193ibg-0004G6-00 for rpsec-web-archive@ietf.org; Thu, 10 Apr 2003 16:25:12 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 193ibf-0004G3-00 for rpsec-web-archive@ietf.org; Thu, 10 Apr 2003 16:25:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AKji812189; Thu, 10 Apr 2003 16:45:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3AKiK812119 for ; Thu, 10 Apr 2003 16:44:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05918 for ; Thu, 10 Apr 2003 16:38:00 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 193iXx-0004EL-00 for RPSEC@ietf.org; Thu, 10 Apr 2003 16:21:21 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 193iXx-0004Dl-00 for RPSEC@ietf.org; Thu, 10 Apr 2003 16:21:21 -0400 Received: from [10.5.63.187] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3AKe25w006075; Thu, 10 Apr 2003 16:40:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@127.0.0.1 Message-Id: In-Reply-To: <5EF7D95E17BDAD4A968C812E5ABC390BAA7524@KC-MAIL4.kc.umkc.edu> References: <5EF7D95E17BDAD4A968C812E5ABC390BAA7524@KC-MAIL4.kc.umkc.edu> Date: Thu, 10 Apr 2003 16:37:49 -0400 To: "Ayyasamy, Senthilkumar (UMKC-Student)" From: Stephen Kent Subject: RE: [RPSEC] an anti-flooding mechanism for consideration Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 5:20 PM -0600 4/4/03, Ayyasamy, Senthilkumar (UMKC-Student) wrote: > > The mechanism I describe has the property you note, since the hash >> chains are per source/dest pair. > >Yes. I noticed them, only after senting the reply.... But, bradner's >draft also seems to provide one way of doing. I had forgotten about Scott's PBK I-D, but your message caused me to reread it. It has almost nothing in common with what I discussed in my message. PBKs are public key pairs dynamically created and bound to entities in dynamic challenge-response exchanges. I saw no mechanism in the PBK draft that would qualify as fast-to-compute authentication mechanism, which was the purpose of the mechanism I described. So, could you explain how you think the PBK notion relates to the problem discussed at the last RPSEC meeting, and to the features of the solution I offered in my message? The linkage is not at all clear to me. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 17 16:45:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07053 for ; Thu, 17 Apr 2003 16:45:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HKsIu06991 for rpsec-archive@odin.ietf.org; Thu, 17 Apr 2003 16:54:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HKsI806988 for ; Thu, 17 Apr 2003 16:54:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07046 for ; Thu, 17 Apr 2003 16:44:32 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196GHb-0002W8-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 16:46:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196GHa-0002W4-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 16:46:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HKpO806873; Thu, 17 Apr 2003 16:51:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HKoU806815 for ; Thu, 17 Apr 2003 16:50:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06924 for ; Thu, 17 Apr 2003 16:40:43 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196GDu-0002UA-00 for rpsec@ietf.org; Thu, 17 Apr 2003 16:43:10 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196GDu-0002Ts-00 for rpsec@ietf.org; Thu, 17 Apr 2003 16:43:10 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3HKgr5w003304 for ; Thu, 17 Apr 2003 16:42:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Thu, 17 Apr 2003 16:40:45 -0400 To: rpsec@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [RPSEC] rate limiting management traffic, redux Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Undeterred by the overwhelming response to my last posting on this topic, I've thought some more about it and have a simpler technique to propose. Recall that the problem being addressed (which was the topic of two presentations at the last RPSEC WG meeting) is how to quickly determine if purported management (vs. subscriber) traffic directed to a router is from an authorized source. The traffic of interest includes BGP traffic sent between peers, SNMP traffic between a management station and a router, etc. The goal is to find a simple mechanism that allows a router to make a quick determination, probably on an interface card, if a packet represents legitimate management traffic, so as to be able to reject bogus traffic that might overwhelm the router's management processor. Ideally, candidate mechanisms should be resistant to man-in-the-middle attacks, however there also was interest in mechanisms that would not provide protection in this worst cast context. My new suggestion in this area requires a shared secret (key) between the router and the entity sending the management traffic, either another router or a management workstation. The key is one of two inputs to a one-way function; the other input will be a sequence number which will be carried with the packet. The one-way function transforms the key and sequence number into an output that should be big enough to preclude effective guessing attacks. The one-way function is required to prevent a passive wiretapper from being able to work backwards from the output and the sequence number (which is visible in each packet) to determine the key. The key must be changed before the sequence number cycles, to prevent replay attacks. The mechanism is quite simple. Each authorized sender of management traffic is identified by its IP address. Associated with each sender is a secret (key) that must be shared with the managed device, e.g., a router. The sender of the management traffic maintains a packet counter which is initialized to 0 and is incremented for each transmitted packet. Before transmitting the packet, the sender creates the authentication tag by applying a one-way function to the key and the sequence number. Both the sequence number and the tag are carried in the packet. A managed device such as a router maintains a separate key for each entity that is authorized to send management traffic to the device. For each authorized sender, the managed device maintains the following information: - the address of the sender - the shared secret - a receive window consisting of the sequence number for the most recent, valid management packet from the sender, a sequence number indicating the edge for "too old" packets, plus a bit map marking received , valid packets within the window. This is the same mechanism used by IPsec to reject replays while allowing out of order arrival. This data is maintained on each interface card via which management packets from the sender may be received. So, for example, if the sender is a neighbor router (for BGP traffic) only one interface will hold the data for that sender. If the sender is a management station from which traffic might be received multiple interfaces, then every appropriate interface would maintain this data for that sender. In this later case there is a synchronization issue, since the window would be updated locally on each interface where such packets are received. I think it would suffice to periodically update the window data in a loose fashion for these senders, since the vulnerability that arises from imperfect sync is not very great, as explained below. Upon receipt of a packet addressed to the router, the interface checks for the presence of the sequence number and authentication tag. If absent, the packet is discarded. If present, the sequence number is matched against the receive window for the indicated sender. If the sequence number labels the packet as too old, or if it matches a flag in the window indicating that it is a duplicate, the packet is discarded. If the packet sequence number suggests that the packet would be acceptable if it is authentic, the tag is checked. The check is simple, i.e., the key for the indicate sender is used to generate a tag based on the sequence number in the packet. If the locally generated tag matches the one in the packet, the packet is forwarded to the management processor and the window is updated, otherwise the packet is discarded. This simple mechanism rate limits management traffic that is forwarded to the router's management processor. Because of the one-way property of the function, an attacker should have a low probability of generating a legitimate sequence number-tag pair, proportional to the size of the tag and assuming a suitably large and random key. Since the authentication tag is not bound to the packet, a MITM attack could strip a tag from a legitimate packet and attach it to a bogus packet, but he cannot do so at a rate greater than an authorized sender sends legitimate management packets. A residual vulnerability arises in that a router might accept as valid a packet that was already accepted via another interface, serviced via a different line card, prior to a resync. This is not ideal, but if we periodically synch across cards, the window of vulnerability is limited, and in any case the replay vulnerability is proportional to the number of non-synched interfaces on a router and the size of the window allowed for each sender who is authorized to send to multiple interfaces. In general I expect this would be a small number. There are a few open issues: - where to carry the sequence number and tag - how big is the sequence number and how big is the tag - how big is the key - what one-way function to use Comments? Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 17 16:56:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07727 for ; Thu, 17 Apr 2003 16:56:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HL5gF07985 for rpsec-archive@odin.ietf.org; Thu, 17 Apr 2003 17:05:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HL5g807982 for ; Thu, 17 Apr 2003 17:05:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07706 for ; Thu, 17 Apr 2003 16:55:54 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196GSc-0002dj-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 16:58:22 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196GSb-0002dg-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 16:58:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HL53807965; Thu, 17 Apr 2003 17:05:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HL4p807944 for ; Thu, 17 Apr 2003 17:04:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07671 for ; Thu, 17 Apr 2003 16:55:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196GRn-0002dZ-00 for rpsec@ietf.org; Thu, 17 Apr 2003 16:57:31 -0400 Received: from aardvark.icir.org ([192.150.187.20]) by ietf-mx with esmtp (Exim 4.12) id 196GRm-0002dW-00 for rpsec@ietf.org; Thu, 17 Apr 2003 16:57:31 -0400 Received: from aardvark.icir.org (localhost [127.0.0.1]) by aardvark.icir.org (8.12.8p1/8.12.3) with ESMTP id h3HKvWY3047122; Thu, 17 Apr 2003 13:57:32 -0700 (PDT) (envelope-from mjh@aardvark.icir.org) From: Mark Handley X-Organisation: ICIR To: Stephen Kent cc: rpsec@ietf.org Subject: Re: [RPSEC] rate limiting management traffic, redux In-reply-to: Your message of "Thu, 17 Apr 2003 16:40:45 EDT." Date: Thu, 17 Apr 2003 13:57:32 -0700 Message-ID: <47121.1050613052@aardvark.icir.org> Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , >There are a few open issues: > - where to carry the sequence number and tag > - how big is the sequence number and how big is the tag > - how big is the key > - what one-way function to use > >Comments? What do you do about sequence number re-initialization? If this is being used to protect routing traffic, and a router restarts, do you require stable storage to preserve the previous sequence numbers? - Mark _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 17 17:28:28 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08867 for ; Thu, 17 Apr 2003 17:28:28 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HLbkf11145 for rpsec-archive@odin.ietf.org; Thu, 17 Apr 2003 17:37:46 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLbk811142 for ; Thu, 17 Apr 2003 17:37:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08847 for ; Thu, 17 Apr 2003 17:27:58 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Gxd-0002tB-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 17:30:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196Gxd-0002t8-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 17:30:25 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLbB810568; Thu, 17 Apr 2003 17:37:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLZU810110 for ; Thu, 17 Apr 2003 17:35:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08772 for ; Thu, 17 Apr 2003 17:25:42 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196GvR-0002rg-00 for rpsec@ietf.org; Thu, 17 Apr 2003 17:28:09 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196GvR-0002rR-00 for rpsec@ietf.org; Thu, 17 Apr 2003 17:28:09 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3HLRp5w005954; Thu, 17 Apr 2003 17:27:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <47121.1050613052@aardvark.icir.org> References: <47121.1050613052@aardvark.icir.org> Date: Thu, 17 Apr 2003 17:28:14 -0400 To: Mark Handley From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 1:57 PM -0700 4/17/03, Mark Handley wrote: > >There are a few open issues: >> - where to carry the sequence number and tag >> - how big is the sequence number and how big is the tag >> - how big is the key >> - what one-way function to use >> >>Comments? > >What do you do about sequence number re-initialization? If this is >being used to protect routing traffic, and a router restarts, do you >require stable storage to preserve the previous sequence numbers? > > - Mark Mark, Good question. At a minimum, stable storage is needed for the keys, but they change slowly, so maintaining that ought not be too hard. It would be harder for the per-sender window data to be saved, so we ought to have a plan for re-initialization. A likely approach is to have the router that crashed initiate a connection to each authorized management entity to reinitialize, e.g., putting a new key in place and resetting the sequence number to zero. In the re-initialization process, the router would engage in a handshake with the management entities, using a nonce to ensure freshness, and because the router initiated the handshake, it can at least be protected against an attacker without access to the packets it sends as part of the re-initialization process. We may be able to be clever here too. For example, we could take the nonce generated by the router and use it as an input to generate the new key from the old key, so that the router and the management entity can very quickly transition to the new key and resume secure communication. I'll have to work out the details, but I think it's feasible with a quick UDP exchange. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 17 17:51:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09704 for ; Thu, 17 Apr 2003 17:51:13 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HM0V812303 for rpsec-archive@odin.ietf.org; Thu, 17 Apr 2003 18:00:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HM0V812300 for ; Thu, 17 Apr 2003 18:00:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09664 for ; Thu, 17 Apr 2003 17:50:42 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HJe-00032E-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 17:53:10 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196HJd-00032B-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 17:53:09 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HM09812279; Thu, 17 Apr 2003 18:00:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HLxV812204 for ; Thu, 17 Apr 2003 17:59:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09643 for ; Thu, 17 Apr 2003 17:49:43 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HIh-00031n-00 for rpsec@ietf.org; Thu, 17 Apr 2003 17:52:11 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=sentry.rv.nailabs.com ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 196HIg-00031k-00 for rpsec@ietf.org; Thu, 17 Apr 2003 17:52:10 -0400 Received: by sentry.rv.nailabs.com; id RAA04059; Thu, 17 Apr 2003 17:53:28 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma004031; Thu, 17 Apr 03 17:52:58 -0400 Received: (from sandy@localhost) by raven.rv.nailabs.com (8.11.6/8.11.6) id h3HLprW05182; Thu, 17 Apr 2003 17:51:53 -0400 (EDT) Date: Thu, 17 Apr 2003 17:51:53 -0400 (EDT) Message-Id: <200304172151.h3HLprW05182@raven.rv.nailabs.com> From: sandy@raven.gw.tislabs.com To: kent@bbn.com, rpsec@ietf.org Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: sandy@nailabs.com Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , >Recall that the problem being addressed (which was the topic of two >presentations at the last RPSEC WG meeting) is how to quickly >determine if purported management (vs. subscriber) traffic directed >to a router is from an authorized source. Now, first, I must admit that I had been meaning to read over the previous exchanges carefully, so I might have missed a subtle shift in the discussion, so what I say here might have been overtaken by events. I thought that the presentations in the IETF meetings were devoted to this problem with a bit of an addition ".... and no crypto techniques run fast enough to solve this with authentication. In fact, using crypto makes the problem worse." Given that comments on the list have been claiming that TCP MD5 is not useful in preventing the DoS attacks against the BGP port because it just makes the router processor work harder for each packet, I'm not sure that a crypto-focused proposal would win over those proposing the TTL=255 approach. If the benefit is that it is the interface card that is doing the crypto, not the router processor, would moving the TCP MD5 processing to the interface card provide the same benefits as your technique? (OK, so TCP MD5 doesn't have sequence numbers, and this technique does, but off-loading wise.) Or perhaps the advantage of this approach is that the amount of data processed by the one-way function is very small, resulting in increased speed? --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 17 17:59:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09955 for ; Thu, 17 Apr 2003 17:59:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HM8T313526 for rpsec-archive@odin.ietf.org; Thu, 17 Apr 2003 18:08:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HM8T813523 for ; Thu, 17 Apr 2003 18:08:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09938 for ; Thu, 17 Apr 2003 17:58:40 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HRM-00034p-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 18:01:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196HRL-00034m-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 18:01:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HM86813493; Thu, 17 Apr 2003 18:08:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HM7J813060 for ; Thu, 17 Apr 2003 18:07:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09914 for ; Thu, 17 Apr 2003 17:57:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HQC-000349-00 for rpsec@ietf.org; Thu, 17 Apr 2003 17:59:56 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 196HQC-000346-00 for rpsec@ietf.org; Thu, 17 Apr 2003 17:59:56 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3HM0BE65213; Fri, 18 Apr 2003 00:00:11 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 18 Apr 2003 00:00:02 +0200 Subject: Re: [RPSEC] rate limiting management traffic, redux Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rpsec@ietf.org To: Stephen Kent From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On donderdag, apr 17, 2003, at 22:40 Europe/Amsterdam, Stephen Kent wrote: > My new suggestion in this area requires a shared secret (key) between > the router and the entity sending the management traffic, either > another router or a management workstation. The key is one of two > inputs to a one-way function; the other input will be a sequence > number which will be carried with the packet. This is similar to something I proposed about a month ago: "Ok, how about this: we use a stream cipher to come up with a random-looking data stream on both ends and use the IPsec anti-replay counter as a pointer to the part of the data stream that is used as a magic cookie in the current packet. We can then program the line card with enough data to be able to check a certain number of packets per session" > A managed device such as a router maintains a separate key for each > entity that is authorized to send management traffic to the device. > For each authorized sender, the managed device maintains the following > information: > - the address of the sender > - the shared secret This means the crypto is done on the cards. Doing this beforehand elsewhere and then simply upload the results to the linecard is probably a better idea. A linecard with crypto hardware could of course do this on the fly but if we have such a linecard why not simply do IPsec AH? > - a receive window consisting of the sequence number for the most > recent, valid management packet from the sender, a sequence number > indicating the edge for "too old" packets, plus a bit map marking > received , valid packets within the window. I'm not sure requiring this bitmap is a good idea, as id adds complexity (that may need to be burnt into silicon). > There are a few open issues: > - where to carry the sequence number and tag If we're doing IPsec, we already have the anti-replay counter that I think can easily do double duty here. For the tag we either have to create a completely new option or extend IPsec. Alternatively, the tag can be used as (part of) the IV for ESP processing. > - how big is the sequence number and how big is the tag The sequence number wraps all the time so 16 bits should be adequate or maybe 32 bits. As a typical window would be something like 64 packets, with a 32 bit tag an attacker has a one in 500 million chance of guessing a valid tag. A 10 Gbit link can carry several million packets per second so the attack would hit paydirt in a matter of minutes with 32 bits. So I'd say at least 48 bits. > - how big is the key > - what one-way function to use This is something the crypto experts should answer. I suspect that doing a one-way function over some static data and a sequence number doesn't provide enough entropy from one packet to the next to be secure, even for this purpose. My non-expert guess is that a stream cipher with the sequence number as a pointer to the stream would be better. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 17 18:06:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10564 for ; Thu, 17 Apr 2003 18:06:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HMFTV14012 for rpsec-archive@odin.ietf.org; Thu, 17 Apr 2003 18:15:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMFT814007 for ; Thu, 17 Apr 2003 18:15:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10456 for ; Thu, 17 Apr 2003 18:05:40 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HY8-00038W-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 18:08:08 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196HY7-00038T-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 18:08:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMF4813935; Thu, 17 Apr 2003 18:15:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMCa813730 for ; Thu, 17 Apr 2003 18:12:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10149 for ; Thu, 17 Apr 2003 18:02:47 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HVL-00037B-00 for rpsec@ietf.org; Thu, 17 Apr 2003 18:05:15 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196HVK-00036m-00 for rpsec@ietf.org; Thu, 17 Apr 2003 18:05:14 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3HM4c60008000; Thu, 17 Apr 2003 18:04:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200304172151.h3HLprW05182@raven.rv.nailabs.com> References: <200304172151.h3HLprW05182@raven.rv.nailabs.com> Date: Thu, 17 Apr 2003 18:05:54 -0400 To: sandy@raven.gw.tislabs.com From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org, sandy@nailabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 5:51 PM -0400 4/17/03, sandy@raven.gw.tislabs.com wrote: > >Recall that the problem being addressed (which was the topic of two >>presentations at the last RPSEC WG meeting) is how to quickly >>determine if purported management (vs. subscriber) traffic directed >>to a router is from an authorized source. > >Now, first, I must admit that I had been meaning to read over the >previous exchanges carefully, so I might have missed a subtle shift >in the discussion, so what I say here might have been overtaken by events. > >I thought that the presentations in the IETF meetings were devoted >to this problem with a bit of an addition ".... and no crypto techniques >run fast enough to solve this with authentication. In fact, using >crypto makes the problem worse." Given that comments on the list have >been claiming that TCP MD5 is not useful in preventing the DoS attacks >against the BGP port because it just makes the router processor work >harder for each packet, I'm not sure that a crypto-focused proposal >would win over those proposing the TTL=255 approach. > >If the benefit is that it is the interface card that is doing the crypto, >not the router processor, would moving the TCP MD5 processing to the >interface card provide the same benefits as your technique? (OK, so >TCP MD5 doesn't have sequence numbers, and this technique does, but >off-loading wise.) Or perhaps the advantage of this approach is that the >amount of data processed by the one-way function is very small, resulting >in increased speed? > >--Sandy I think it would be wrong to maintain that "no crypto techniques run fast enough" since we have some pretty fast, simple techniques that have become available over time. Note that we don't need a MAC or hash function for this purpose. A simple stream cipher would probably suffice. Moving MD5 to the interface card would address the current problem for BGP neighbor traffic, but since it is a TCP-level mechanism, it would entail moving a lot more mechanism to the card than just the crypto check. However, the TTL=255 trick is certainly tough to beat :-) in terms of performance, and it may be sufficient for a dedicated point-to-point link, e.g., as opposed to a link over a VLAN at an internet exchange. Maybe the more important context is the remote management workstation path to a router, vs. a neighbor router. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 17 18:13:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11384 for ; Thu, 17 Apr 2003 18:13:09 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HMMSP14401 for rpsec-archive@odin.ietf.org; Thu, 17 Apr 2003 18:22:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMMS814398 for ; Thu, 17 Apr 2003 18:22:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11328 for ; Thu, 17 Apr 2003 18:12:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Hes-0003BJ-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 18:15:06 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196Hes-0003BG-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 18:15:06 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMM5814374; Thu, 17 Apr 2003 18:22:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMLD814320 for ; Thu, 17 Apr 2003 18:21:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11164 for ; Thu, 17 Apr 2003 18:11:24 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Hdg-0003Ao-00 for rpsec@ietf.org; Thu, 17 Apr 2003 18:13:52 -0400 Received: from aardvark.icir.org ([192.150.187.20]) by ietf-mx with esmtp (Exim 4.12) id 196Hdf-0003Al-00 for rpsec@ietf.org; Thu, 17 Apr 2003 18:13:51 -0400 Received: from aardvark.icir.org (localhost [127.0.0.1]) by aardvark.icir.org (8.12.8p1/8.12.3) with ESMTP id h3HMDwY3047907; Thu, 17 Apr 2003 15:13:58 -0700 (PDT) (envelope-from mjh@aardvark.icir.org) From: Mark Handley X-Organisation: ICIR To: Stephen Kent cc: rpsec@ietf.org Subject: Re: [RPSEC] rate limiting management traffic, redux In-reply-to: Your message of "Thu, 17 Apr 2003 17:59:56 EDT." Date: Thu, 17 Apr 2003 15:13:58 -0700 Message-ID: <47906.1050617638@aardvark.icir.org> Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , >If the management entity is a peer router at the other end of a link, >one might decide that less stringent resync mechanisms are needed, if >one does not assume a MITM attack capability. I guess I think you need to assume MITM attack capability. Routers are quite often peered across LANs, and I wouldn't want to count on an ethernet switch for routing protection. - Mark _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 17 18:31:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12521 for ; Thu, 17 Apr 2003 18:31:07 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HMeQS16292 for rpsec-archive@odin.ietf.org; Thu, 17 Apr 2003 18:40:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMeP816289 for ; Thu, 17 Apr 2003 18:40:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12477 for ; Thu, 17 Apr 2003 18:30:36 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HwG-0003L9-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 18:33:04 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196HwF-0003L6-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 18:33:03 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMe4816280; Thu, 17 Apr 2003 18:40:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMdr816226 for ; Thu, 17 Apr 2003 18:39:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12465 for ; Thu, 17 Apr 2003 18:30:03 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Hvj-0003Ku-00 for rpsec@ietf.org; Thu, 17 Apr 2003 18:32:31 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=sentry.rv.nailabs.com ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 196Hvj-0003Kr-00 for rpsec@ietf.org; Thu, 17 Apr 2003 18:32:31 -0400 Received: by sentry.rv.nailabs.com; id SAA05262; Thu, 17 Apr 2003 18:33:49 -0400 (EDT) Received: from raven.rv.nailabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma005232; Thu, 17 Apr 03 18:33:27 -0400 Received: (from sandy@localhost) by raven.rv.nailabs.com (8.11.6/8.11.6) id h3HMWM507337; Thu, 17 Apr 2003 18:32:22 -0400 (EDT) Date: Thu, 17 Apr 2003 18:32:22 -0400 (EDT) Message-Id: <200304172232.h3HMWM507337@raven.rv.nailabs.com> From: sandy@raven.gw.tislabs.com To: kent@bbn.com, sandy@nailabs.com Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , >I think it would be wrong to maintain that "no crypto techniques run >fast enough" I'm not advocating the opinion, just wondering if your approach was going to convince the folk who needed to be convinced. >A simple stream cipher would probably >suffice. Ah, I saw "one way function" and immediately jumped to the conclusion that you meant "cryptographic hash". >Moving MD5 to the interface card would address the current >problem for BGP neighbor traffic, but since it is a TCP-level >mechanism, it would entail moving a lot more mechanism to the card >than just the crypto check. Welllll, I was thinking that if you could accept the layer violations, the interface card could do just the MD5 authentication, and let the other processor do all the TCP processing. Of course, the whole question is moot, as you're suggesting a faster crypto. >However, the TTL=255 trick is certainly tough to beat :-) in terms of >performance, and it may be sufficient for a dedicated point-to-point >link I was wondering for a bit about routers that accepted IP-in-IP and whether that would be a way to disguise traffic so it had a 255/254 TTL, but the word I hear is that routers in general do not accept IP-in-IP packets. MBONE tunnels used to be IP-in-IP, but that's not used much anymore. >Maybe the more important context is the remote management workstation >path to a router, vs. a neighbor router. Any protocol a router is likely to run in the off-data-path processor has to be looked at. Network management protocols are a good bet to be there. --Sandy _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 17 18:38:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12785 for ; Thu, 17 Apr 2003 18:38:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HMlOR16553 for rpsec-archive@odin.ietf.org; Thu, 17 Apr 2003 18:47:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMlO816550 for ; Thu, 17 Apr 2003 18:47:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12778 for ; Thu, 17 Apr 2003 18:37:34 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196I30-0003O2-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 18:40:02 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196I2z-0003Nz-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 18:40:01 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMl4816539; Thu, 17 Apr 2003 18:47:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMk7816514 for ; Thu, 17 Apr 2003 18:46:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12762 for ; Thu, 17 Apr 2003 18:36:18 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196I1l-0003Ng-00 for rpsec@ietf.org; Thu, 17 Apr 2003 18:38:45 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 196I1l-0003Nd-00 for rpsec@ietf.org; Thu, 17 Apr 2003 18:38:45 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3HMcrE65308; Fri, 18 Apr 2003 00:38:53 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 18 Apr 2003 00:38:45 +0200 Subject: Re: [RPSEC] rate limiting management traffic, redux Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Stephen Kent , rpsec@ietf.org To: Mark Handley From: Iljitsch van Beijnum In-Reply-To: <47906.1050617638@aardvark.icir.org> Message-Id: <5905CE6A-7125-11D7-A1F8-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On vrijdag, apr 18, 2003, at 00:13 Europe/Amsterdam, Mark Handley wrote: >> If the management entity is a peer router at the other end of a link, >> one might decide that less stringent resync mechanisms are needed, if >> one does not assume a MITM attack capability. > I guess I think you need to assume MITM attack capability. Routers > are quite often peered across LANs, and I wouldn't want to count on an > ethernet switch for routing protection. The question is whether we need to be able to do man in the middle protection at line rate. If a man in the middle needs a real packet for every forged packet, it would be ok for the line cards to let these packets through and let the CPU do the strong crypto to detect this. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 17 18:52:15 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10563 for ; Thu, 17 Apr 2003 18:06:11 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HMFTp13996 for rpsec-archive@odin.ietf.org; Thu, 17 Apr 2003 18:15:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMFT813993 for ; Thu, 17 Apr 2003 18:15:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10450 for ; Thu, 17 Apr 2003 18:05:40 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HY7-00038S-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 18:08:07 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196HY7-00038P-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 18:08:07 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMF3813919; Thu, 17 Apr 2003 18:15:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HMCa813731 for ; Thu, 17 Apr 2003 18:12:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10151 for ; Thu, 17 Apr 2003 18:02:48 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196HVL-00037E-00 for rpsec@ietf.org; Thu, 17 Apr 2003 18:05:15 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196HVK-00036l-00 for rpsec@ietf.org; Thu, 17 Apr 2003 18:05:14 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3HM4c5w008000; Thu, 17 Apr 2003 18:04:38 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <47121.1050613052@aardvark.icir.org> References: <47121.1050613052@aardvark.icir.org> Date: Thu, 17 Apr 2003 17:59:56 -0400 To: Mark Handley From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Mark, I may have gone overboard in my proposed solution. If the management entity is a peer router at the other end of a link, one might decide that less stringent resync mechanisms are needed, if one does not assume a MITM attack capability. Even for a management station the vulnerability associated with not changing to a new key immediately may be acceptable. The reasoning is that only if an attacker has saved old tags for this router can he now use them to send bogus messages that will pass the quick discard test. Once the management station reestablishes contact, using its sequence number (hopefully capable of being retained reasonably well), then the receive window is reset to the correct value and old messages are again excluded. So, one might choose to keep things simple and allow for a "dumb" restart, confident that in a short time the system will resync and become secure (against replay) again. Still, the management station would be wise to initiate a re-key when feasible. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 17 19:21:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13963 for ; Thu, 17 Apr 2003 19:21:20 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HNUcF18789 for rpsec-archive@odin.ietf.org; Thu, 17 Apr 2003 19:30:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HNUc818786 for ; Thu, 17 Apr 2003 19:30:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13955 for ; Thu, 17 Apr 2003 19:20:49 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Iip-0003a5-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 19:23:15 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196Iip-0003a2-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 19:23:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HNUD818767; Thu, 17 Apr 2003 19:30:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HNTX818727 for ; Thu, 17 Apr 2003 19:29:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13930 for ; Thu, 17 Apr 2003 19:19:44 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Ihm-0003ZZ-00 for rpsec@ietf.org; Thu, 17 Apr 2003 19:22:10 -0400 Received: from aardvark.icir.org ([192.150.187.20]) by ietf-mx with esmtp (Exim 4.12) id 196Ihl-0003ZW-00 for rpsec@ietf.org; Thu, 17 Apr 2003 19:22:09 -0400 Received: from aardvark.icir.org (localhost [127.0.0.1]) by aardvark.icir.org (8.12.8p1/8.12.3) with ESMTP id h3HNMAY3048307; Thu, 17 Apr 2003 16:22:11 -0700 (PDT) (envelope-from mjh@aardvark.icir.org) From: Mark Handley X-Organisation: ICIR To: Stephen Kent cc: rpsec@ietf.org Subject: Re: [RPSEC] rate limiting management traffic, redux In-reply-to: Your message of "Thu, 17 Apr 2003 17:28:14 EDT." Date: Thu, 17 Apr 2003 16:22:10 -0700 Message-ID: <48306.1050621730@aardvark.icir.org> Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , >>What do you do about sequence number re-initialization? If this is >>being used to protect routing traffic, and a router restarts, do you >>require stable storage to preserve the previous sequence numbers? >Good question. > >At a minimum, stable storage is needed for the keys, but they change >slowly, so maintaining that ought not be too hard. It would be harder >for the per-sender window data to be saved, so we ought to have a >plan for re-initialization. > >A likely approach is to have the router that crashed initiate a >connection to each authorized management entity to reinitialize, >e.g., putting a new key in place and resetting the sequence number to >zero. In the re-initialization process, the router would engage in a >handshake with the management entities, using a nonce to ensure >freshness, and because the router initiated the handshake, it can at >least be protected against an attacker without access to the packets >it sends as part of the re-initialization process. We may be able to >be clever here too. For example, we could take the nonce generated by >the router and use it as an input to generate the new key from the >old key, so that the router and the management entity can very >quickly transition to the new key and resume secure communication. I'm not sure I understand your solution, so let me see if I can restate it. Suppose I have two routers, A and B that were communicating securely. Now, A restarts. How is B going to accept any more packets from A, as A can no longer send packets that fall in the window? I think you implied (trying to fill in the details myself): - A sends a re-initialization packet to B with nonce_A. - B replies with nonce_A and a new nonce_B. - A sends nonce_A and nonce_B back to B along with the new sequence number it wants to use and the one-way hash of nonce_A, nonce_B, the new sequence number and the secret. - On success, B sends nonce_A and nonce_B back to A, the new sequence number specified by A, and the one-way hash of nonce_B (but not nonce_A to avoid replay) the new sequence number and the secret. On success, the new secret becomes the hash of the old secret and the two nonces. The reason for the last phase is to avoid a DoS vulnerability from someone who can see traffic from A to B. They can flood A with re-initialization replies giving many different values of nonce_B. Router A will have to respond to all of them to reliably set up communication. So we need to add a final phase so A unambiguously knows which one was successful. Also need to be careful not to be used as an oracle - I think the above is OK, but I may have missed something. Is this more or less what you had in mind? - Mark _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Thu Apr 17 19:22:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13990 for ; Thu, 17 Apr 2003 19:22:02 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3HNVLC18848 for rpsec-archive@odin.ietf.org; Thu, 17 Apr 2003 19:31:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HNVL818845 for ; Thu, 17 Apr 2003 19:31:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13982 for ; Thu, 17 Apr 2003 19:21:32 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196IjW-0003aQ-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 19:23:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196IjV-0003aN-00 for rpsec-web-archive@ietf.org; Thu, 17 Apr 2003 19:23:57 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HNV2818827; Thu, 17 Apr 2003 19:31:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3HNUi818803 for ; Thu, 17 Apr 2003 19:30:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13961 for ; Thu, 17 Apr 2003 19:20:56 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Iiv-0003aB-00 for rpsec@ietf.org; Thu, 17 Apr 2003 19:23:21 -0400 Received: from aardvark.icir.org ([192.150.187.20]) by ietf-mx with esmtp (Exim 4.12) id 196Iiv-0003a8-00 for rpsec@ietf.org; Thu, 17 Apr 2003 19:23:21 -0400 Received: from aardvark.icir.org (localhost [127.0.0.1]) by aardvark.icir.org (8.12.8p1/8.12.3) with ESMTP id h3HNNTY3048319; Thu, 17 Apr 2003 16:23:29 -0700 (PDT) (envelope-from mjh@aardvark.icir.org) From: Mark Handley X-Organisation: ICIR To: Iljitsch van Beijnum cc: Stephen Kent , rpsec@ietf.org Subject: Re: [RPSEC] rate limiting management traffic, redux In-reply-to: Your message of "Fri, 18 Apr 2003 00:38:45 +0200." <5905CE6A-7125-11D7-A1F8-00039388672E@muada.com> Date: Thu, 17 Apr 2003 16:23:29 -0700 Message-ID: <48318.1050621809@aardvark.icir.org> Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , >On vrijdag, apr 18, 2003, at 00:13 Europe/Amsterdam, Mark Handley wrote: > >>> If the management entity is a peer router at the other end of a link, >>> one might decide that less stringent resync mechanisms are needed, if >>> one does not assume a MITM attack capability. > >> I guess I think you need to assume MITM attack capability. Routers >> are quite often peered across LANs, and I wouldn't want to count on an >> ethernet switch for routing protection. > >The question is whether we need to be able to do man in the middle >protection at line rate. If a man in the middle needs a real packet for >every forged packet, it would be ok for the line cards to let these >packets through and let the CPU do the strong crypto to detect this. That's true. But you've got to be careful in any re-initialization mechanism to not allow the attacker use a MITM attack to de-sync genuinely re-initializing peers so they can't communicate further, while at the same time defending against flooding of the re-initialization mechanism. - Mark _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 18 03:33:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05084 for ; Fri, 18 Apr 2003 03:33:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3I7gXR26997 for rpsec-archive@odin.ietf.org; Fri, 18 Apr 2003 03:42:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I7gW826994 for ; Fri, 18 Apr 2003 03:42:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05081 for ; Fri, 18 Apr 2003 03:32:33 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196QOh-0005kT-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 03:34:59 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196QOh-0005kQ-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 03:34:59 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I7fK826957; Fri, 18 Apr 2003 03:41:20 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I7ec826933 for ; Fri, 18 Apr 2003 03:40:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05042 for ; Fri, 18 Apr 2003 03:30:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196QMr-0005k4-00 for rpsec@ietf.org; Fri, 18 Apr 2003 03:33:05 -0400 Received: from ca-uk-fs.cisco.com ([64.103.66.8]) by ietf-mx with esmtp (Exim 4.12) id 196QMq-0005k1-00 for rpsec@ietf.org; Fri, 18 Apr 2003 03:33:04 -0400 Received: from DRAJNOVI-W2K1.cisco.com (drajnovi-isdn-home.cisco.com [10.49.135.250]) by ca-uk-fs.cisco.com (8.11.6+Sun/8.10.2) with ESMTP id h3I7Wch00106; Fri, 18 Apr 2003 08:32:39 +0100 (BST) Message-Id: <4.3.2.7.2.20030418080943.06111f00@ca-uk-fs.cisco.com> X-Sender: drajnovi@ca-uk-fs.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 18 Apr 2003 08:32:35 +0100 To: Mark Handley , Stephen Kent From: Damir Rajnovic Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org In-Reply-To: <48306.1050621730@aardvark.icir.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Hi, At 16:22 17/04/2003 -0700, Mark Handley wrote: >Suppose I have two routers, A and B that were communicating securely. >Now, A restarts. How is B going to accept any more packets from A, as >A can no longer send packets that fall in the window? > >I think you implied (trying to fill in the details myself): > > - A sends a re-initialization packet to B with nonce_A. If you send nonce_A and H(secret, nonce_A) you will ensure that router A is authenticated because (by the definition) only A knows the secret. The router A can also offer a new sequence number in the same packet. To make guessing even harder we can say that the router A should send H(secret, nonce_A, new_seq_A). By sending only nonce_A you are forcing the router B to respond to any request it receives. It does not have any means to discriminate which requests are legitimate and which are not. By sending a hash in the first packet you can authenticate the sender. > - B replies with nonce_A and a new nonce_B. B can reply with nonce_A, nonce_B, new sequence B and H(secret, nonce_B, new_seq_B) and H(secret, sequence A+1). The first hash H(secret, nonce_B, new_seq_B) server to initialize the new sequence number for the reverse session (from A to B). The second hash, H(secret, seq_A+1) is used normally as envisaged. The router A will check it first to determine if it will accept the packet or not. I think that you can accomplish the same result with only two messages instead of four. Since all data are sent in the clear the strength of the protection lies in the one-way hash function and the shared secret. These steps could probably be abandoned. > - A sends nonce_A and nonce_B back to B along with the new sequence > number it wants to use and the one-way hash of nonce_A, nonce_B, > the new sequence number and the secret. > > - On success, B sends nonce_A and nonce_B back to A, the new sequence number > specified by A, and the one-way hash of nonce_B (but not nonce_A to > avoid replay) the new sequence number and the secret. > >On success, the new secret becomes the hash of the old secret and the >two nonces. Even using the modified handshake you can derive the new key in the same manner. A and B are mutually authenticated and H(secret, nonce_A, nonce_B) was never transmitted. Gaus ============== Damir Rajnovic , PSIRT Incident Manager, Cisco Systems Telephone: +44 7715 546 033 200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB ============== There are no insolvable problems. The question is can you accept the solution? _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 18 04:42:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06235 for ; Fri, 18 Apr 2003 04:42:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3I8prQ31038 for rpsec-archive@odin.ietf.org; Fri, 18 Apr 2003 04:51:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I8pr831035 for ; Fri, 18 Apr 2003 04:51:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06220 for ; Fri, 18 Apr 2003 04:41:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196RTm-0005yq-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 04:44:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196RTm-0005yn-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 04:44:18 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I8pT831021; Fri, 18 Apr 2003 04:51:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3I8p0830993 for ; Fri, 18 Apr 2003 04:51:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06197 for ; Fri, 18 Apr 2003 04:40:58 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196RSv-0005yY-00 for rpsec@ietf.org; Fri, 18 Apr 2003 04:43:25 -0400 Received: from king.mcs.drexel.edu ([129.25.6.170]) by ietf-mx with esmtp (Exim 4.12) id 196RSv-0005yV-00 for rpsec@ietf.org; Fri, 18 Apr 2003 04:43:25 -0400 Received: from king.mcs.drexel.edu (localhost [127.0.0.1]) by king.mcs.drexel.edu (8.12.9/8.12.8) with ESMTP id h3I8hdVY021705 for ; Fri, 18 Apr 2003 04:43:39 -0400 (EDT) Received: (from vp@localhost) by king.mcs.drexel.edu (8.12.9/8.12.8/Submit) id h3I8hdBm021704 for rpsec@ietf.org; Fri, 18 Apr 2003 04:43:39 -0400 (EDT) Date: Fri, 18 Apr 2003 04:43:39 -0400 (EDT) From: Vassilis Prevelakis Message-Id: <200304180843.h3I8hdBm021704@king.mcs.drexel.edu> To: rpsec@ietf.org Subject: Re: [RPSEC] rate limiting management traffic, redux Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Damir Rajnovic wrote: > If you send nonce_A and H(secret, nonce_A) you will ensure that router A > is authenticated because (by the definition) only A knows the secret. > The router A can also offer a new sequence number in the same packet. > To make guessing even harder we can say that the router A should > send H(secret, nonce_A, new_seq_A). > > By sending only nonce_A you are forcing the router B to respond to > any request it receives. It does not have any means to discriminate > which requests are legitimate and which are not. By sending a hash > in the first packet you can authenticate the sender. [...] > B can reply with nonce_A, nonce_B, new sequence B and H(secret, > nonce_B, new_seq_B) and H(secret, sequence A+1). The first hash > H(secret, nonce_B, new_seq_B) server to initialize the new > sequence number for the reverse session (from A to B). The second > hash, H(secret, seq_A+1) is used normally as envisaged. The router > A will check it first to determine if it will accept the packet > or not. Your two message scheme exposes router B to replay attacks. I.e. what is to prevent me from recording the initial packet nonce_A, new_seq_A, H(secret, nonce_A, new_seq_A) and sending it to B every now and then? What should A do when it receives the reply from B? Can I capture A's reply and feed it to B later on? If the process of verifying the incoming message and computing the reply (new seq num, etc) is expensive, then you also expose B to DOS attacks. Must we rediscover the wheel in this group? Why don't we all take a break to read a good book on communications security and return after a week or so. **vp _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 18 08:36:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11700 for ; Fri, 18 Apr 2003 08:36:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ICjv513162 for rpsec-archive@odin.ietf.org; Fri, 18 Apr 2003 08:45:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICjv813159 for ; Fri, 18 Apr 2003 08:45:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11689 for ; Fri, 18 Apr 2003 08:35:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196V8D-0007El-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 08:38:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196V8D-0007Ei-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 08:38:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICjM813120; Fri, 18 Apr 2003 08:45:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICiT813083 for ; Fri, 18 Apr 2003 08:44:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11677 for ; Fri, 18 Apr 2003 08:34:24 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196V6n-0007EY-00 for rpsec@ietf.org; Fri, 18 Apr 2003 08:36:49 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196V6n-0007EQ-00 for rpsec@ietf.org; Fri, 18 Apr 2003 08:36:49 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3ICaG5w008287; Fri, 18 Apr 2003 08:36:16 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 18 Apr 2003 08:33:35 -0400 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 12:00 AM +0200 4/18/03, Iljitsch van Beijnum wrote: >On donderdag, apr 17, 2003, at 22:40 Europe/Amsterdam, Stephen Kent wrote: > >>My new suggestion in this area requires a shared secret (key) >>between the router and the entity sending the management traffic, >>either another router or a management workstation. The key is one >>of two inputs to a one-way function; the other input will be a >>sequence number which will be carried with the packet. > >This is similar to something I proposed about a month ago: > >"Ok, how about this: we use a stream cipher to come up with a random-looking >data stream on both ends and use the IPsec anti-replay counter as a >pointer to the part of the data stream that is used as a magic cookie in >the current packet. We can then program the line card with enough data >to be able to check a certain number of packets per session" I don't recall seeing your message on RPSEC. Also, it's still a bit hard to translate what you said above, into a more general description of the sort I provided, complete with a rationale of why it might suffice. Some stream ciphers are slow to compute an arbitrary value in the stream, vs. the "next" value, so the description you have above is more specific that my general proposal (in specifying stream ciphers) but it still needs to be narrowed to select the right sort of one-way function. > >>A managed device such as a router maintains a separate key for each >>entity that is authorized to send management traffic to the device. >>For each authorized sender, the managed device maintains the >>following information: >> - the address of the sender >> - the shared secret > >This means the crypto is done on the cards. Doing this beforehand >elsewhere and then simply upload the results to the linecard is >probably a better idea. A linecard with crypto hardware could of >course do this on the fly but if we have such a linecard why not >simply do IPsec AH? One could pre-compute sequence number/tag values and download them to line cards, but I would suggest this only if the function was too slow to effect in real time on the cards. There is a big difference between doign what I suggested and doing AH. The integrity check in AH covers most of the packet and thus will take longer to compute than a function that has only a key and a sequence number as inputs. Also, the AH integrity check skips some but not all IP header fields, making it complex to compute. So, this is an "apples/oranges" sort of comparison! >> - a receive window consisting of the sequence number for the >>most recent, valid management packet from the sender, a sequence >>number indicating the edge for "too old" packets, plus a bit map >>marking received , valid packets within the window. > >I'm not sure requiring this bitmap is a good idea, as id adds >complexity (that may need to be burnt into silicon). Huh? You refer to the IPsec sequence number management mechanism in your quote, but the use of a bit map to track arrived packets within the window is exactly the nominal implementation approach for this, as described in RFC 2406 & 2406. What did you mean when you referred to IPsec sequence number management? > >>There are a few open issues: >> - where to carry the sequence number and tag > >If we're doing IPsec, we already have the anti-replay counter that I >think can easily do double duty here. For the tag we either have to >create a completely new option or extend IPsec. Alternatively, the >tag can be used as (part of) the IV for ESP processing. Yes, if we use IPsec for end-to-end security, one could definitely use that sequence number field, but I didn't know if people wanted to make that assumption for this mechanism. > >> - how big is the sequence number and how big is the tag > >The sequence number wraps all the time so 16 bits should be adequate >or maybe 32 bits. As a typical window would be something like 64 >packets, with a 32 bit tag an attacker has a one in 500 million >chance of guessing a valid tag. A 10 Gbit link can carry several >million packets per second so the attack would hit paydirt in a >matter of minutes with 32 bits. So I'd say at least 48 bits. Recall that for IPsec we moved to support 64 bit sequence numbers (vs. 32 bit numbers) to better accommodate high speed links, so I a 32 bit sequence number is probably the smallest I would consider, and 64 would be preferable. The tag size is a crypto issue, as well as the key size, so all of these parameters need to be considered as a whole. > >> - how big is the key >> - what one-way function to use > >This is something the crypto experts should answer. I suspect that >doing a one-way function over some static data and a sequence number >doesn't provide enough entropy from one packet to the next to be >secure, even for this purpose. My non-expert guess is that a stream >cipher with the sequence number as a pointer to the stream would be >better. Yes, let's not play cryptographer here. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 18 08:36:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11703 for ; Fri, 18 Apr 2003 08:36:22 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ICjvf13178 for rpsec-archive@odin.ietf.org; Fri, 18 Apr 2003 08:45:57 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICjv813175 for ; Fri, 18 Apr 2003 08:45:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11692 for ; Fri, 18 Apr 2003 08:35:52 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196V8D-0007Ep-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 08:38:17 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196V8D-0007Em-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 08:38:17 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICjQ813136; Fri, 18 Apr 2003 08:45:26 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICiW813087 for ; Fri, 18 Apr 2003 08:44:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11680 for ; Fri, 18 Apr 2003 08:34:27 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196V6r-0007Ed-00 for rpsec@ietf.org; Fri, 18 Apr 2003 08:36:53 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196V6q-0007ES-00 for rpsec@ietf.org; Fri, 18 Apr 2003 08:36:52 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3ICaG60008287; Fri, 18 Apr 2003 08:36:17 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <47906.1050617638@aardvark.icir.org> References: <47906.1050617638@aardvark.icir.org> Date: Fri, 18 Apr 2003 08:35:51 -0400 To: Mark Handley From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 3:13 PM -0700 4/17/03, Mark Handley wrote: > >If the management entity is a peer router at the other end of a link, >>one might decide that less stringent resync mechanisms are needed, if >>one does not assume a MITM attack capability. > >I guess I think you need to assume MITM attack capability. Routers >are quite often peered across LANs, and I wouldn't want to count on an >ethernet switch for routing protection. > > - Mark OK. As a security guy I'm accustomed to thinking in terms of MITM attacks, but I didn't want to impose my biases on the problem space. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 18 08:45:54 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11859 for ; Fri, 18 Apr 2003 08:45:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ICtTq13542 for rpsec-archive@odin.ietf.org; Fri, 18 Apr 2003 08:55:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICtT813539 for ; Fri, 18 Apr 2003 08:55:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11849 for ; Fri, 18 Apr 2003 08:45:23 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196VHQ-0007H2-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 08:47:48 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196VHQ-0007Gz-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 08:47:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICt3813521; Fri, 18 Apr 2003 08:55:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICsA813438 for ; Fri, 18 Apr 2003 08:54:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11822 for ; Fri, 18 Apr 2003 08:44:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196VGA-0007GS-00 for rpsec@ietf.org; Fri, 18 Apr 2003 08:46:30 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196VGA-0007G0-00 for rpsec@ietf.org; Fri, 18 Apr 2003 08:46:30 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3ICk562008903; Fri, 18 Apr 2003 08:46:14 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5905CE6A-7125-11D7-A1F8-00039388672E@muada.com> References: <5905CE6A-7125-11D7-A1F8-00039388672E@muada.com> Date: Fri, 18 Apr 2003 08:44:25 -0400 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: Mark Handley , rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 12:38 AM +0200 4/18/03, Iljitsch van Beijnum wrote: >On vrijdag, apr 18, 2003, at 00:13 Europe/Amsterdam, Mark Handley wrote: > >>>If the management entity is a peer router at the other end of a link, >>>one might decide that less stringent resync mechanisms are needed, if >>>one does not assume a MITM attack capability. > >>I guess I think you need to assume MITM attack capability. Routers >>are quite often peered across LANs, and I wouldn't want to count on an >>ethernet switch for routing protection. > >The question is whether we need to be able to do man in the middle >protection at line rate. If a man in the middle needs a real packet >for every forged packet, it would be ok for the line cards to let >these packets through and let the CPU do the strong crypto to detect >this. Yes that is exactly the rationale underlying why it seems to be OK to not tie the authentication tag to the packet. But, I interpreted Mark's comment to be a response to the question of what sort of attacks we have to worry about under restart conditions, where I suggested that we could relax the constraints after a crash where the sequence number info was lost. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 18 09:15:01 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12601 for ; Fri, 18 Apr 2003 09:15:01 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IDObJ15433 for rpsec-archive@odin.ietf.org; Fri, 18 Apr 2003 09:24:37 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IDOa815430 for ; Fri, 18 Apr 2003 09:24:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12591 for ; Fri, 18 Apr 2003 09:14:30 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Vjc-0007PK-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 09:16:56 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196Vjc-0007PH-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 09:16:56 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IDO7815415; Fri, 18 Apr 2003 09:24:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IDNq815395 for ; Fri, 18 Apr 2003 09:23:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12579 for ; Fri, 18 Apr 2003 09:13:46 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Vit-0007P1-00 for rpsec@ietf.org; Fri, 18 Apr 2003 09:16:11 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196Vit-0007Ow-00 for rpsec@ietf.org; Fri, 18 Apr 2003 09:16:11 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3IDFq60010441; Fri, 18 Apr 2003 09:15:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <48318.1050621809@aardvark.icir.org> References: <48318.1050621809@aardvark.icir.org> Date: Fri, 18 Apr 2003 09:16:24 -0400 To: Mark Handley From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 4:23 PM -0700 4/17/03, Mark Handley wrote: > >On vrijdag, apr 18, 2003, at 00:13 Europe/Amsterdam, Mark Handley wrote: >> >>>> If the management entity is a peer router at the other end of a link, >>>> one might decide that less stringent resync mechanisms are needed, if >>>> one does not assume a MITM attack capability. >> >>> I guess I think you need to assume MITM attack capability. Routers >>> are quite often peered across LANs, and I wouldn't want to count on an >>> ethernet switch for routing protection. >> >>The question is whether we need to be able to do man in the middle >>protection at line rate. If a man in the middle needs a real packet for >>every forged packet, it would be ok for the line cards to let these >>packets through and let the CPU do the strong crypto to detect this. > >That's true. But you've got to be careful in any re-initialization >mechanism to not allow the attacker use a MITM attack to de-sync >genuinely re-initializing peers so they can't communicate further, >while at the same time defending against flooding of the >re-initialization mechanism. > > - Mark Mark, Right. My off the cuff protocol should be viewed just as a starting point for discussion, but this is a generally tricky area, because it's hard to defend against attacks that focus on DoS, and initialization is hard, and ... Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 18 09:26:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12998 for ; Fri, 18 Apr 2003 09:26:59 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IDaZL15825 for rpsec-archive@odin.ietf.org; Fri, 18 Apr 2003 09:36:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IDaZ815821 for ; Fri, 18 Apr 2003 09:36:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12990 for ; Fri, 18 Apr 2003 09:26:28 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196VvC-0007UY-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 09:28:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196VvC-0007UV-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 09:28:54 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IDa6815805; Fri, 18 Apr 2003 09:36:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IDZI815770 for ; Fri, 18 Apr 2003 09:35:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12878 for ; Fri, 18 Apr 2003 09:25:12 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196Vty-0007Sk-00 for rpsec@ietf.org; Fri, 18 Apr 2003 09:27:38 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196Vtx-0007Rs-00 for rpsec@ietf.org; Fri, 18 Apr 2003 09:27:37 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3IDQP5w011041; Fri, 18 Apr 2003 09:26:25 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <4.3.2.7.2.20030418080943.06111f00@ca-uk-fs.cisco.com> References: <4.3.2.7.2.20030418080943.06111f00@ca-uk-fs.cisco.com> Date: Fri, 18 Apr 2003 09:25:09 -0400 To: Damir Rajnovic From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 8:32 AM +0100 4/18/03, Damir Rajnovic wrote: >Hi, > >At 16:22 17/04/2003 -0700, Mark Handley wrote: >>Suppose I have two routers, A and B that were communicating securely. >>Now, A restarts. How is B going to accept any more packets from A, as >>A can no longer send packets that fall in the window? >> >>I think you implied (trying to fill in the details myself): >> >> - A sends a re-initialization packet to B with nonce_A. > >If you send nonce_A and H(secret, nonce_A) you will ensure that router A >is authenticated because (by the definition) only A knows the secret. >The router A can also offer a new sequence number in the same packet. >To make guessing even harder we can say that the router A should >send H(secret, nonce_A, new_seq_A). > >By sending only nonce_A you are forcing the router B to respond to >any request it receives. It does not have any means to discriminate >which requests are legitimate and which are not. By sending a hash >in the first packet you can authenticate the sender. Very good point. Do we need to choose a new sequence number, rather than just starting at 0 again? I guess we get some benefit from a new sequence starting point in terms of rejecting old or random traffic faster, assuming that the attacker does not have passive wiretap ability (often true, but not always). > > - B replies with nonce_A and a new nonce_B. > >B can reply with nonce_A, nonce_B, new sequence B and H(secret, >nonce_B, new_seq_B) and H(secret, sequence A+1). The first hash >H(secret, nonce_B, new_seq_B) server to initialize the new >sequence number for the reverse session (from A to B). The second >hash, H(secret, seq_A+1) is used normally as envisaged. The router >A will check it first to determine if it will accept the packet >or not. > >I think that you can accomplish the same result with only two >messages instead of four. Since all data are sent in the clear >the strength of the protection lies in the one-way hash function >and the shared secret. Right. And, this hash function need not be the same as the function I called for using to generate per-packet tags. This hash function could be slower, since it is used less frequently. > >These steps could probably be abandoned. > >> - A sends nonce_A and nonce_B back to B along with the new sequence >> number it wants to use and the one-way hash of nonce_A, nonce_B, >> the new sequence number and the secret. >> >> - On success, B sends nonce_A and nonce_B back to A, the new sequence number >> specified by A, and the one-way hash of nonce_B (but not nonce_A to >> avoid replay) the new sequence number and the secret. >> >>On success, the new secret becomes the hash of the old secret and the >>two nonces. > >Even using the modified handshake you can derive the new key in the >same manner. A and B are mutually authenticated and H(secret, nonce_A, >nonce_B) was never transmitted. > >Gaus I like the style of your proposed exchanges. The goals of the (re) initialization protocol are to put in place a new secret and, maybe, to reset the sequence number and to minimize the opportunities for an attacker to waste router resources in the process. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 18 09:32:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11860 for ; Fri, 18 Apr 2003 08:45:54 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3ICtTC13558 for rpsec-archive@odin.ietf.org; Fri, 18 Apr 2003 08:55:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICtT813555 for ; Fri, 18 Apr 2003 08:55:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11852 for ; Fri, 18 Apr 2003 08:45:23 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196VHR-0007H6-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 08:47:49 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196VHQ-0007H3-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 08:47:48 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICt2813505; Fri, 18 Apr 2003 08:55:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ICs0813421 for ; Fri, 18 Apr 2003 08:54:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11814 for ; Fri, 18 Apr 2003 08:43:55 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196VG0-0007GH-00 for rpsec@ietf.org; Fri, 18 Apr 2003 08:46:20 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196VG0-0007Fv-00 for rpsec@ietf.org; Fri, 18 Apr 2003 08:46:20 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3ICk55w008903; Fri, 18 Apr 2003 08:46:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200304172232.h3HMWM507337@raven.rv.nailabs.com> References: <200304172232.h3HMWM507337@raven.rv.nailabs.com> Date: Fri, 18 Apr 2003 08:38:38 -0400 To: sandy@raven.gw.tislabs.com From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 6:32 PM -0400 4/17/03, sandy@raven.gw.tislabs.com wrote: > >I think it would be wrong to maintain that "no crypto techniques run >>fast enough" > >I'm not advocating the opinion, just wondering if your approach was >going to convince the folk who needed to be convinced. I didn't mean to suggest that this was your opinion, but I did want to make the point that not all crypto is slow. > >>A simple stream cipher would probably >>suffice. > >Ah, I saw "one way function" and immediately jumped to the conclusion that >you meant "cryptographic hash". Understandable, but not the only option. > >Moving MD5 to the interface card would address the current >>problem for BGP neighbor traffic, but since it is a TCP-level >>mechanism, it would entail moving a lot more mechanism to the card >>than just the crypto check. > >Welllll, I was thinking that if you could accept the layer violations, >the interface card could do just the MD5 authentication, and let the >other processor do all the TCP processing. Of course, the whole question >is moot, as you're suggesting a faster crypto. Also, the MD5 checksum is computed over the whole TCP payload, and that IS a lot slower than a function computed over just two, small values. > >However, the TTL=255 trick is certainly tough to beat :-) in terms of >>performance, and it may be sufficient for a dedicated point-to-point >>link > >I was wondering for a bit about routers that accepted IP-in-IP and >whether that would be a way to disguise traffic so it had a 255/254 TTL, >but the word I hear is that routers in general do not accept IP-in-IP >packets. MBONE tunnels used to be IP-in-IP, but that's not used much >anymore. > >>Maybe the more important context is the remote management workstation >>path to a router, vs. a neighbor router. > >Any protocol a router is likely to run in the off-data-path processor >has to be looked at. Network management protocols are a good bet to be there. Right. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 18 09:37:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13288 for ; Fri, 18 Apr 2003 09:37:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IDl2417092 for rpsec-archive@odin.ietf.org; Fri, 18 Apr 2003 09:47:02 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IDl2817089 for ; Fri, 18 Apr 2003 09:47:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13282 for ; Fri, 18 Apr 2003 09:36:55 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196W5J-0007Xj-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 09:39:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196W5J-0007Xg-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 09:39:21 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IDkR817018; Fri, 18 Apr 2003 09:46:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IDhl816913 for ; Fri, 18 Apr 2003 09:43:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13223 for ; Fri, 18 Apr 2003 09:33:39 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196W29-0007Wv-00 for rpsec@ietf.org; Fri, 18 Apr 2003 09:36:05 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196W28-0007Wo-00 for rpsec@ietf.org; Fri, 18 Apr 2003 09:36:04 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3IDZn5w011587; Fri, 18 Apr 2003 09:35:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <48306.1050621730@aardvark.icir.org> References: <48306.1050621730@aardvark.icir.org> Date: Fri, 18 Apr 2003 09:28:59 -0400 To: Mark Handley From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 4:22 PM -0700 4/17/03, Mark Handley wrote: > >>What do you do about sequence number re-initialization? If this is >>>being used to protect routing traffic, and a router restarts, do you >>>require stable storage to preserve the previous sequence numbers? > >>Good question. >> >>At a minimum, stable storage is needed for the keys, but they change >>slowly, so maintaining that ought not be too hard. It would be harder >>for the per-sender window data to be saved, so we ought to have a >>plan for re-initialization. >> >>A likely approach is to have the router that crashed initiate a >>connection to each authorized management entity to reinitialize, >>e.g., putting a new key in place and resetting the sequence number to >>zero. In the re-initialization process, the router would engage in a >>handshake with the management entities, using a nonce to ensure >>freshness, and because the router initiated the handshake, it can at >>least be protected against an attacker without access to the packets >>it sends as part of the re-initialization process. We may be able to >>be clever here too. For example, we could take the nonce generated by >>the router and use it as an input to generate the new key from the >>old key, so that the router and the management entity can very >>quickly transition to the new key and resume secure communication. > >I'm not sure I understand your solution, so let me see if I can >restate it. > >Suppose I have two routers, A and B that were communicating securely. >Now, A restarts. How is B going to accept any more packets from A, as >A can no longer send packets that fall in the window? > >I think you implied (trying to fill in the details myself): > > - A sends a re-initialization packet to B with nonce_A. > > - B replies with nonce_A and a new nonce_B. > > - A sends nonce_A and nonce_B back to B along with the new sequence > number it wants to use and the one-way hash of nonce_A, nonce_B, > the new sequence number and the secret. > > - On success, B sends nonce_A and nonce_B back to A, the new sequence number > specified by A, and the one-way hash of nonce_B (but not nonce_A to > avoid replay) the new sequence number and the secret. > >On success, the new secret becomes the hash of the old secret and the >two nonces. > >The reason for the last phase is to avoid a DoS vulnerability from >someone who can see traffic from A to B. They can flood A with >re-initialization replies giving many different values of nonce_B. >Router A will have to respond to all of them to reliably set up >communication. So we need to add a final phase so A unambiguously >knows which one was successful. Also need to be careful not to be >used as an oracle - I think the above is OK, but I may have missed >something. > >Is this more or less what you had in mind? > > - Mark Mark, I like the suggestions Damir made, to include data in each message to make forgery hard and thus allow a router to reject bogus re-initialization attempts. When I dashed off the quick message late yesterday afternoon I was thinking more about the router-to-management station case, where there is less of a need to worry about processing for bogus re-initialization messages. The router-to-router case was not foremost on my mind. But, it is nice to have a unified way to deal with both cases and I think we are heading in that direction. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 18 10:57:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16488 for ; Fri, 18 Apr 2003 10:57:44 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IF7NV22393 for rpsec-archive@odin.ietf.org; Fri, 18 Apr 2003 11:07:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IF7N822390 for ; Fri, 18 Apr 2003 11:07:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16480 for ; Fri, 18 Apr 2003 10:57:14 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196XL2-00007F-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 10:59:40 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196XL1-00007C-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 10:59:39 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IF6e821584; Fri, 18 Apr 2003 11:06:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IF09821398 for ; Fri, 18 Apr 2003 11:00:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16342 for ; Fri, 18 Apr 2003 10:50:01 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196XE3-00005M-00 for rpsec@ietf.org; Fri, 18 Apr 2003 10:52:27 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 196XE2-00005J-00 for rpsec@ietf.org; Fri, 18 Apr 2003 10:52:26 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3IEqkE66876; Fri, 18 Apr 2003 16:52:46 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 18 Apr 2003 16:52:37 +0200 Subject: Re: [RPSEC] rate limiting management traffic, redux Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rpsec@ietf.org To: Stephen Kent From: Iljitsch van Beijnum In-Reply-To: Message-Id: <65551A83-71AD-11D7-BDD6-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On vrijdag, apr 18, 2003, at 14:33 Europe/Amsterdam, Stephen Kent wrote: >> This is similar to something I proposed about a month ago: > I don't recall seeing your message on RPSEC. Also, it's still a bit > hard to translate what you said above, into a more general description > of the sort I provided, complete with a rationale of why it might > suffice. It was part of a more extensive discussion, but I agree your description is more thorough and more general. > Some stream ciphers are slow to compute an arbitrary value in the > stream, vs. the "next" value, so the description you have above is > more specific that my general proposal (in specifying stream ciphers) > but it still needs to be narrowed to select the right sort of one-way > function. Of course. >> This means the crypto is done on the cards. Doing this beforehand >> elsewhere and then simply upload the results to the linecard is >> probably a better idea. A linecard with crypto hardware could of >> course do this on the fly but if we have such a linecard why not >> simply do IPsec AH? > One could pre-compute sequence number/tag values and download them to > line cards, but I would suggest this only if the function was too slow > to effect in real time on the cards. Even if you _can_ do it on the fly, that doesn't mean it is preferable to do it that way. The whole point of the earlier stuff I mentioned above was to not have to do crypto for each incoming packet, but rather for each expected valid packet. This should be doable in software, or with the assistence of crypto hardware without the requirement that this crypto hardware be able to keep up with line rate on all interfaces. > There is a big difference between doign what I suggested and doing AH. > The integrity check in AH covers most of the packet and thus will take > longer to compute than a function that has only a key and a sequence > number as inputs. Also, the AH integrity check skips some but not all > IP header fields, making it complex to compute. So, this is an > "apples/oranges" sort of comparison! Yes, but if you have a perfectly good apple tree, is a craving for the occasional orange reason enough to build a green house so you can grow them? In other words: yes, your integrety check is cheaper than full AH, but is it worth the trouble to implement a new protocol in hardware? If I were buying crypto hardware, I'd rather have it do full line rate IPsec. >> 'm not sure requiring this bitmap is a good idea, as id adds >> complexity (that may need to be burnt into silicon). > Huh? You refer to the IPsec sequence number management mechanism in > your quote, but the use of a bit map to track arrived packets within > the window is exactly the nominal implementation approach for this, as > described in RFC 2406 & 2406. What did you mean when you referred to > IPsec sequence number management? I don't think I mentioned the management of the sequence number, just the replay counter field. Having the bitmap processing would be a good feature, I'm just not sure it's a good idea to require it. Let the implementers worry about this. >> If we're doing IPsec, we already have the anti-replay counter that I >> think can easily do double duty here. For the tag we either have to >> create a completely new option or extend IPsec. Alternatively, the >> tag can be used as (part of) the IV for ESP processing. > Yes, if we use IPsec for end-to-end security, one could definitely use > that sequence number field, but I didn't know if people wanted to make > that assumption for this mechanism. Currently IPsec ESP supports authentication and encryption, maybe this could be an additional IPsec service? >>> - how big is the sequence number and how big is the tag >> The sequence number wraps all the time so 16 bits should be adequate >> or maybe 32 bits. As a typical window would be something like 64 >> packets, with a 32 bit tag an attacker has a one in 500 million >> chance of guessing a valid tag. A 10 Gbit link can carry several >> million packets per second so the attack would hit paydirt in a >> matter of minutes with 32 bits. So I'd say at least 48 bits. > Recall that for IPsec we moved to support 64 bit sequence numbers (vs. > 32 bit numbers) to better accommodate high speed links, so I a 32 bit > sequence number is probably the smallest I would consider, and 64 > would be preferable. Note that the requirements here are very different from those in regular IPsec. In IPsec, data rates may be very high, and the overhead in creating a new SA is considerable. In this scheme, the data rates are in the order of one Mbps or less and the overhead of increasing the window is very small. So there is no need to support a large sequence number space, a simple sliding window pointer is sufficient. Even 6 bits could be enough. The other end can simply fill in the missing bits to arrive at the desired sequence number length. > The tag size is a crypto issue, as well as the key size, so all of > these parameters need to be considered as a whole. It's not a traditional crypto issue. After thinking about it a bit more I realized my earlier reasoning that the tag should be at least 48 bits doesn't hold. With a 32 bit tag an attacker has a 1 in 4 billion chance of guessing a valid tag/sequence combination. Even with millions abusive packets per second that means the CPU only gets to see a hand full per hour. That's more than adequate. And a smaller tag has the advantage that it makes analysis by an attacker more difficult, I think there are some remarks about this in one of the IPsec documents on authentication. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 18 16:14:03 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25687 for ; Fri, 18 Apr 2003 16:14:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3IKNmS10455 for rpsec-archive@odin.ietf.org; Fri, 18 Apr 2003 16:23:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IKNm810452 for ; Fri, 18 Apr 2003 16:23:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25654 for ; Fri, 18 Apr 2003 16:13:32 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196cH8-0001H8-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 16:15:58 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196cH8-0001H4-00 for rpsec-web-archive@ietf.org; Fri, 18 Apr 2003 16:15:58 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IKND810428; Fri, 18 Apr 2003 16:23:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3IKMx810403 for ; Fri, 18 Apr 2003 16:22:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25636 for ; Fri, 18 Apr 2003 16:12:44 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196cGM-0001Gn-00 for rpsec@ietf.org; Fri, 18 Apr 2003 16:15:10 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 196cGL-0001Gb-00 for rpsec@ietf.org; Fri, 18 Apr 2003 16:15:09 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3IKEo5w007060; Fri, 18 Apr 2003 16:14:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <65551A83-71AD-11D7-BDD6-00039388672E@muada.com> References: <65551A83-71AD-11D7-BDD6-00039388672E@muada.com> Date: Fri, 18 Apr 2003 16:08:46 -0400 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 4:52 PM +0200 4/18/03, Iljitsch van Beijnum wrote: > >>One could pre-compute sequence number/tag values and download them >>to line cards, but I would suggest this only if the function was >>too slow to effect in real time on the cards. > >Even if you _can_ do it on the fly, that doesn't mean it is >preferable to do it that way. The whole point of the earlier stuff I >mentioned above was to not have to do crypto for each incoming >packet, but rather for each expected valid packet. This should be >doable in software, or with the assistence of crypto hardware >without the requirement that this crypto hardware be able to keep up >with line rate on all interfaces. > >>There is a big difference between doign what I suggested and doing >>AH. The integrity check in AH covers most of the packet and thus >>will take longer to compute than a function that has only a key and >>a sequence number as inputs. Also, the AH integrity check skips >>some but not all IP header fields, making it complex to compute. >>So, this is an "apples/oranges" sort of comparison! > >Yes, but if you have a perfectly good apple tree, is a craving for >the occasional orange reason enough to build a green house so you >can grow them? Must be an old Dutch proverb ? >In other words: yes, your integrety check is cheaper than full AH, >but is it worth the trouble to implement a new protocol in hardware? >If I were buying crypto hardware, I'd rather have it do full line >rate IPsec. No disagreement about what would be ideal, just a matter of complexity and cost, which I have been told are concerns for some folks :-) > >>>'m not sure requiring this bitmap is a good idea, as id adds >>>complexity (that may need to be burnt into silicon). > >>Huh? You refer to the IPsec sequence number management mechanism in >>your quote, but the use of a bit map to track arrived packets >>within the window is exactly the nominal implementation approach >>for this, as described in RFC 2406 & 2406. What did you mean when >>you referred to IPsec sequence number management? > >I don't think I mentioned the management of the sequence number, >just the replay counter field. Having the bitmap processing would be >a good feature, I'm just not sure it's a good idea to require it. >Let the implementers worry about this. Yes, the implementation details are a local matter. > >>>If we're doing IPsec, we already have the anti-replay counter that >>>I think can easily do double duty here. For the tag we either have >>>to create a completely new option or extend IPsec. Alternatively, >>>the tag can be used as (part of) the IV for ESP processing. > >>Yes, if we use IPsec for end-to-end security, one could definitely >>use that sequence number field, but I didn't know if people wanted >>to make that assumption for this mechanism. > >Currently IPsec ESP supports authentication and encryption, maybe >this could be an additional IPsec service? ESP mandates support for confidentiality plus integrity, or integrity only, or confidentiality only. Since the IPsec WG is trying to simplify the range of options, we're dropping mandatory support for confidentiality only. I don't see it as likely that we would add an "authentication tag not tied to the payload" option. > >>>> - how big is the sequence number and how big is the tag > >>>The sequence number wraps all the time so 16 bits should be >>>adequate or maybe 32 bits. As a typical window would be something >>>like 64 packets, with a 32 bit tag an attacker has a one in 500 >>>million chance of guessing a valid tag. A 10 Gbit link can carry >>>several million packets per second so the attack would hit paydirt >>>in a matter of minutes with 32 bits. So I'd say at least 48 bits. > >>Recall that for IPsec we moved to support 64 bit sequence numbers >>(vs. 32 bit numbers) to better accommodate high speed links, so I a >>32 bit sequence number is probably the smallest I would consider, >>and 64 would be preferable. > >Note that the requirements here are very different from those in >regular IPsec. In IPsec, data rates may be very high, and the >overhead in creating a new SA is considerable. In this scheme, the >data rates are in the order of one Mbps or less and the overhead of >increasing the window is very small. So there is no need to support >a large sequence number space, a simple sliding window pointer is >sufficient. Even 6 bits could be enough. The other end can simply >fill in the missing bits to arrive at the desired sequence number >length. Yes, legitimate management traffic should arrive at relatively low data rates, so maybe a smaller sequence number size would suffice. But, the tag size should be big enough to not allow an attacker to flood the system with bogus packets for which a non-trivial number pass this test. > >>The tag size is a crypto issue, as well as the key size, so all of >>these parameters need to be considered as a whole. > >It's not a traditional crypto issue. After thinking about it a bit >more I realized my earlier reasoning that the tag should be at least >48 bits doesn't hold. With a 32 bit tag an attacker has a 1 in 4 >billion chance of guessing a valid tag/sequence combination. Even >with millions abusive packets per second that means the CPU only >gets to see a hand full per hour. That's more than adequate. And a >smaller tag has the advantage that it makes analysis by an attacker >more difficult, I think there are some remarks about this in one of >the IPsec documents on authentication. A tag formed from a truncated hash function output has the advantage that an attacker is not able to see all the output bits to try to work backwards to the key. But, we have not yet specified the function we will use to generate the tag, and so it's a bit premature to talk about whether a truncated output from that unspecified function is appropriate :-). Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Sat Apr 19 13:46:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28669 for ; Sat, 19 Apr 2003 13:46:16 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3JHuSA25725 for rpsec-archive@odin.ietf.org; Sat, 19 Apr 2003 13:56:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3JHuR825722 for ; Sat, 19 Apr 2003 13:56:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28665 for ; Sat, 19 Apr 2003 13:45:45 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196wRf-000558-00 for rpsec-web-archive@ietf.org; Sat, 19 Apr 2003 13:48:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 196wRe-000555-00 for rpsec-web-archive@ietf.org; Sat, 19 Apr 2003 13:48:10 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3JHtl825701; Sat, 19 Apr 2003 13:55:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3JHsk825677 for ; Sat, 19 Apr 2003 13:54:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28660 for ; Sat, 19 Apr 2003 13:44:04 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 196wQ1-000550-00 for rpsec@ietf.org; Sat, 19 Apr 2003 13:46:29 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 196wQ1-00054x-00 for rpsec@ietf.org; Sat, 19 Apr 2003 13:46:29 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3JHkmE71120; Sat, 19 Apr 2003 19:46:48 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Sat, 19 Apr 2003 19:46:39 +0200 Subject: Re: [RPSEC] rate limiting management traffic, redux Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rpsec@ietf.org To: Stephen Kent From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On vrijdag, apr 18, 2003, at 22:08 Europe/Amsterdam, Stephen Kent wrote: >> In other words: yes, your integrety check is cheaper than full AH, >> but is it worth the trouble to implement a new protocol in hardware? >> If I were buying crypto hardware, I'd rather have it do full line >> rate IPsec. > No disagreement about what would be ideal, just a matter of complexity > and cost, which I have been told are concerns for some folks :-) They are. Maybe we'll see hardware that can do line rate crypto in some places in the forseeable future, for instance at the edges to protect against denial of service. But I'm pretty confident most people will not be happy doing line rate crypto on a 40 Gbps linecard just to protect a 1 Mbps max BGP session. >> Currently IPsec ESP supports authentication and encryption, maybe >> this could be an additional IPsec service? > ESP mandates support for confidentiality plus integrity, or integrity > only, or confidentiality only. Since the IPsec WG is trying to > simplify the range of options, we're dropping mandatory support for > confidentiality only. I don't see it as likely that we would add an > "authentication tag not tied to the payload" option. Does it make sense to reinvent the wheel here? Especially as we can at least reuse the anti-replay counter and possibly borrow some space from the initialization vector to store the tag. Obviously this mechanism would be entirely optional. > A tag formed from a truncated hash function output has the advantage > that an attacker is not able to see all the output bits to try to work > backwards to the key. But, we have not yet specified the function we > will use to generate the tag, and so it's a bit premature to talk > about whether a truncated output from that unspecified function is > appropriate :-). Agree. I was just pointing out that a bigger tag isn't necessarily better. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Mon Apr 21 08:36:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13584 for ; Mon, 21 Apr 2003 08:36:23 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3LClRf27504 for rpsec-archive@odin.ietf.org; Mon, 21 Apr 2003 08:47:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LClR827501 for ; Mon, 21 Apr 2003 08:47:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13577 for ; Mon, 21 Apr 2003 08:35:53 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197aYq-00003z-00 for rpsec-web-archive@ietf.org; Mon, 21 Apr 2003 08:38:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 197aYp-00003v-00 for rpsec-web-archive@ietf.org; Mon, 21 Apr 2003 08:38:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LCkQ827383; Mon, 21 Apr 2003 08:46:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3LCjf827344 for ; Mon, 21 Apr 2003 08:45:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13516 for ; Mon, 21 Apr 2003 08:34:07 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.12) id 197aX8-000033-00 for RPSEC@ietf.org; Mon, 21 Apr 2003 08:36:30 -0400 Received: from mesa.bbnplanet.com ([171.78.172.21]) by ietf-mx with esmtp (Exim 4.12) id 197aX8-00002x-00 for RPSEC@ietf.org; Mon, 21 Apr 2003 08:36:30 -0400 Received: from localhost (ttauber@localhost) by mesa.bbnplanet.com (8.10.2+Sun/8.10.2) with ESMTP id h3LCaCd09265; Mon, 21 Apr 2003 08:36:12 -0400 (EDT) X-Authentication-Warning: mesa.bbnplanet.com: ttauber owned process doing -bs Date: Mon, 21 Apr 2003 08:36:12 -0400 (EDT) From: Tony Tauber X-X-Sender: ttauber@mesa.bbnplanet.com To: Gregory Lebovitz cc: RPSEC@ietf.org Subject: Re: [RPSEC] Threat model slides from SF? In-Reply-To: <541402FFDC56DA499E7E13329ABFEA87E66BBD@SARATOGA.netscreen.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , On Mon, 7 Apr 2003, Gregory Lebovitz wrote: > It appears Alex' slides from IETF56 made it to the "proceedings" > page, but not the Threat Model slides that Sandy presented. > > Can we get Sandy's slides posted? All, The minutes and all slides have now made it to the IETF Proceedings page and we'll work to get them posted to the rpsec.org website also. Send further comments along if there are any. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Apr 22 03:05:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28396 for ; Tue, 22 Apr 2003 03:05:12 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3M7GcW12685 for rpsec-archive@odin.ietf.org; Tue, 22 Apr 2003 03:16:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M7Gb812682 for ; Tue, 22 Apr 2003 03:16:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28386 for ; Tue, 22 Apr 2003 03:04:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197rrr-0006zn-00 for rpsec-web-archive@ietf.org; Tue, 22 Apr 2003 03:07:03 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 197rrq-0006zj-00 for rpsec-web-archive@ietf.org; Tue, 22 Apr 2003 03:07:02 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M7FA812635; Tue, 22 Apr 2003 03:15:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3M79C812461 for ; Tue, 22 Apr 2003 03:09:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28303 for ; Tue, 22 Apr 2003 02:57:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 197rkf-0006yg-00 for rpsec@ietf.org; Tue, 22 Apr 2003 02:59:37 -0400 Received: from ca-uk-fs.cisco.com ([64.103.66.8]) by ietf-mx with esmtp (Exim 4.12) id 197rkf-0006ya-00 for rpsec@ietf.org; Tue, 22 Apr 2003 02:59:37 -0400 Received: from DRAJNOVI-W2K1.cisco.com (dhcp-rea-gp200-64-103-67-83.cisco.com [64.103.67.83]) by ca-uk-fs.cisco.com (8.11.6+Sun/8.10.2) with ESMTP id h3M6xKh19863; Tue, 22 Apr 2003 07:59:21 +0100 (BST) Message-Id: <4.3.2.7.2.20030422070434.02afb930@ca-uk-fs.cisco.com> X-Sender: drajnovi@ca-uk-fs.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Apr 2003 07:59:19 +0100 To: Vassilis Prevelakis , rpsec@ietf.org From: Damir Rajnovic Subject: Re: [RPSEC] rate limiting management traffic, redux In-Reply-To: <200304180843.h3I8hdBm021704@king.mcs.drexel.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Hello, At 04:43 18/04/2003 -0400, Vassilis Prevelakis wrote: >Your two message scheme exposes router B to replay attacks. I.e. what >is to prevent me from recording the initial packet > nonce_A, new_seq_A, H(secret, nonce_A, new_seq_A) >and sending it to B every now and then? What should A do when it >receives the reply from B? Can I capture A's reply and feed it to >B later on? Valid points. We can add a time stamp to prevent reply attacks. If a packet is older than some_time_period it will be discarded. Let me try again. The proposed exchange may look like this: *) Router A sends: nonce_A, time_stamp_A, new_seq_A, H(secret, nonce_A, tim_stamp_A, new_seq_A) *) After receiving this packet router B will perform the following tests: 1) calculate the hash using his secret that is shared with the router A and compare the result with the hash received in the packet. If they do not match the packet will be rejected. 2) Check the time_stamp_A against its own current time. If it is older than some predefined (or negotiated) time interval the packet will be dropped. If packet passes these checks it will be accepted as a legitimate request from the router A to negotiate a new sequence number and new secret *) After successful verification the router B will send back: nonce_A, nonce_B, new_seq_B, time_stamp_B, H(secret, nonce_A, nonce_B, new_seq_B, time_stamp_B) At the same time router B will set the new shared key to be H(secret, nonce_A, nonce_B). However, it will still accept packets where only the "old secret" was used. *) After receiving this packet the router A will perform the following checks: 1) calculate the hash using his secret that is shared with the router B and compare the result with the hash received in the packet. If they do not match the packet will be rejected. 2) Check the time_stamp_A against its own current time. If it is older than some predefined (or negotiated) time interval the packet will be dropped. *) After successful verification the router A will set its new shared key to be H(secret, nonce_A, nonce_B) Please note that here we can safely drop nonces and use time stamps instead. That can speed calculation of the hash and would not compromise the scheme. >If the process of verifying the incoming message and computing the >reply (new seq num, etc) is expensive, then you also expose B to DOS >attacks. True again. Unfortunately, there is no easy way out of this. You will either perform a superficial check and then accept a packet as genuine or you will spend a bit more time verifying legitimacy of the packet before accepting it. If we can have a check that will provide a satisfactory level of assurance that the packet is legitimate and that will take only 10%-15% (preferably even less) of the total processing time of the packet, then I would classify this as a success IMHO. Gaus ============== Damir Rajnovic , PSIRT Incident Manager, Cisco Systems Telephone: +44 7715 546 033 200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB ============== There are no insolvable problems. The question is can you accept the solution? _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Tue Apr 22 21:31:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03531 for ; Tue, 22 Apr 2003 21:31:25 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3N1hEC28765 for rpsec-archive@odin.ietf.org; Tue, 22 Apr 2003 21:43:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N1hE828762 for ; Tue, 22 Apr 2003 21:43:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03493 for ; Tue, 22 Apr 2003 21:30:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19898N-0006pX-00 for rpsec-web-archive@ietf.org; Tue, 22 Apr 2003 21:33:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19898N-0006pT-00 for rpsec-web-archive@ietf.org; Tue, 22 Apr 2003 21:33:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N1gV828746; Tue, 22 Apr 2003 21:42:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3N1fL828718 for ; Tue, 22 Apr 2003 21:41:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03460 for ; Tue, 22 Apr 2003 21:29:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19896Z-0006p8-00 for rpsec@ietf.org; Tue, 22 Apr 2003 21:31:23 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 19896Z-0006p4-00 for rpsec@ietf.org; Tue, 22 Apr 2003 21:31:23 -0400 Received: from [12.159.173.169] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3N1Ur5w010210; Tue, 22 Apr 2003 21:30:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost (Unverified) Message-Id: In-Reply-To: References: Date: Tue, 22 Apr 2003 21:30:59 -0400 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 7:46 PM +0200 4/19/03, Iljitsch van Beijnum wrote: >... > >>>Currently IPsec ESP supports authentication and encryption, maybe >>>this could be an additional IPsec service? > >>ESP mandates support for confidentiality plus integrity, or >>integrity only, or confidentiality only. Since the IPsec WG is >>trying to simplify the range of options, we're dropping mandatory >>support for confidentiality only. I don't see it as likely that we >>would add an "authentication tag not tied to the payload" option. > >Does it make sense to reinvent the wheel here? Especially as we can >at least reuse the anti-replay counter and possibly borrow some >space from the initialization vector to store the tag. Obviously >this mechanism would be entirely optional. Well, having invented this particular wheel, I am comfortable saying that the sequence number and windowing mechanisms should be reused, but nothing else :-) We're not really reinventing here; we're reusing that mechanism. More seriously, the focus of this proposal is a rate limiting authentication mechanism, and that is not very closely aligned with the security services that IPsec offers. So I do not think it likely that we will add this sort of facility, even as an option, to AH or ESP (said the editor of those documents). Finally, the really hard problem we face is the (re)initialization protocol. This is a difficult problem to solve, since we want to minimize the opportunity for DoS attacks at both ends (so that we can use this between routers, not just between a management station and a router), to a greater extent that existing protocols like IKE (v2). Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Wed Apr 23 13:56:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28109 for ; Wed, 23 Apr 2003 13:56:04 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3NI8Bt14914 for rpsec-archive@odin.ietf.org; Wed, 23 Apr 2003 14:08:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NI8B814911 for ; Wed, 23 Apr 2003 14:08:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28068 for ; Wed, 23 Apr 2003 13:55:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198OUz-0005vt-00 for rpsec-web-archive@ietf.org; Wed, 23 Apr 2003 13:57:37 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 198OUz-0005vq-00 for rpsec-web-archive@ietf.org; Wed, 23 Apr 2003 13:57:37 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NI7F814435; Wed, 23 Apr 2003 14:07:15 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3NI1U813834 for ; Wed, 23 Apr 2003 14:01:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27881 for ; Wed, 23 Apr 2003 13:48:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 198OOm-0005uP-00 for rpsec@ietf.org; Wed, 23 Apr 2003 13:51:12 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 198OOl-0005uM-00 for rpsec@ietf.org; Wed, 23 Apr 2003 13:51:11 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3NHpYE79148; Wed, 23 Apr 2003 19:51:35 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Wed, 23 Apr 2003 10:44:14 +0200 Subject: Re: [RPSEC] rate limiting management traffic, redux Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rpsec@ietf.org To: Stephen Kent From: Iljitsch van Beijnum In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On woensdag, apr 23, 2003, at 03:30 Europe/Amsterdam, Stephen Kent wrote: >> Does it make sense to reinvent the wheel here? Especially as we can >> at least reuse the anti-replay counter and possibly borrow some space >> from the initialization vector to store the tag. Obviously this >> mechanism would be entirely optional. > Well, having invented this particular wheel, I am comfortable saying > that the sequence number and windowing mechanisms should be reused, > but nothing else :-) Any particular reason for this? > More seriously, the focus of this proposal is a rate limiting > authentication mechanism, and that is not very closely aligned with > the security services that IPsec offers. The phrase "rate limiting authentication mechanism" isn't clearly defined (or I'm unaware of this definition) but if you mean something that can effectively rate limit unauthentic traffic to very low levels without impacting authentic traffic, we are in agreement. Now obviously we can't immediately rule out any synergy between the simple authentication mechanism and the full-fledged one that IPsec provides... And in practice I think it's safe to assume (or mandate) that the new scheme will always be used together with ESP authentication or AH. > So I do not think it likely that we will add this sort of facility, > even as an option, to AH or ESP (said the editor of those documents). I don't care all that much what goes in which document, but I'd hate to see this take up unneeded space in the headers. Also, the hardware builders are probably not going to like this as option processing uses up silicon. This wouldn't be a problem for linecards implementing this, but the packets must also be forwarded using the fast path in routers that don't implement this, unless we can be positive that packets containing this option never traverse any routers in the middle. (Which we can't for iBGP.) > Finally, the really hard problem we face is the (re)initialization > protocol. This is a difficult problem to solve, since we want to > minimize the opportunity for DoS attacks at both ends (so that we can > use this between routers, not just between a management station and a > router), to a greater extent that existing protocols like IKE (v2). Does IKE have explicit support for negotiation in the presence of DoS? I guess what we need for this is for the two endpoints to establish some bootstrapping authentication state without actually communicating. This should be doable in the presence of a pre-shared key for this purpose along with something that changes over time in a predictable way (such as the clock...). _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 25 13:46:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16523 for ; Fri, 25 Apr 2003 13:46:30 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PHnhN14526 for rpsec-archive@odin.ietf.org; Fri, 25 Apr 2003 13:49:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PHnh814523 for ; Fri, 25 Apr 2003 13:49:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16496 for ; Fri, 25 Apr 2003 13:45:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1997J2-0002Sa-00 for rpsec-web-archive@ietf.org; Fri, 25 Apr 2003 13:48:16 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1997J1-0002SW-00 for rpsec-web-archive@ietf.org; Fri, 25 Apr 2003 13:48:15 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PHma814494; Fri, 25 Apr 2003 13:48:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PHlS814458 for ; Fri, 25 Apr 2003 13:47:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16461 for ; Fri, 25 Apr 2003 13:43:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1997Gt-0002S0-00 for rpsec@ietf.org; Fri, 25 Apr 2003 13:46:03 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1997Gn-0002RH-00 for rpsec@ietf.org; Fri, 25 Apr 2003 13:45:57 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3PHjZ5w019944; Fri, 25 Apr 2003 13:45:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 25 Apr 2003 13:41:46 -0400 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 10:44 AM +0200 4/23/03, Iljitsch van Beijnum wrote: >On woensdag, apr 23, 2003, at 03:30 Europe/Amsterdam, Stephen Kent wrote: > >>>Does it make sense to reinvent the wheel here? Especially as we >>>can at least reuse the anti-replay counter and possibly borrow >>>some space from the initialization vector to store the tag. >>>Obviously this mechanism would be entirely optional. > >>Well, having invented this particular wheel, I am comfortable >>saying that the sequence number and windowing mechanisms should be >>reused, but nothing else :-) > >Any particular reason for this? Yes, as I noted, ESP or AH compute integrity checks over payloads, whereas ll we need for rate limiting is a function computed over a secret value and a sequence number. That means that we can perform a much faster computation, with an equivalent level of security (relative to working back to find the key). Thus it makes sense to explore this approach vs. just saying "implement a line-rate capable IPsec chip on each interface." > >>More seriously, the focus of this proposal is a rate limiting >>authentication mechanism, and that is not very closely aligned with >>the security services that IPsec offers. > >The phrase "rate limiting authentication mechanism" isn't clearly >defined (or I'm unaware of this definition) but if you mean >something that can effectively rate limit unauthentic traffic to >very low levels without impacting authentic traffic, we are in >agreement. Now obviously we can't immediately rule out any synergy >between the simple authentication mechanism and the full-fledged one >that IPsec provides... And in practice I think it's safe to assume >(or mandate) that the new scheme will always be used together with >ESP authentication or AH. Agreed. > >>So I do not think it likely that we will add this sort of facility, >>even as an option, to AH or ESP (said the editor of those >>documents). > >I don't care all that much what goes in which document, but I'd hate >to see this take up unneeded space in the headers. Also, the >hardware builders are probably not going to like this as option >processing uses up silicon. This wouldn't be a problem for linecards >implementing this, but the packets must also be forwarded using the >fast path in routers that don't implement this, unless we can be >positive that packets containing this option never traverse any >routers in the middle. (Which we can't for iBGP.) Only the destination router needs to look at these values, not intermediate routers. >>Finally, the really hard problem we face is the (re)initialization >>protocol. This is a difficult problem to solve, since we want to >>minimize the opportunity for DoS attacks at both ends (so that we >>can use this between routers, not just between a management station >>and a router), to a greater extent that existing protocols like IKE >>(v2). > >Does IKE have explicit support for negotiation in the presence of DoS? > >I guess what we need for this is for the two endpoints to establish >some bootstrapping authentication state without actually >communicating. This should be doable in the presence of a pre-shared >key for this purpose along with something that changes over time in >a predictable way (such as the clock...). IKE embodies mechanisms to make IT less susceptible to certain forms of DoS attacks. ESP is engineered to be able to process packets in a fashion to minimize opportunities for DoS, but not to the extent that we are discussing here. It's not that the endpoints ought not communicate to establish fresh state (that would be a neat trick!). rather, we want the communication to be such that the responder to a re-init request to expend minimal effort, to avoid using this sort of request as yet another form of DoS. We can ensure (via an extra round trip) that we are having an exchange with a live partner (to reject replays) and we can ensure that after doing a crypto operation that the partner is who it claims to be. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 25 15:50:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20288 for ; Fri, 25 Apr 2003 15:50:15 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PJrUX23089 for rpsec-archive@odin.ietf.org; Fri, 25 Apr 2003 15:53:30 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PJrT823086 for ; Fri, 25 Apr 2003 15:53:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20236 for ; Fri, 25 Apr 2003 15:49:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1999Eh-0003Ag-00 for rpsec-web-archive@ietf.org; Fri, 25 Apr 2003 15:51:55 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1999Eh-0003Ad-00 for rpsec-web-archive@ietf.org; Fri, 25 Apr 2003 15:51:55 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PJqd823006; Fri, 25 Apr 2003 15:52:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PJom822866 for ; Fri, 25 Apr 2003 15:50:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20135 for ; Fri, 25 Apr 2003 15:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1999CC-00039X-00 for rpsec@ietf.org; Fri, 25 Apr 2003 15:49:20 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 1999CB-00039U-00 for rpsec@ietf.org; Fri, 25 Apr 2003 15:49:20 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3PJnpE83436; Fri, 25 Apr 2003 21:49:51 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Fri, 25 Apr 2003 21:49:47 +0200 Subject: Re: [RPSEC] rate limiting management traffic, redux Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rpsec@ietf.org To: Stephen Kent From: Iljitsch van Beijnum In-Reply-To: Message-Id: <11C05686-7757-11D7-9260-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On vrijdag, apr 25, 2003, at 19:41 Europe/Amsterdam, Stephen Kent wrote: >>> Well, having invented this particular wheel, I am comfortable saying >>> that the sequence number and windowing mechanisms should be reused, >>> but nothing else :-) >> Any particular reason for this? > Yes, as I noted, ESP or AH compute integrity checks over payloads, > whereas ll we need for rate limiting is a function computed over a > secret value and a sequence number. That means that we can perform a > much faster computation, with an equivalent level of security > (relative to working back to find the key). Thus it makes sense to > explore this approach vs. just saying "implement a line-rate capable > IPsec chip on each interface." I agree here, but that's not that I was getting at. What I meant was that it makes sense to somehow make this new scheme part of the larger world of IPsec rather than create a new, independent protocol that handles this. >> I don't care all that much what goes in which document, but I'd hate >> to see this take up unneeded space in the headers. Also, the hardware >> builders are probably not going to like this as option processing >> uses up silicon. This wouldn't be a problem for linecards >> implementing this, but the packets must also be forwarded using the >> fast path in routers that don't implement this, unless we can be >> positive that packets containing this option never traverse any >> routers in the middle. (Which we can't for iBGP.) > Only the destination router needs to look at these values, not > intermediate routers. I talked to some vendors at the IETF meeting in Atlanta and they told me that due to the fact that customers demand filtering on TCP/UDP port numbers on all interfaces, their IPv6 ASICs must support following the protocol chain to find the TCP/UDP header, and for this they must know about all the intermediate option headers to some extent, even though the router isn't supposed to look at these. This means that having "strange" options in an IPv6 packet will make said packet take the slow (software) path. So if you want to implement an IPv6 option, be sure to consult with a good number of vendors first to make sure you're not shooting yourself in the foot. Hopefully this problem will go away at some point but I gather it's very real now. I just now realized that we might be talking IPv4 and not IPv6 here. :-) Another way to do this what would work in both IPv4 and IPv6 is encapsulate the whole thing in UDP... >>> Finally, the really hard problem we face is the (re)initialization >>> protocol. >> I guess what we need for this is for the two endpoints to establish >> some bootstrapping authentication state without actually >> communicating. This should be doable in the presence of a pre-shared >> key for this purpose along with something that changes over time in a >> predictable way (such as the clock...). > It's not that the endpoints ought not communicate to establish fresh > state (that would be a neat trick!). rather, we want the communication > to be such that the responder to a re-init request to expend minimal > effort, to avoid using this sort of request as yet another form of > DoS. We can ensure (via an extra round trip) that we are having an > exchange with a live partner (to reject replays) and we can ensure > that after doing a crypto operation that the partner is who it claims > to be. However, if a box goes down and the correspondent is still doing accelerated pre-authentication, the session re-establishement packets probably won't make it through to the CPU. NOT having the pre-auth isn't an attractive option as an attacker can now saturate the path to the CPU. But maybe we don't really have to solve this. Would it be extremely hard to implement a feature that automatically stops traffic being _routed_ towards a router or management station if the management or routing session with this station is down? (Locally source packet should still be allowed through so sessions can be reestablished.) _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Fri Apr 25 16:25:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21485 for ; Fri, 25 Apr 2003 16:25:50 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3PKT5i25565 for rpsec-archive@odin.ietf.org; Fri, 25 Apr 2003 16:29:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKT5825562 for ; Fri, 25 Apr 2003 16:29:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21468 for ; Fri, 25 Apr 2003 16:25:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1999mx-0003Mt-00 for rpsec-web-archive@ietf.org; Fri, 25 Apr 2003 16:27:19 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1999mx-0003Mq-00 for rpsec-web-archive@ietf.org; Fri, 25 Apr 2003 16:27:19 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKR7825465; Fri, 25 Apr 2003 16:27:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3PKQf825435 for ; Fri, 25 Apr 2003 16:26:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21398 for ; Fri, 25 Apr 2003 16:22:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1999kv-0003M2-00 for rpsec@ietf.org; Fri, 25 Apr 2003 16:25:13 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 1999ku-0003Lr-00 for rpsec@ietf.org; Fri, 25 Apr 2003 16:25:12 -0400 Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3PKPB5w000302; Fri, 25 Apr 2003 16:25:12 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <11C05686-7757-11D7-9260-00039388672E@muada.com> References: <11C05686-7757-11D7-9260-00039388672E@muada.com> Date: Fri, 25 Apr 2003 16:22:15 -0400 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 9:49 PM +0200 4/25/03, Iljitsch van Beijnum wrote: >>... > >I agree here, but that's not that I was getting at. What I meant was >that it makes sense to somehow make this new scheme part of the >larger world of IPsec rather than create a new, independent protocol >that handles this. OK, I understand. Let me say why I think it is very unlikely for that to happen. IPsec is trying to remove complexity from implementations, whereas adding this functionality would add complexity. Moreover, the rate-limiting goal for this mechanism is not one that the IPsec WG, or most IPsec customers, see as relevant to the overall set of security features that IPsec offers. Thus I doubt that IPsec would add this feature. > >>>I don't care all that much what goes in which document, but I'd >>>hate to see this take up unneeded space in the headers. Also, the >>>hardware builders are probably not going to like this as option >>>processing uses up silicon. This wouldn't be a problem for >>>linecards implementing this, but the packets must also be >>>forwarded using the fast path in routers that don't implement >>>this, unless we can be positive that packets containing this >>>option never traverse any routers in the middle. (Which we can't >>>for iBGP.) > >>Only the destination router needs to look at these values, not >>intermediate routers. > >I talked to some vendors at the IETF meeting in Atlanta and they >told me that due to the fact that customers demand filtering on >TCP/UDP port numbers on all interfaces, their IPv6 ASICs must >support following the protocol chain to find the TCP/UDP header, and >for this they must know about all the intermediate option headers to >some extent, even though the router isn't supposed to look at these. >This means that having "strange" options in an IPv6 packet will make >said packet take the slow (software) path. > >So if you want to implement an IPv6 option, be sure to consult with >a good number of vendors first to make sure you're not shooting >yourself in the foot. Hopefully this problem will go away at some >point but I gather it's very real now. OK. Then we just need to be defined as "not strange" :-) >I just now realized that we might be talking IPv4 and not IPv6 here. :-) > >Another way to do this what would work in both IPv4 and IPv6 is >encapsulate the whole thing in UDP... yes, that might be an option. > >>>>Finally, the really hard problem we face is the >>>>(re)initialization protocol. > >>>I guess what we need for this is for the two endpoints to >>>establish some bootstrapping authentication state without actually >>>communicating. This should be doable in the presence of a >>>pre-shared key for this purpose along with something that changes >>>over time in a predictable way (such as the clock...). > >>It's not that the endpoints ought not communicate to establish >>fresh state (that would be a neat trick!). rather, we want the >>communication to be such that the responder to a re-init request to >>expend minimal effort, to avoid using this sort of request as yet >>another form of DoS. We can ensure (via an extra round trip) that >>we are having an exchange with a live partner (to reject replays) >>and we can ensure that after doing a crypto operation that the >>partner is who it claims to be. > >However, if a box goes down and the correspondent is still doing >accelerated pre-authentication, the session re-establishement >packets probably won't make it through to the CPU. NOT having the >pre-auth isn't an attractive option as an attacker can now saturate >the path to the CPU. > >But maybe we don't really have to solve this. Would it be extremely >hard to implement a feature that automatically stops traffic being >_routed_ towards a router or management station if the management or >routing session with this station is down? (Locally source packet >should still be allowed through so sessions can be reestablished.) since a correspondent does not always know when its peer has crashed and recovered, our goal is to have a way to re-initialize without involving the CPU, to avoid the problems you cite. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Mon Apr 28 11:23:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04371 for ; Mon, 28 Apr 2003 11:23:27 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3SFS3118527 for rpsec-archive@odin.ietf.org; Mon, 28 Apr 2003 11:28:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SFRh818474 for ; Mon, 28 Apr 2003 11:27:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04341 for ; Mon, 28 Apr 2003 11:22:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AAUs-0003S9-00 for rpsec-web-archive@ietf.org; Mon, 28 Apr 2003 11:24:50 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AAUr-0003S5-00 for rpsec-web-archive@ietf.org; Mon, 28 Apr 2003 11:24:49 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SFPf818334; Mon, 28 Apr 2003 11:25:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3SFO3818260 for ; Mon, 28 Apr 2003 11:24:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04206 for ; Mon, 28 Apr 2003 11:18:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AARK-0003Qg-00 for rpsec@ietf.org; Mon, 28 Apr 2003 11:21:10 -0400 Received: from sequoia.muada.com ([213.156.1.123]) by ietf-mx with esmtp (Exim 4.12) id 19AARJ-0003Qa-00 for rpsec@ietf.org; Mon, 28 Apr 2003 11:21:10 -0400 Received: from muada.com (sequoia.muada.com [213.156.1.123]) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id h3SFLjE92320; Mon, 28 Apr 2003 17:21:45 +0200 (CEST) (envelope-from iljitsch@muada.com) Date: Mon, 28 Apr 2003 17:21:42 +0200 Subject: Re: [RPSEC] rate limiting management traffic, redux Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: rpsec@ietf.org To: Stephen Kent From: Iljitsch van Beijnum In-Reply-To: Message-Id: <1DB0DE60-798D-11D7-B0FF-00039388672E@muada.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On vrijdag, apr 25, 2003, at 22:22 Europe/Amsterdam, Stephen Kent wrote: >> I agree here, but that's not that I was getting at. What I meant was >> that it makes sense to somehow make this new scheme part of the >> larger world of IPsec rather than create a new, independent protocol >> that handles this. > OK, I understand. Let me say why I think it is very unlikely for that > to happen. IPsec is trying to remove complexity from implementations, > whereas adding this functionality would add complexity. Ok, not doing this is less complex than doing it. The real question is whether implementing the pre-authentication is more complex with or without IPsec. I think it could very well be the former. >> So if you want to implement an IPv6 option, be sure to consult with a >> good number of vendors first to make sure you're not shooting >> yourself in the foot. Hopefully this problem will go away at some >> point but I gather it's very real now. > OK. Then we just need to be defined as "not strange" :-) Good luck doing that for the installed base. (-: >> But maybe we don't really have to solve this. Would it be extremely >> hard to implement a feature that automatically stops traffic being >> _routed_ towards a router or management station if the management or >> routing session with this station is down? (Locally source packet >> should still be allowed through so sessions can be reestablished.) > since a correspondent does not always know when its peer has crashed > and recovered, our goal is to have a way to re-initialize without > involving the CPU, to avoid the problems you cite. Re-initialize without involving the CPU... Talk about neat tricks! Detecting failures is usually done with periodic keepalives. I don't see why this can't work here. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From mailnull@www1.ietf.org Wed Apr 30 17:55:40 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25467 for ; Wed, 30 Apr 2003 17:55:40 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h3UM1Ox09999 for rpsec-archive@odin.ietf.org; Wed, 30 Apr 2003 18:01:24 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UM1O809957 for ; Wed, 30 Apr 2003 18:01:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25441 for ; Wed, 30 Apr 2003 17:55:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AzZp-0003vf-00 for rpsec-web-archive@ietf.org; Wed, 30 Apr 2003 17:57:21 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19AzZo-0003vb-00 for rpsec-web-archive@ietf.org; Wed, 30 Apr 2003 17:57:20 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3UM0L804487; Wed, 30 Apr 2003 18:00:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h3ULwM804089 for ; Wed, 30 Apr 2003 17:58:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25354 for ; Wed, 30 Apr 2003 17:52:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19AzWu-0003uV-00 for rpsec@ietf.org; Wed, 30 Apr 2003 17:54:20 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 19AzWj-0003u1-00 for rpsec@ietf.org; Wed, 30 Apr 2003 17:54:09 -0400 Received: from [10.81.114.236] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h3ULrk5w028410; Wed, 30 Apr 2003 17:53:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <1DB0DE60-798D-11D7-B0FF-00039388672E@muada.com> References: <1DB0DE60-798D-11D7-B0FF-00039388672E@muada.com> Date: Wed, 30 Apr 2003 17:53:08 -0400 To: Iljitsch van Beijnum From: Stephen Kent Subject: Re: [RPSEC] rate limiting management traffic, redux Cc: rpsec@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: rpsec-admin@ietf.org Errors-To: rpsec-admin@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Protocol Security Requirements List-Post: List-Help: List-Subscribe: , At 5:21 PM +0200 4/28/03, Iljitsch van Beijnum wrote: >On vrijdag, apr 25, 2003, at 22:22 Europe/Amsterdam, Stephen Kent wrote: > >>>I agree here, but that's not that I was getting at. What I meant >>>was that it makes sense to somehow make this new scheme part of >>>the larger world of IPsec rather than create a new, independent >>>protocol that handles this. > >>OK, I understand. Let me say why I think it is very unlikely for >>that to happen. IPsec is trying to remove complexity from >>implementations, whereas adding this functionality would add >>complexity. > >Ok, not doing this is less complex than doing it. The real question >is whether implementing the pre-authentication is more complex with >or without IPsec. I think it could very well be the former. I don't see why you say this. The only thing we are reusing from IPsec is the anti-replay mechanism. The authentication tag is not really related to what we do in AH or ESP. > >>>So if you want to implement an IPv6 option, be sure to consult >>>with a good number of vendors first to make sure you're not >>>shooting yourself in the foot. Hopefully this problem will go away >>>at some point but I gather it's very real now. > >>OK. Then we just need to be defined as "not strange" :-) > >Good luck doing that for the installed base. (-: Well, as you suggested, the best bet is probably to encapsulate the traffic, so that intermediate systems do not see any reason to examine the packets more closely. > >>>But maybe we don't really have to solve this. Would it be >>>extremely hard to implement a feature that automatically stops >>>traffic being _routed_ towards a router or management station if >>>the management or routing session with this station is down? >>>(Locally source packet should still be allowed through so sessions >>>can be reestablished.) > >>since a correspondent does not always know when its peer has >>crashed and recovered, our goal is to have a way to re-initialize >>without involving the CPU, to avoid the problems you cite. > >Re-initialize without involving the CPU... Talk about neat tricks! > >Detecting failures is usually done with periodic keepalives. I don't >see why this can't work here. Your observation suggests a possible, hybrid approach. For peer router management communication (e.g., BGP), one could rely on higher level detection of failure as a precursor to initiating a response to a resynch message. But for management communication between a router and a management station, where we don't have as good info about router status, we might be more willing to process a resynch, because the management station has the resources to devote to this. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec