From rpsec-bounces@ietf.org Mon Mar 06 02:50:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGATt-0006WW-Gr; Mon, 06 Mar 2006 02:50:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGATm-0006S1-9U; Mon, 06 Mar 2006 02:50:06 -0500 Received: from [156.154.16.129] (helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGATh-0003e1-MQ; Mon, 06 Mar 2006 02:50:06 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k267o10e004159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Mar 2006 07:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FGATh-0008Jj-8P; Mon, 06 Mar 2006 02:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 06 Mar 2006 02:50:01 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: rpsec@ietf.org Subject: [RPSEC] I-D ACTION:draft-ietf-rpsec-bgpsecrec-04.txt X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Protocol Security Requirements Working Group of the IETF. Title : BGP Security Requirements Author(s) : B. Christian, T. Tauber Filename : draft-ietf-rpsec-bgpsecrec-04.txt Pages : 18 Date : 2006-3-5 The security of BGP, the Border Gateway Protocol, is critical to the proper operation of large-scale internetworks, both public and private. While securing the information transmitted between two BGP speakers is a relatively easy technical matter, securing BGP, as a routing system, is more complex. This document describes a set of requirements for securing BGP, including communications between BGP speakers, and the routing information carried within BGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-bgpsecrec-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rpsec-bgpsecrec-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rpsec-bgpsecrec-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-3-5180921.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rpsec-bgpsecrec-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rpsec-bgpsecrec-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-5180921.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --NextPart-- From rpsec-bounces@ietf.org Tue Mar 21 17:32:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpOP-0003nr-4i; Tue, 21 Mar 2006 17:31:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpOO-0003nm-4A for rpsec@ietf.org; Tue, 21 Mar 2006 17:31:56 -0500 Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpOM-0007Km-Pp for rpsec@ietf.org; Tue, 21 Mar 2006 17:31:56 -0500 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id OAA22194; Tue, 21 Mar 2006 14:31:53 -0800 (PST) Received: from manavLpt ([10.128.16.204]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 14:31:52 -0800 Message-ID: <00e301c64d37$3cd57540$38858182@rs.riverstonenet.com> From: "Manav Bhatia" To: Date: Wed, 22 Mar 2006 04:01:41 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 21 Mar 2006 22:31:52.0858 (UTC) FILETIME=[409367A0:01C64D37] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [RPSEC] draft-bonica-tcp-auth-04 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Hi Ron, Is there really a need to send the "Alg ID" (identifying the MAC algorithm) in the TCP Enhanced Authentication Option? The receiving TCP would associate the inbound TCP segment with a local key-chain based upon source IP, dest IP, source port and dest port. It would then search the associated key-chain for a key whose identifier matches that which was specified by the incoming TCP segment option. If the key returned is valid then the receiving TCP can figure out the algorithm from the key itself, and use that to calculate the MAC. If so, then why do we need to send the Algorithm details in the TCP option? Cheers, Manav _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 21 17:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpac-0005Rv-Q5; Tue, 21 Mar 2006 17:44:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpab-0005OE-LV for rpsec@ietf.org; Tue, 21 Mar 2006 17:44:33 -0500 Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpaa-0007v4-7U for rpsec@ietf.org; Tue, 21 Mar 2006 17:44:33 -0500 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id OAA23456; Tue, 21 Mar 2006 14:44:31 -0800 (PST) Received: from manavLpt ([10.128.16.207]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 14:44:29 -0800 Message-ID: <000c01c64d38$ffe19900$38858182@rs.riverstonenet.com> From: "Manav Bhatia" To: References: <00e301c64d37$3cd57540$38858182@rs.riverstonenet.com> Subject: Re: [RPSEC] draft-bonica-tcp-auth-04 Date: Wed, 22 Mar 2006 04:14:17 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 21 Mar 2006 22:44:30.0568 (UTC) FILETIME=[0434C680:01C64D39] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Ok. I got it sorted out. You do it because you don't even need to calculate the MAC if the Algo ID that you receive in the pkt doesn't match with the SA that you have. Saves you from unnecessarily wasting CPU cycles. Fair enough. Cheers, Manav ----- Original Message ----- From: "Manav Bhatia" To: <> Sent: Wednesday, March 22, 2006 4:01 AM Subject: [RPSEC] draft-bonica-tcp-auth-04 > Hi Ron, > > Is there really a need to send the "Alg ID" (identifying the MAC > algorithm) in the TCP Enhanced Authentication Option? > > The receiving TCP would associate the inbound TCP segment with a local > key-chain based upon source IP, dest IP, source port and dest port. It > would then search the associated key-chain for a key whose identifier > matches that which was specified by the incoming TCP segment option. If > the key returned is valid then the receiving TCP can figure out the > algorithm from the key itself, and use that to calculate the MAC. > > If so, then why do we need to send the Algorithm details in the TCP > option? > > Cheers, > Manav > > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 21 18:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpuv-0003No-Ep; Tue, 21 Mar 2006 18:05:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLput-0003Nj-Ng for rpsec@ietf.org; Tue, 21 Mar 2006 18:05:31 -0500 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpur-000051-Ok for rpsec@ietf.org; Tue, 21 Mar 2006 18:05:31 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=QT8BTV1NrHHK3WbMtGZeyuvWeMQXo7j8HJ2Frgs0EZ52bNYWMtYrsiJcvPMtt10O; h=Received:Message-Id:X-Sender:X-Mailer:Date:To:From:Subject:In-Reply-To:References:Mime-Version:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [130.129.132.69] (helo=gregory-lt.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.34) id 1FLpun-0000wh-3g; Tue, 21 Mar 2006 18:05:26 -0500 Message-Id: <6.1.2.0.0.20060321150324.044d8eb0@mail.earthlink.net> X-Sender: gregory-ietf@earthlink.net@mail.earthlink.net X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Tue, 21 Mar 2006 15:05:22 -0800 To: "Manav Bhatia" , From: Gregory M Lebovitz Subject: Re: [RPSEC] draft-bonica-tcp-auth-04 In-Reply-To: <000c01c64d38$ffe19900$38858182@rs.riverstonenet.com> References: <00e301c64d37$3cd57540$38858182@rs.riverstonenet.com> <000c01c64d38$ffe19900$38858182@rs.riverstonenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: bb75549d41bf6763a56c75a03b4135ad4d2b10475b571120d572b6770bdd550fae1175f334a499183788860f0b40a802350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.132.69 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org wouldn't a successful attack then be to send a lot of packets with the valid Algo ID, so the peer matches the Algo ID, and continues to process the digest, only to find it worthless? At 02:44 PM 3/21/2006, Manav Bhatia wrote: >Ok. I got it sorted out. You do it because you don't even need to >calculate the MAC if the Algo ID that you receive in the pkt doesn't match >with the SA that you have. > >Saves you from unnecessarily wasting CPU cycles. > >Fair enough. > >Cheers, >Manav >----- Original Message ----- From: "Manav Bhatia" >To: <> >Sent: Wednesday, March 22, 2006 4:01 AM >Subject: [RPSEC] draft-bonica-tcp-auth-04 > > >>Hi Ron, >> >>Is there really a need to send the "Alg ID" (identifying the MAC >>algorithm) in the TCP Enhanced Authentication Option? >> >>The receiving TCP would associate the inbound TCP segment with a local >>key-chain based upon source IP, dest IP, source port and dest port. It >>would then search the associated key-chain for a key whose identifier >>matches that which was specified by the incoming TCP segment option. If >>the key returned is valid then the receiving TCP can figure out the >>algorithm from the key itself, and use that to calculate the MAC. >> >>If so, then why do we need to send the Algorithm details in the TCP option? >> >>Cheers, >>Manav >> >> >>_______________________________________________ >>RPSEC mailing list >>RPSEC@ietf.org >>https://www1.ietf.org/mailman/listinfo/rpsec > > > >_______________________________________________ >RPSEC mailing list >RPSEC@ietf.org >https://www1.ietf.org/mailman/listinfo/rpsec _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 21 18:19:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLq80-000140-0c; Tue, 21 Mar 2006 18:19:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLq7z-00013n-1N for rpsec@ietf.org; Tue, 21 Mar 2006 18:19:03 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLq7x-0000P3-Rn for rpsec@ietf.org; Tue, 21 Mar 2006 18:19:03 -0500 Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.130.184]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FLq7w-0005jS-5J; Tue, 21 Mar 2006 18:19:01 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <00e301c64d37$3cd57540$38858182@rs.riverstonenet.com> References: <00e301c64d37$3cd57540$38858182@rs.riverstonenet.com> Date: Tue, 21 Mar 2006 17:59:57 -0500 To: "Manav Bhatia" From: Stephen Kent Subject: Re: [RPSEC] draft-bonica-tcp-auth-04 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 4:01 AM +0530 3/22/06, Manav Bhatia wrote: >Hi Ron, > >Is there really a need to send the "Alg ID" (identifying the MAC >algorithm) in the TCP Enhanced Authentication Option? the security area is very insistent on algorithm agility, so putting the alg ID into the option satisfies this requirement. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 21 18:46:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqYV-0004Rd-3k; Tue, 21 Mar 2006 18:46:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLqYT-0004P8-U6 for rpsec@ietf.org; Tue, 21 Mar 2006 18:46:25 -0500 Received: from generic.riverstonenet.com ([66.17.149.13] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLqYS-0001gQ-GK for rpsec@ietf.org; Tue, 21 Mar 2006 18:46:25 -0500 Received: from legolas.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id PAA00376; Tue, 21 Mar 2006 15:46:22 -0800 (PST) Received: from manavLpt ([10.128.16.180]) by legolas.rs.riverstonenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 15:46:20 -0800 Message-ID: <002101c64d41$a2153670$20fe3bce@rs.riverstonenet.com> From: "Manav Bhatia" To: , "Gregory M Lebovitz" References: <00e301c64d37$3cd57540$38858182@rs.riverstonenet.com> <000c01c64d38$ffe19900$38858182@rs.riverstonenet.com> <6.1.2.0.0.20060321150324.044d8eb0@mail.earthlink.net> Subject: Re: [RPSEC] draft-bonica-tcp-auth-04 Date: Wed, 22 Mar 2006 05:15:38 +0530 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 21 Mar 2006 23:46:21.0879 (UTC) FILETIME=[A851E470:01C64D41] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Having the Algo ID in the TCP option helps us in the cases where the algo ID carried in the pkt is different from the one specified in the SA. We just drop such pkts. Its not much of an optimization as there only a few values defined for this field and an attacker can send pkts by randomly filling those 'valid' values in this particular field. Manav ----- Original Message ----- From: "Gregory M Lebovitz" To: "Manav Bhatia" ; Sent: Wednesday, March 22, 2006 4:35 AM Subject: Re: [RPSEC] draft-bonica-tcp-auth-04 > wouldn't a successful attack then be to send a lot of packets with the > valid Algo ID, so the peer matches the Algo ID, and continues to process > the digest, only to find it worthless? > > At 02:44 PM 3/21/2006, Manav Bhatia wrote: >>Ok. I got it sorted out. You do it because you don't even need to >>calculate the MAC if the Algo ID that you receive in the pkt doesn't match >>with the SA that you have. >> >>Saves you from unnecessarily wasting CPU cycles. >> >>Fair enough. >> >>Cheers, >>Manav >>----- Original Message ----- From: "Manav Bhatia" >> >>To: <> >>Sent: Wednesday, March 22, 2006 4:01 AM >>Subject: [RPSEC] draft-bonica-tcp-auth-04 >> >> >>>Hi Ron, >>> >>>Is there really a need to send the "Alg ID" (identifying the MAC >>>algorithm) in the TCP Enhanced Authentication Option? >>> >>>The receiving TCP would associate the inbound TCP segment with a local >>>key-chain based upon source IP, dest IP, source port and dest port. It >>>would then search the associated key-chain for a key whose identifier >>>matches that which was specified by the incoming TCP segment option. If >>>the key returned is valid then the receiving TCP can figure out the >>>algorithm from the key itself, and use that to calculate the MAC. >>> >>>If so, then why do we need to send the Algorithm details in the TCP >>>option? >>> >>>Cheers, >>>Manav >>> >>> >>>_______________________________________________ >>>RPSEC mailing list >>>RPSEC@ietf.org >>>https://www1.ietf.org/mailman/listinfo/rpsec >> >> >> >>_______________________________________________ >>RPSEC mailing list >>RPSEC@ietf.org >>https://www1.ietf.org/mailman/listinfo/rpsec > > _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 21 19:19:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLr4V-0007uO-TC; Tue, 21 Mar 2006 19:19:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLr4U-0007uI-CK for rpsec@ietf.org; Tue, 21 Mar 2006 19:19:30 -0500 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLr4T-0003iz-64 for rpsec@ietf.org; Tue, 21 Mar 2006 19:19:30 -0500 Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.130.184]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FLr4R-0003Zy-6L; Tue, 21 Mar 2006 19:19:28 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <001e01c64d40$c0e1d870$20fe3bce@rs.riverstonenet.com> References: <00e301c64d37$3cd57540$38858182@rs.riverstonenet.com> <001e01c64d40$c0e1d870$20fe3bce@rs.riverstonenet.com> Date: Tue, 21 Mar 2006 19:18:04 -0500 To: "Manav Bhatia" From: Stephen Kent Subject: Re: [RPSEC] draft-bonica-tcp-auth-04 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org At 5:09 AM +0530 3/22/06, Manav Bhatia wrote: >How different would the agility be if you don't advertise the algo >ID and instead let the receiver look at its SA to figure out what >algo to use? > >Manav I assume you mean the key ID that defines which key to use. That should work too, but it creates the opportunity to have each end be confused about which alg to employ with a given key ID, and no explicit declaration (on the wire) about which alg the sender thinks both ends should be using. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Mar 21 20:42:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsN8-0003i4-NO; Tue, 21 Mar 2006 20:42:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLsN7-0003hz-CF for rpsec@ietf.org; Tue, 21 Mar 2006 20:42:49 -0500 Received: from xproxy.gmail.com ([66.249.82.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLsN7-0006Gf-4H for rpsec@ietf.org; Tue, 21 Mar 2006 20:42:49 -0500 Received: by xproxy.gmail.com with SMTP id s14so23339wxc for ; Tue, 21 Mar 2006 17:42:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=aiAogjHD3yJHxqutPagFqqUDcBUbo9zzrg9SyTG3LqYtCV4cXAp1o5u/EM1IjWs+gMH+NVLJs0kqEvEzHTpv4g6gBNJe2FJppnUqXckkiPv9KFvVHZNP1lqnabFVZHzZYU72Vajp78TW6J/BZNk/Kd9s+pxYqEq9GrE3JuMtcH4= Received: by 10.70.33.6 with SMTP id g6mr348333wxg; Tue, 21 Mar 2006 17:42:48 -0800 (PST) Received: by 10.70.7.2 with HTTP; Tue, 21 Mar 2006 17:42:48 -0800 (PST) Message-ID: <77ead0ec0603211742p215d73c3p9a5c471ffc48f0db@mail.gmail.com> Date: Tue, 21 Mar 2006 17:42:48 -0800 From: "Vishwas Manral" To: "Stephen Kent" Subject: Re: [RPSEC] draft-bonica-tcp-auth-04 In-Reply-To: MIME-Version: 1.0 References: <00e301c64d37$3cd57540$38858182@rs.riverstonenet.com> <001e01c64d40$c0e1d870$20fe3bce@rs.riverstonenet.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: rpsec@ietf.org X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0329181252==" Errors-To: rpsec-bounces@ietf.org --===============0329181252== Content-Type: multipart/alternative; boundary="----=_Part_3039_19337832.1142991768673" ------=_Part_3039_19337832.1142991768673 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, An advantage I see with using Key Id is that incase we have multiple keys configured(in case of Key rollover), we only need to verify the packet with the key associated with the Key Id. Not doing this can cause unnecessary wastage of CPU cycles. It can also amplify the attack during keyRollover when multiple keys are configured and random packets are sent in. By keeping the semantics of Key Id(which can be unique across all algorithms) we get a degree of opaqueness. Thanks, Vishwas On 3/21/06, Stephen Kent wrote: > > At 5:09 AM +0530 3/22/06, Manav Bhatia wrote: > >How different would the agility be if you don't advertise the algo > >ID and instead let the receiver look at its SA to figure out what > >algo to use? > > > >Manav > > I assume you mean the key ID that defines which key to use. > > That should work too, but it creates the opportunity to have each end > be confused about which alg to employ with a given key ID, and no > explicit declaration (on the wire) about which alg the sender thinks > both ends should be using. > > Steve > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > ------=_Part_3039_19337832.1142991768673 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

An advantage I see with using Key Id is that incase we have multiple keys configured(in case of Key rollover), we only need to verify the packet with the key associated with the Key Id.

Not doing this can cause unnecessary wastage of CPU cycles. It can also amplify the attack during keyRollover when multiple keys are configured and random packets are sent in.

By keeping the semantics of Key Id(which can be unique across all algorithm= s) we get a degree of opaqueness.

Thanks,
Vishwas

On 3/21/06, Stephen Kent <kent@bb= n.com> wrote:
At 5:09 AM +0530 3/22/06, Manav Bhatia wrote:
>How different would th= e agility be if you don't advertise the algo
>ID and instead let the = receiver look at its SA to figure out what
>algo to use?
>
>Manav

I assume you mean the key ID that defines which key to use= .

That should work too, but it creates the opportunity to have each = end
be confused about which alg to employ with a given key ID, and no
explicit declaration (on the wire) about which alg the sender thinksboth ends should be using.

Steve

___________________________= ____________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec
=
------=_Part_3039_19337832.1142991768673-- --===============0329181252== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec --===============0329181252==-- From rpsec-bounces@ietf.org Fri Mar 24 21:58:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMyyd-0007eU-4b; Fri, 24 Mar 2006 21:58:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMyyb-0007SD-Lg for rpsec@ietf.org; Fri, 24 Mar 2006 21:58:05 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMyyb-0008G0-1a for rpsec@ietf.org; Fri, 24 Mar 2006 21:58:05 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k2P2w45X027159 for ; Fri, 24 Mar 2006 18:58:04 -0800 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) with ESMTP id k2P2w4c9027156 for ; Fri, 24 Mar 2006 18:58:04 -0800 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Fri, 24 Mar 2006 18:58:04 -0800 (PST) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: rpsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Subject: [RPSEC] Minutes from IETF-65 (Dallas) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Please write in with any corrections by March 31. Thanks, Tony --- Routing Protocol Security Requirements WG (rpsec) Tuesday, March 21 at 1520-1720 Cortez AB ======================================== CHAIRS: Russ White Tony Tauber AGENDA: Agenda Bashing and Administrivia Old Document Status Generic Threats OSPF Vulnerabilities BGP Attack Tree BGP Security Requirements T. Tauber draft-ietf-rpsec-bgpsecrec-04 Authentication for TCP-based Routing and Management Protocols draft-bonica-tcp-auth-04 R. Bonica Charter update and futures discussion R. White --- Minutes --- Agenda Bashing (Tony) No changes from the published agenda. Old Work (Tony) Generic Threats Hit an administrative speed-bump w/in the RFC-Editor's Queue. Looks like it should be shaken loose soon. ADs will help. Pekka Savola: Looks like it was deleted from the editor's queue. Tony: We'll get it fixed. OSPF Vulnerabilities Analysis done by Emanuele Jones, et. al. expired. We'll look at re-submitting and getting it published as Informational. BGP Attack Tree Analysis done by Sean Convery, Dave Cook, Michael Franz. Similarly, bring it to the list, see if there are comments/etc. If not, possibly last call it, and be done with it. BGP Security Requirements (Tony) (See Presentation slides) SIDR BOF/WG-to-be is waiting for consensus output to begin. === Consensus call: How should we proceed? Is there concensus on the draft outside the AS Path considerations? 4 or 5 How many are opposed? 1 Sense of the room is the draft is okay as it is, outside the AS Path Leave AS Path in, but state there is no consensus on the AS Path parts of the draft? Sense of the room is this is the correct path === Describe these results on the list. Steve Kent has submitted some mark-up so the doc may be revised with these changes and the change to call out the AS_Path issues as not having consent. Authentication for TCP Based Routing Protocols (Ron Bonica) (See presentation slides.) Steve Kent: To clarify, the keys used in IPsec are authentication keys, the keys we are talking about in this solution are different. Rolling over identification keys is possible with existing systems. SK: Chains of keys have the same exposure possibility as preshared keys used for the life of the BGP session. Ron Bonica: We are trying to solve the problem of how long these keys are used. SK: How long do these session stay up? Tony Tauber: Months SK: There's no requirement to kill the child SAs when you swap keys. When you create a new child SA you would normally establish a new child SA, and the traffic would migrate to the new SA when the old one times out. Ron: Had we gone the ipsec route, if we change the key on one side, and not the other side, and something causes the SA to bounce. SK: Only two things will cause that: The SA times out, one side or the other side crashes. If the key is changed on one side, and the other side times the SA out, we are out of business until the keys are changed. Alex Zinin: Let's continue the slides, and continue this discussion later Greg Lebovitz: Why is TLS problematic? Ron: The attacks we're trying to gaurd against are against TCP (e.g. forged resets), rather than BGP. If TCP can be forced into an ACK war, it can take minutes for BGP to recover, so we need to protect TCP. Greg: TLS has the concept of contexts, the flow is considered part of a flow context. If TCP resets, the BGP session could be recovered from the context state. Wouldn't this be a feature. Ron: We would have to define BGP and others (LDP, etc) over TLS. Steve: The receiver is making a choice between keys and some timing checks. This implies some level of time synchronization between the peer routers. If you have a large number of peers, this turns into a requirement to maintain time among all the peers on a per peer basis. Ron: This is why the keychain has a start and end time for sending and receiving. If you believe the peers have fairly synchronized times, you can set the end time to some time in the future, so that the receiver will accept the key for a long time. Steve: In which case you're dependant on the other peer to change keys, if both peers have bad time, then the keys won't ever change. Ron: The sender always determines which key is used. The sender can switch keys, since the sender chooses which key the receiver should accept. Steve: I'll ask the question again in a different fashion. If both peers have problems with keeping clock straight, is there any safe algorithm to ever take a key out? Ron: There is a potential problem. If clocks are skewed by months or years. There's no way to know for the receiver to know when it's safe to delete a key from the keychain. Steve: This raises questions about how far this is from a system where the sender just arbitrarily chooses which key to use. You've had to take the time element and make it almost a no-op. It's going to take a lot of effort when writing the operational guidance or security considerations what the assumptions are. Ross Callon: How useful is it to worry about clocks that are off 20 years. The document should clearly state that you should have your clocks to within some period of time if this is going to be useful. Ron: I think it's reasonable to put something in the security considerations section stating the clocks must be within some degree of coordination. Dave Ward: This doc is useful, the clock stuff we run into in all the protocols. There is a draft I wrote a couple of years ago on how to secure BGP with IPsec, but not all routing protocols can run on IPsec, so that isn't a complete solution. Alex: It is reasonable to assume the clocks on routers will be synchronized within minutes or hours. I'm in favor, being a prime contributor. Geoff Huston: If you have a peering session not coming up, you don't normally look at the time of day. There should be some pointer in implementations to look at the time if there's a failure; a notification to the Operator to indicate what the error was (e.g., time out of range.) Greg: A comment on IPsec with preshared keys. The only preshared key large scale IPsec systems that work are vendor proprietary. It's operationally infeasible to believe that interdomain routing will be able to use preshared keys and be able to roll over those keys in an automated fashion. Certificates could be used to make this a nonproblem, with a little more work. See work going on in the PKI4IPSEC Working Group. Chris Hopps: Is it envisioned that you will configure large keychains that will slowly roll keys over time, or are you looking at transitioning keys over time. Ron: A keychain normally can hold 64 keys, so the most would be about 2 months. Chris Hopps: So it's not reaction? Ron: There is a mechanism to handle the situation where you believe your keys have been compromised you can roll your keys now. Andrew Dul: We would have to reconfigure the keychain every two months? Ron: How often do you want to do it? Keys are easier to break the more you use them. There's an RFC that talks about how often you should roll your keys if you're using MD5. Andrew: As an operator, I don't want to touch my routers every 2 months to roll keys. Ron: You could use a time of about 10 days, and touch them once a year. === Next Steps: === Since the changes here would be to TCP, the thing to do would be have RPSEC recommend to the TCPM Working Group to take on this work. RPsec Charter Update - Russ White (See presentation slides.) Consensus call: === Do these look like these are the right things? Four or Five Hands Not the right direction? Crickets === _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sun Mar 26 22:52:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNimP-0006bs-MI; Sun, 26 Mar 2006 22:52:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNimN-0006bn-Rk for rpsec@ietf.org; Sun, 26 Mar 2006 22:52:31 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNimM-00082S-FA for rpsec@ietf.org; Sun, 26 Mar 2006 22:52:31 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.6/8.13.6) with ESMTP id k2R3qTm6010398 for ; Sun, 26 Mar 2006 19:52:29 -0800 Received: from localhost (ttauber@localhost) by m106.maoz.com (8.13.6/8.12.11/Submit) with ESMTP id k2R3qToA010395 for ; Sun, 26 Mar 2006 19:52:29 -0800 X-Authentication-Warning: m106.maoz.com: ttauber owned process doing -bs Date: Sun, 26 Mar 2006 19:52:29 -0800 (PST) From: Tony Tauber X-X-Sender: ttauber@m106.maoz.com To: rpsec@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [RPSEC] Consensus/Action Calls from IETF-65 (Dallas) X-BeenThere: rpsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing Protocol Security Requirements List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: rpsec-bounces@ietf.org Hi folks, These items were buried within the minutes I posted but I wanted to draw people's attention to them. If there are comments or concerns, send them along. Thanks, Tony ---- > BGP Security Requirements (Tony) > (See Presentation slides) > SIDR BOF/WG-to-be is waiting for consensus output to begin. > === > Consensus call: How should we proceed? > Is there concensus on the draft outside the AS Path considerations? > 4 or 5 > How many are opposed? > 1 > Sense of the room is the draft is okay as it is, outside the AS Path > Leave AS Path in, but state there is no consensus on the AS Path > parts of the draft? > Sense of the room is this is the correct path > === > Authentication for TCP Based Routing Protocols (Ron Bonica) > (See presentation slides.) > === > Next Steps: > === > Since the changes here would be to TCP, the thing to do would be > have RPSEC recommend to the TCPM Working Group to take on this work. > RPsec Charter Update - Russ White > (See presentation slides.) > Consensus call: > === > Do these look like these are the right things? > Four or Five Hands > Not the right direction? > Crickets > === _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec