From rpsec-bounces@ietf.org Wed Feb 01 14:24:55 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Nb5-0006Lg-Gs; Wed, 01 Feb 2006 14:24:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Nb3-0006J0-KQ for rpsec@megatron.ietf.org; Wed, 01 Feb 2006 14:24:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23906 for ; Wed, 1 Feb 2006 14:23:17 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4NmH-0000p1-4d for rpsec@ietf.org; Wed, 01 Feb 2006 14:36:30 -0500 Received: from [198.202.64.53] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k11JOcIC014865; Wed, 1 Feb 2006 14:24:39 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43DE5D48.6010902@cisco.com> References: <03235919BBDE634289BB6A0758A20B36357E37@NT-SJCA-0751.brcm.ad.broadcom.com> <43DE5D48.6010902@cisco.com> Date: Wed, 1 Feb 2006 14:19:13 -0500 To: Brian Weis From: Stephen Kent Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 10:39 AM -0800 1/30/06, Brian Weis wrote: >Merike Kaeo wrote: >>While it is true that pre-shared key roll-over is the same problem >>as changing the MD-5 keys used in today's non-IPsec authentication >>implementations, IPsec works a bit differently. The pre-shared >>key is used to originally authenticate the communicating peers >>(i.e. the Diffie-Hellman exchange) which then results in a shared >>secret. This shared secret is then used to derive the actual key >>used for the MD-5 or SHA-1 authentication used in IPsec. These >>authentication keys are refreshed based on a defined lifetime, >>which is the so-called 'automated' key rollover. > >The real roll-over problem is that an IPsec system can have only one >valid IPsec pre-shared key for each peer, and if the two peers >disagree on the value of the current key at any point in time the >connection will fail. The pre-shared key in IPsec (really IKE) is for authentication of an IKE SA. The key used to protect traffic (integrity and confidentiality) is the result of a ephemeral DH exchange, and is thus unique per SA. Also, multiple SAs between a pair of peers is supported. If the IKE authentication key is changed at one peer during the life of an SA, that does not affect the extent SA. Given this more detailed characterization of keying for IPsec, I'm not sure what aspects of IPsec keying you were alluding to above. >What Merike describes above shows that that once authentication >completes, there is usually a few hours before it gets used again. >Under ordinary circumstances, this gives the operations staffs of >the two peers a period of a few hours to synchronize changing the >key. But if one peer unexpectedly has a need to re-authenticate when >only one side has installed the new key, they won't be able to bring >up the BGP session just as in the case when keyed-MD5 authentication >keys are different. AH, this is what you were trying to say! Yes, if one peer changes an IKE authentication key AND the other end has not changed to that key, AND if the SA needs to be replaced, then creation of the new SA would fail. But, you have not described examples of circumstances that would trigger the need to create a new SA. If one uses the MD5 option, as soon as the key is changed at either end, that would seem to kill the existing TCP connection, which requires much more careful sync of key changes compared to IPsec use. Certainly one needs to be careful to avoid an auth key change near the time that an SA would timeout, based on the SA lifetime parameters. >Whether or not this level of risk is acceptable to operators is >unknown to me, but in any case it has to be considered. > >Brian Given the different use of the IKE auth key, vs. the traffic keys, one also needs to ask what frequency of auth key change is appropriate. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 01 14:41:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Nr6-0004sH-Vu; Wed, 01 Feb 2006 14:41:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Nr5-0004ri-GJ for rpsec@megatron.ietf.org; Wed, 01 Feb 2006 14:41:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26348 for ; Wed, 1 Feb 2006 14:39:49 -0500 (EST) Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4O2C-0001oF-89 for rpsec@ietf.org; Wed, 01 Feb 2006 14:53:00 -0500 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 01 Feb 2006 11:40:47 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 7262067421; Wed, 1 Feb 2006 11:40:47 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 3CF2F67420 for ; Wed, 1 Feb 2006 11:40:47 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id CVI27299; Wed, 1 Feb 2006 11:40:47 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id F11D820501 for ; Wed, 1 Feb 2006 11:40:46 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RPSEC] Re: no TCP-MD5 replacement please Date: Wed, 1 Feb 2006 11:40:46 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B363581D3@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [RPSEC] Re: no TCP-MD5 replacement please Thread-Index: AcYnZjbrImTsIKGyTyGk/+HabVpNdgAAPt0Q From: "Bora Akyol" To: rpsec@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006020106; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230312E34334531304432372E303030362D412D; ENG=IBF; TS=20060201194051; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006020106_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FFFD13541W6082180-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org > AH, this is what you were trying to say! Yes, if one peer=20 > changes an IKE authentication key AND the other end has not=20 > changed to that key, AND if the SA needs to be replaced, then=20 > creation of the new SA would fail. But, you have not=20 > described examples of circumstances that would trigger the=20 > need to create a new SA. If one uses the MD5 option, as soon=20 > as the key is changed at either end, that would seem to kill=20 > the existing TCP connection, which requires much more careful=20 > sync of key changes compared to IPsec use. Certainly one=20 > needs to be careful to avoid an auth key change near the time=20 > that an SA would timeout, based on the SA lifetime parameters. DPD will kill the IKE SA if there is a temporary network disruption while the key change is in progress. Regardless, the IPSEC key turnover is more robust with respect to synchronization when compared to TCP-MD5. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 01 17:49:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Qmp-0003UG-G0; Wed, 01 Feb 2006 17:49:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Qmn-0003Rs-Rd for rpsec@megatron.ietf.org; Wed, 01 Feb 2006 17:49:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22465 for ; Wed, 1 Feb 2006 17:47:36 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4Qy3-00046b-0G for rpsec@ietf.org; Wed, 01 Feb 2006 18:00:52 -0500 Received: from [198.202.64.53] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k11MmnIC028104; Wed, 1 Feb 2006 17:48:49 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <03235919BBDE634289BB6A0758A20B363581D3@NT-SJCA-0751.brcm.ad.broadcom.com> References: <03235919BBDE634289BB6A0758A20B363581D3@NT-SJCA-0751.brcm.ad.broadcom.com> Date: Wed, 1 Feb 2006 17:26:31 -0500 To: "Bora Akyol" From: Stephen Kent Subject: RE: [RPSEC] Re: no TCP-MD5 replacement please Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 11:40 AM -0800 2/1/06, Bora Akyol wrote: > > AH, this is what you were trying to say! Yes, if one peer >> changes an IKE authentication key AND the other end has not >> changed to that key, AND if the SA needs to be replaced, then >> creation of the new SA would fail. But, you have not >> described examples of circumstances that would trigger the >> need to create a new SA. If one uses the MD5 option, as soon >> as the key is changed at either end, that would seem to kill >> the existing TCP connection, which requires much more careful >> sync of key changes compared to IPsec use. Certainly one >> needs to be careful to avoid an auth key change near the time >> that an SA would timeout, based on the SA lifetime parameters. > >DPD will kill the IKE SA if there is a temporary network disruption >while the key change is in progress. Good point. >Regardless, the IPSEC key turnover is more robust with respect to >synchronization when compared to TCP-MD5. agreed. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 02 11:03:20 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4gvY-0007Ks-4m; Thu, 02 Feb 2006 11:03:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4gvU-0007HP-GE for rpsec@megatron.ietf.org; Thu, 02 Feb 2006 11:03:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15641 for ; Thu, 2 Feb 2006 11:01:30 -0500 (EST) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4h6l-0000wy-HZ for rpsec@ietf.org; Thu, 02 Feb 2006 11:14:55 -0500 Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3EBB2FB293; Thu, 2 Feb 2006 11:03:00 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 2E45B3C0229; Thu, 2 Feb 2006 09:27:47 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: "Bora Akyol" Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please In-Reply-To: (Your message of "Wed, 01 Feb 2006 11:40:46 PST.") <03235919BBDE634289BB6A0758A20B363581D3@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Feb 2006 09:27:47 -0500 Message-Id: <20060202142747.2E45B3C0229@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org In message <03235919BBDE634289BB6A0758A20B363581D3@NT-SJCA-0751.brcm.ad.broadco m.com>, "Bora Akyol" writes: > >> AH, this is what you were trying to say! Yes, if one peer >> changes an IKE authentication key AND the other end has not >> changed to that key, AND if the SA needs to be replaced, then >> creation of the new SA would fail. But, you have not >> described examples of circumstances that would trigger the >> need to create a new SA. If one uses the MD5 option, as soon >> as the key is changed at either end, that would seem to kill >> the existing TCP connection, which requires much more careful >> sync of key changes compared to IPsec use. Certainly one >> needs to be careful to avoid an auth key change near the time >> that an SA would timeout, based on the SA lifetime parameters. > >DPD will kill the IKE SA if there is a temporary network disruption >while the key change is in progress. That raises the issue of whether short-timeout DPD makes sense in this environment. I suspect that it does not. Routers don't change the IP address they use for BGP particularly often. BGP peering associations come and go on a scale of weeks, not hours; you're unlikely to recover resources you need for another BGP-over-IPsec session. And outages tend not to be permanent; they last until the fiber rangers drive off the predatory backhoes. For that matter, the need for an SA operation to rekey is very different for BGP. This is an authentication key, not a confidentiality key; it does an attacker no good to to recover a key after it's no longer in use. My suggestion is to turn off DPD and have a session key lifetime measured in days or possibly a small number of weeks, to permit easy synchronization of changes to long-term secrets. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 02 11:29:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4hKl-0001rp-0C; Thu, 02 Feb 2006 11:29:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4hKk-0001qr-2K for rpsec@megatron.ietf.org; Thu, 02 Feb 2006 11:29:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17868 for ; Thu, 2 Feb 2006 11:27:33 -0500 (EST) Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4hVy-0001wp-Ej for rpsec@ietf.org; Thu, 02 Feb 2006 11:40:59 -0500 Received: from [192.168.1.6] (c-67-180-169-111.hsd1.ca.comcast.net[67.180.169.111]) by comcast.net (rwcrmhc12) with ESMTP id <20060202162855m12007ivaqe>; Thu, 2 Feb 2006 16:28:57 +0000 Message-ID: <43E23380.3040700@tony.li> Date: Thu, 02 Feb 2006 08:29:52 -0800 From: Tony Li User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Steven M. Bellovin" Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please References: <20060202142747.2E45B3C0229@berkshire.machshav.com> In-Reply-To: <20060202142747.2E45B3C0229@berkshire.machshav.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org > My suggestion is to turn off DPD and have a session key lifetime > measured in days or possibly a small number of weeks, to permit easy > synchronization of changes to long-term secrets. I'm an IPsec novice, so please pardon the naive question: would this permit keys to change without breaking the TCP connection? IMHO, this is an absolute requirement, as we have enough BGP flap out there already. Tony _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 02 11:35:14 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4hQQ-0004eQ-3z; Thu, 02 Feb 2006 11:35:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4hQI-0004Va-6w for rpsec@megatron.ietf.org; Thu, 02 Feb 2006 11:35:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18508 for ; Thu, 2 Feb 2006 11:33:24 -0500 (EST) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4hbc-0002E5-LJ for rpsec@ietf.org; Thu, 02 Feb 2006 11:46:49 -0500 Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BA94CFB293; Thu, 2 Feb 2006 11:34:59 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id 8BD1D3BFDE3; Thu, 2 Feb 2006 11:34:58 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Tony Li Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please In-Reply-To: (Your message of "Thu, 02 Feb 2006 08:29:52 PST.") <43E23380.3040700@tony.li> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 02 Feb 2006 11:34:58 -0500 Message-Id: <20060202163458.8BD1D3BFDE3@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org In message <43E23380.3040700@tony.li>, Tony Li writes: >> My suggestion is to turn off DPD and have a session key lifetime >> measured in days or possibly a small number of weeks, to permit easy >> synchronization of changes to long-term secrets. > > >I'm an IPsec novice, so please pardon the naive question: would this >permit keys to change without breaking the TCP connection? IMHO, this >is an absolute requirement, as we have enough BGP flap out there already. > If properly implemented, it would. In fact, it's a major advantage of IPsec over TCP-MD5. The IPsec header includes an "SPI" -- security parameter index -- that identifies (among other things) the actual key used to protect the packet. During rekeying (which doesn't need to be too frequent in any event, as I mentioned) more than one SPI is accepted by the receiver; thus, both old and new keys can be accepted. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu Feb 02 12:45:53 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4iWm-0005JK-VA; Thu, 02 Feb 2006 12:45:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4iWh-0005II-Gw for rpsec@megatron.ietf.org; Thu, 02 Feb 2006 12:45:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23623 for ; Thu, 2 Feb 2006 12:43:59 -0500 (EST) Received: from mms2.broadcom.com ([216.31.210.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4ihw-0004XU-Ep for rpsec@ietf.org; Thu, 02 Feb 2006 12:57:25 -0500 Received: from 10.10.64.154 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Thu, 02 Feb 2006 09:45:11 -0800 X-Server-Uuid: D9EB6F12-1469-4C1C-87A2-5E4C0D6F9D06 Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id B046867422; Thu, 2 Feb 2006 09:45:10 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 7C0BB67421; Thu, 2 Feb 2006 09:45:10 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id CVM90522; Thu, 2 Feb 2006 09:45:09 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id CB7B620501; Thu, 2 Feb 2006 09:45:09 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RPSEC] Re: no TCP-MD5 replacement please Date: Thu, 2 Feb 2006 09:45:09 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B363582CB@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [RPSEC] Re: no TCP-MD5 replacement please Thread-Index: AcYoFp9j2yxyq+mjRNyIuF3/PtFfWwACaGBw From: "Bora Akyol" To: smb@cs.columbia.edu, "Tony Li" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006020206; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230342E34334532343338322E303033352D412D; ENG=IBF; TS=20060202174511; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006020206_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FFC9AAD1SC2298189-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org =20 With IKEv1, you could rekey the IKE SA without rekeying the IPSEC SAs or vice versa. IKEv2 coupled the two together, but I think rekeying the parent SA (IKE) without rekeying the children remains possible. IPSEC SAs are the ones that protect the BGP traffic. > -----Original Message----- > From: smb@cs.columbia.edu [mailto:smb@cs.columbia.edu]=20 > Sent: Thursday, February 02, 2006 8:35 AM > To: Tony Li > Cc: Bora Akyol; rpsec@ietf.org > Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please >=20 > In message <43E23380.3040700@tony.li>, Tony Li writes: > >> My suggestion is to turn off DPD and have a session key lifetime=20 > >> measured in days or possibly a small number of weeks, to=20 > permit easy=20 > >> synchronization of changes to long-term secrets. > > > > > >I'm an IPsec novice, so please pardon the naive question: would this=20 > >permit keys to change without breaking the TCP connection? =20 > IMHO, this=20 > >is an absolute requirement, as we have enough BGP flap out=20 > there already. > > >=20 > If properly implemented, it would. In fact, it's a major=20 > advantage of IPsec over TCP-MD5. The IPsec header includes=20 > an "SPI" -- security parameter index -- that identifies=20 > (among other things) the actual key used to protect the=20 > packet. During rekeying (which doesn't need to be too=20 > frequent in any event, as I mentioned) more than one SPI is=20 > accepted by the receiver; thus, both old and new keys can be accepted. >=20 _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Feb 03 12:28:07 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54j9-0004da-D6; Fri, 03 Feb 2006 12:28:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54j7-0004XF-3j for rpsec@megatron.ietf.org; Fri, 03 Feb 2006 12:28:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22139 for ; Fri, 3 Feb 2006 12:26:26 -0500 (EST) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F54ui-0003sU-Cw for rpsec@ietf.org; Fri, 03 Feb 2006 12:40:05 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 03 Feb 2006 09:27:48 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,85,1139212800"; d="scan'208"; a="527332698:sNHT21401340" Received: from [172.25.42.162] ([172.25.42.162] RDNS failed) by proton.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 12:27:53 -0500 Message-ID: <43E39296.3050305@juniper.net> Date: Fri, 03 Feb 2006 12:27:50 -0500 From: Ron Bonica User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rpsec@ietf.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Feb 2006 17:27:53.0194 (UTC) FILETIME=[29E30CA0:01C628E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Folks, Please review the draft at the following URL: http://www.ietf.org/internet-drafts/draft-bonica-tcp-auth-04.txt An abstract follows: "This memo describes a TCP extension that enhances security for BGP, LDP and other TCP-based protocols. It is intended for applications where secure administrative access to both the end-points of the TCP connection is normally available. TCP peers can use this extension to authenticate messages passed between one another. The strategy described herein improves upon current practice, which is described in RFC 2385. Using this new strategy, TCP peers can update authentication keys during the lifetime of a TCP connection. TCP peers can also use stronger authentication algorithms to authenticate routing messages." Ron _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Sat Feb 04 09:06:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5O3S-0007Ls-7W; Sat, 04 Feb 2006 09:06:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5O3R-0007Kt-0d for rpsec@megatron.ietf.org; Sat, 04 Feb 2006 09:06:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09316 for ; Sat, 4 Feb 2006 09:04:35 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F5OF5-0003b7-Ik for rpsec@ietf.org; Sat, 04 Feb 2006 09:18:24 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 04 Feb 2006 06:06:04 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,88,1139212800"; d="scan'208"; a="21189252:sNHT23098416" Received: from RussPC (rtp-vpn3-26.cisco.com [10.82.216.26]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k14E606I018425 for ; Sat, 4 Feb 2006 09:06:01 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Sat, 04 Feb 2006 09:06:00 -0500 X-PGP-Universal: processed; by RussPC on Sat, 04 Feb 2006 09:06:00 -0500 Message-ID: <43E4B4C2.1010304@cisco.com> Date: Sat, 04 Feb 2006 09:05:54 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rpsec@ietf.org X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Subject: [RPSEC] Charter Update 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Y'all: A second attempt.... See below for a proposed new charter. This should be one of the items on the WG meeting agenda at Dallas. I've taken out the first work item, although I'm not certain it's the right thing to do. Please comment, so we can see if there's concensus to move forward. Thanks! :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone - -- The lack of a common set of security requirements and methods for routing protocols has resulted in a wide variety of security mechanisms for individual routing protocols. Ongoing work on requirements for the next generation routing system and future work on the actual mechanisms for it will require well documented routing security requirements. The products of this working group will be used by routing protocol designers to ensure adequate coverage of security in the future, including well known and possible threats. The scope of work is limited to router-to-router protocols for unicast and multicast systems, and does NOT include host-to-router protocol such as IGMP, ICMP, ARP, or ND. It is also a non-goal at this point to produce new or change the current security mechanisms in the existing routing protocols. The RPSEC working group is charged with the following tasks: - - Document threat models for routing systems - - Document security requirements for routing systems - - Document security analysis and requirements for specific routing protocols (e.g., OSPF, BGP) - - Provide a common area for discussion between security and routing experts on the topic of securing the routing system Goals and Milestones: July 06 Submit BGP Attack-Tree analysis for publication as Informational RFC. July 06 Submit OSPF vulnerability analysis for publication as Informational RFC. July 06 Submit BGP security requirements for publication as Informational RFC. December 06 Submit initial document discussing security requirements in an OSPFv3 mobile ad hoc environment December 06 Evaluate progress, recharter with new goals or shutdown. -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ+S0yBEdu7FIVPTkEQIYOwCg9yY5uzdjAm4CiFXmOhA1g8ehNwEAoMSz YzCGrXBhq7cm1cOPls5tpQNE =6Km/ -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Feb 06 14:19:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6BtK-0006Sj-W5; Mon, 06 Feb 2006 14:19:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6BtJ-0006Se-RJ for rpsec@megatron.ietf.org; Mon, 06 Feb 2006 14:19:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14157 for ; Mon, 6 Feb 2006 14:17:32 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6C5Z-0008G9-32 for rpsec@ietf.org; Mon, 06 Feb 2006 14:31:53 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 06 Feb 2006 11:19:06 -0800 X-IronPort-AV: i="4.02,92,1139212800"; d="scan'208"; a="1773829949:sNHT31063032" Received: from [128.107.163.158] (dhcp-128-107-163-158.cisco.com [128.107.163.158]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k16JJ4c1026560; Mon, 6 Feb 2006 11:19:04 -0800 (PST) Message-ID: <43E7A15D.9060209@cisco.com> Date: Mon, 06 Feb 2006 11:19:57 -0800 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Steven M. Bellovin" Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please References: <20060202163458.8BD1D3BFDE3@berkshire.machshav.com> In-Reply-To: <20060202163458.8BD1D3BFDE3@berkshire.machshav.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Steven M. Bellovin wrote: > In message <43E23380.3040700@tony.li>, Tony Li writes: > >>>My suggestion is to turn off DPD and have a session key lifetime >>>measured in days or possibly a small number of weeks, to permit easy >>>synchronization of changes to long-term secrets. >> >> >>I'm an IPsec novice, so please pardon the naive question: would this >>permit keys to change without breaking the TCP connection? IMHO, this >>is an absolute requirement, as we have enough BGP flap out there already. >> > > > If properly implemented, it would. In fact, it's a major advantage of > IPsec over TCP-MD5. The IPsec header includes an "SPI" -- security > parameter index -- that identifies (among other things) the actual key > used to protect the packet. During rekeying (which doesn't need to be > too frequent in any event, as I mentioned) more than one SPI is > accepted by the receiver; thus, both old and new keys can be accepted. > > > --Steven M. Bellovin, http://www.cs.columbia.edu/~smb Still, it is true that there is increased risk during the occasional change of IKE pre-shared authentication key. There must exist a window during which two operational staffs agree to change the key and hope that a) they both change the key before the IKE SA lifetime is over, and b) that neither BGP router reboots. (The latter case will of course bring down the BGP session anyway, but if the IKE authentication keys don't match no subsequent BGP session can be setup.) This is *far* less risky than use of RFC 2385. But a risk still exists, which is why I said earlier that the operators needed to evaluate the risk and decide whether they could live with it or not. (Thanks, Shane for sharing your view that the risk *would* be acceptable.) Brian > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Feb 06 15:02:22 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6CZ4-00019o-5b; Mon, 06 Feb 2006 15:02:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6CZ0-00018j-Uj for rpsec@megatron.ietf.org; Mon, 06 Feb 2006 15:02:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17431 for ; Mon, 6 Feb 2006 15:00:29 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1+sqlRM7lWInxwZ7N6DV5w03iN9WpzjDjk=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Cl6-0002HK-LV for rpsec@ietf.org; Mon, 06 Feb 2006 15:14:50 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19c29napPNC4NBtOCamBQjFoLsfPJaK+BY@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k16K17Nv023949; Mon, 6 Feb 2006 20:01:13 GMT Date: Mon, 6 Feb 2006 20:01:56 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Brian Weis Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please In-Reply-To: <43E7A15D.9060209@cisco.com> Message-ID: References: <20060202163458.8BD1D3BFDE3@berkshire.machshav.com> <43E7A15D.9060209@cisco.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: rpsec@ietf.org, "Steven M. Bellovin" 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Mon, 6 Feb 2006, Brian Weis wrote: > Still, it is true that there is increased risk during the > occasional change of IKE pre-shared authentication key. With IPSec and IKE the keys could well be public-key certificates valid for year(s)[1]. Expiry would be known *well* in advance and could be done well in advance as part of planned maintenance, without co-ordination. Ie worrying about PSK updates is, imho, possibly short-sighted. 1. Some RIRs already operate as PKI cert. authorities. Whatever form of secure BGP is adopted likely will just further reinforce the need for RIRs to operate as in such a role. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Q: What do Winnie the Pooh and John the Baptist have in common? A: The same middle name. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Mon Feb 06 15:10:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Cgc-0002bG-Jd; Mon, 06 Feb 2006 15:10:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Cgb-0002ZV-3A for rpsec@megatron.ietf.org; Mon, 06 Feb 2006 15:10:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18153 for ; Mon, 6 Feb 2006 15:08:15 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Csc-0002n8-Cl for rpsec@ietf.org; Mon, 06 Feb 2006 15:22:37 -0500 Received: from gihm3.apnic.net (dhcp6.potaroo.net [203.10.60.6]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k16K8fqS054497; Tue, 7 Feb 2006 07:08:41 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060207070332.03056a48@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 07 Feb 2006 07:05:46 +1100 To: Brian Weis , "Steven M. Bellovin" From: Geoff Huston Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please In-Reply-To: <43E7A15D.9060209@cisco.com> References: <20060202163458.8BD1D3BFDE3@berkshire.machshav.com> <43E7A15D.9060209@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org >Still, it is true that there is increased risk during the occasional >change of IKE pre-shared authentication key. There must exist a window >during which two operational staffs agree to change the key and hope that >a) they both change the key before the IKE SA lifetime is over, and b) >that neither BGP router reboots. (The latter case will of course bring >down the BGP session anyway, but if the IKE authentication keys don't >match no subsequent BGP session can be setup.) Could you clarify this last statement ? i.e. Under what conditions would a subsequent BGP session start up? Geoff _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 07 11:34:25 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6VnN-0002ix-Bx; Tue, 07 Feb 2006 11:34:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6VnJ-0002i7-PA for rpsec@megatron.ietf.org; Tue, 07 Feb 2006 11:34:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08592 for ; Tue, 7 Feb 2006 11:32:29 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6VzZ-000646-8R for rpsec@ietf.org; Tue, 07 Feb 2006 11:47:02 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k17GThIE019423; Tue, 7 Feb 2006 11:29:45 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20060202163458.8BD1D3BFDE3@berkshire.machshav.com> <43E7A15D.9060209@cisco.com> Date: Tue, 7 Feb 2006 10:49:09 -0500 To: Paul Jakma From: Stephen Kent Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: rpsec@ietf.org, Brian Weis , "Steven M. Bellovin" 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 8:01 PM +0000 2/6/06, Paul Jakma wrote: >On Mon, 6 Feb 2006, Brian Weis wrote: > >>Still, it is true that there is increased risk during the >>occasional change of IKE pre-shared authentication key. > >With IPSec and IKE the keys could well be public-key certificates >valid for year(s)[1]. Expiry would be known *well* in advance and >could be done well in advance as part of planned maintenance, >without co-ordination. I'm all in favor of that approach, although it does imply the capability to process certs. >Ie worrying about PSK updates is, imho, possibly short-sighted. > >1. Some RIRs already operate as PKI cert. authorities. Whatever form >of secure BGP is adopted likely will just further reinforce the need >for RIRs to operate as in such a role. SIDR has a charter item that talks about certs being issued to for authorization and authentication in support of routing security. Certs issued by RIRs (and by ISPs), to attest to address space and AS number holdings are consistent with these charter items. In discussions on the list, use of the cert extensions defined in RFC 3779 was cited as a likely starting point for this infrastructure. This would provide an ISP with the ability to issue certs to its routers, identifying them as being affiliated with the AS number(s) of the ISP. That seems to be a reasonable basis for deciding whether a router is an appropriate peer. So, yes, I think we may head down a path that would provide certs suitable for use with IPsec in securing (e)BGP sessions. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 07 14:56:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Ywn-0001mj-2M; Tue, 07 Feb 2006 14:56:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6Ywl-0001lp-Of for rpsec@megatron.ietf.org; Tue, 07 Feb 2006 14:56:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24998 for ; Tue, 7 Feb 2006 14:54:28 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Z90-0004zD-Pk for rpsec@ietf.org; Tue, 07 Feb 2006 15:09:02 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k17JtqIE009814; Tue, 7 Feb 2006 14:55:53 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <43E4B4C2.1010304@cisco.com> References: <43E4B4C2.1010304@cisco.com> Date: Tue, 7 Feb 2006 14:55:46 -0500 To: Russ White From: Stephen Kent Subject: Re: [RPSEC] Charter Update Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Russ, I think the discussion over the last couple of weeks suggests that adding a new, narrowly-defined charter item to address point-to-point security to protect BGP sessions between border routers is worthwhile and has support from a number of WG members. Maybe we need to start with a requirements document, and then move on to consider the proposals that are being put forth. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 07 16:55:08 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6anj-0005m3-RX; Tue, 07 Feb 2006 16:55:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6anf-0005kU-Di for rpsec@megatron.ietf.org; Tue, 07 Feb 2006 16:55:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05802 for ; Tue, 7 Feb 2006 16:53:09 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6azv-0000zj-8n for rpsec@ietf.org; Tue, 07 Feb 2006 17:07:44 -0500 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k17LrlNq056638; Wed, 8 Feb 2006 08:53:48 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060208085220.02feaea0@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 08 Feb 2006 08:53:42 +1100 To: Stephen Kent , Russ White From: Geoff Huston Subject: Re: [RPSEC] Charter Update In-Reply-To: References: <43E4B4C2.1010304@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 06:55 AM 8/02/2006, Stephen Kent wrote: >Russ, > >I think the discussion over the last couple of weeks suggests that adding >a new, narrowly-defined charter item to address point-to-point security to >protect BGP sessions between border routers is worthwhile and has support >from a number of WG members. > >Maybe we need to start with a requirements document, and then move on to >consider the proposals that are being put forth. I would suggest that there is a difference between generating requirements and considering proposed solutions I thought the plan was to define requrements in RPSEC and look at solutions in other working groups, such as SIDR. regards, Geoff _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 07 17:07:37 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6azp-0002a3-Gg; Tue, 07 Feb 2006 17:07:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6azn-0002ZQ-QX for rpsec@megatron.ietf.org; Tue, 07 Feb 2006 17:07:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06300 for ; Tue, 7 Feb 2006 17:05:43 -0500 (EST) Received: from mms1.broadcom.com ([216.31.210.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6bC5-0001Jg-Dw for rpsec@ietf.org; Tue, 07 Feb 2006 17:20:19 -0500 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 07 Feb 2006 14:06:50 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 6CE0A2B4; Tue, 7 Feb 2006 14:06:50 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 57FE72B1 for ; Tue, 7 Feb 2006 14:06:50 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id CWL91875; Tue, 7 Feb 2006 14:06:48 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id A2CC920501 for ; Tue, 7 Feb 2006 14:06:48 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [RPSEC] Re: no TCP-MD5 replacement please Date: Tue, 7 Feb 2006 14:06:47 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B363587D0@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: [RPSEC] Re: no TCP-MD5 replacement please Thread-Index: AcYsBLMWVcInzfo+QIqxkNSBzH+ZcQALbNVg From: "Bora Akyol" To: rpsec@ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006020708; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413039303230392E34334539313832452E303035302D412D; ENG=IBF; TS=20060207220651; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006020708_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FF7C67010G8800198-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org =20 > >With IPSec and IKE the keys could well be public-key=20 > certificates valid=20 > >for year(s)[1]. Expiry would be known *well* in advance and could be=20 > >done well in advance as part of planned maintenance, without=20 > >co-ordination. >=20 > I'm all in favor of that approach, although it does imply the=20 > capability to process certs. >=20 If we decide to go the way of certs, I think we need to make sure that we don't end up with a serious bootstrapping problem. That is,=20 1) Need network to validate cert 2) Need validated cert to get the network going 3) Go to step 1 I do not think the capability to process certs is especially difficult to add to a box that is capable of running BGP. For the bootstrap problem, I guess we could use a model similar to SSL certs as they exist in browsers today. There was quite a bit of talk about this a while back on this list, I think. Regards Bora _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 07 18:24:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6cCc-0007zn-CK; Tue, 07 Feb 2006 18:24:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6cCa-0007ue-8o for rpsec@megatron.ietf.org; Tue, 07 Feb 2006 18:24:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11050 for ; Tue, 7 Feb 2006 18:23:11 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6cP2-0003gN-Vl for rpsec@ietf.org; Tue, 07 Feb 2006 18:37:46 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 07 Feb 2006 15:24:40 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,96,1139212800"; d="scan'208"; a="21391507:sNHT22219680" Received: from RussPC (rtp-vpn2-131.cisco.com [10.82.240.131]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k17NOaPN014553; Tue, 7 Feb 2006 18:24:38 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Tue, 07 Feb 2006 18:24:36 -0500 X-PGP-Universal: processed; by RussPC on Tue, 07 Feb 2006 18:24:36 -0500 Message-ID: <43E92C2C.2070901@cisco.com> Date: Tue, 07 Feb 2006 18:24:28 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoff Huston Subject: Re: [RPSEC] Charter Update References: <43E4B4C2.1010304@cisco.com> <6.2.0.14.2.20060208085220.02feaea0@kahuna.telstra.net> In-Reply-To: <6.2.0.14.2.20060208085220.02feaea0@kahuna.telstra.net> X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: rpsec@ietf.org, Stephen Kent 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Maybe we need to start with a requirements document, and then move on >> to consider the proposals that are being put forth. Sure... I can add that. > I would suggest that there is a difference between generating > requirements and considering proposed solutions > > I thought the plan was to define requrements in RPSEC and look at > solutions in other working groups, such as SIDR. Yes, but that still requires a charter change in rpsec, to do the req's doc. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.4 (Build 4042) iQA/AwUBQ+ksNBEdu7FIVPTkEQJ7FACg3j/Q6xDWp20rjIfxofKznbOwsb0An3ie l61fSoFNZ3Ar6+FvhAsRidi5 =3kq9 -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 07 19:22:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6d6X-0008QQ-Re; Tue, 07 Feb 2006 19:22:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6d6U-0008L7-3o for rpsec@megatron.ietf.org; Tue, 07 Feb 2006 19:22:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14611 for ; Tue, 7 Feb 2006 19:20:32 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6dIY-0005UE-CG for rpsec@ietf.org; Tue, 07 Feb 2006 19:35:08 -0500 Received: from gihm3.apnic.net (protege.telstra.net [203.50.0.194] (may be forged)) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id k180LevF058167; Wed, 8 Feb 2006 11:21:41 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20060208111603.030586d8@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 08 Feb 2006 11:16:47 +1100 To: Russ White From: Geoff Huston Subject: Re: [RPSEC] Charter Update In-Reply-To: <43E92C2C.2070901@cisco.com> References: <43E4B4C2.1010304@cisco.com> <6.2.0.14.2.20060208085220.02feaea0@kahuna.telstra.net> <43E92C2C.2070901@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: rpsec@ietf.org, Stephen Kent 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org At 10:24 AM 8/02/2006, Russ White wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > > >> Maybe we need to start with a requirements document, and then move on > >> to consider the proposals that are being put forth. > >Sure... I can add that. > > > I would suggest that there is a difference between generating > > requirements and considering proposed solutions > > > > I thought the plan was to define requrements in RPSEC and look at > > solutions in other working groups, such as SIDR. > >Yes, but that still requires a charter change in rpsec, to do the req's doc. And that part of the suggestion makes sense to me (to add the req's doc) Geoff _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 08 08:07:38 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6p2o-0003xo-Ki; Wed, 08 Feb 2006 08:07:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6p2m-0003x8-Dw for rpsec@megatron.ietf.org; Wed, 08 Feb 2006 08:07:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20424 for ; Wed, 8 Feb 2006 08:05:46 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6pFE-0003m3-DQ for rpsec@ietf.org; Wed, 08 Feb 2006 08:20:29 -0500 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Feb 2006 05:07:19 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.02,98,1139212800"; d="scan'208"; a="21426350:sNHT23050712" Received: from RussPC (rtp-vpn3-370.cisco.com [10.82.217.116]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k18D7EPN012191 for ; Wed, 8 Feb 2006 08:07:16 -0500 (EST) Received: from [127.0.0.1] by RussPC (PGP Universal service); Wed, 08 Feb 2006 08:07:16 -0500 X-PGP-Universal: processed; by RussPC on Wed, 08 Feb 2006 08:07:16 -0500 Message-ID: <43E9ECFD.5000400@cisco.com> Date: Wed, 08 Feb 2006 08:07:09 -0500 From: Russ White User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rpsec@ietf.org X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [RPSEC] Charter Update.... 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Below is the latest I have.... Thoughts welcome. We'll probably sumbit this to the IESG in about a week's time unless there's a large discussion and more changes. Thanks! :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone - -- The lack of a common set of security requirements and methods for routing protocols has resulted in a wide variety of security mechanisms for individual routing protocols. Ongoing work on requirements for the next generation routing system and future work on the actual mechanisms for it will require well documented routing security requirements. The products of this working group will be used by routing protocol designers to ensure adequate coverage of security in the future, including well known and possible threats. The scope of work is limited to router-to-router protocols for unicast and multicast systems, and does NOT include host-to-router protocol such as IGMP, ICMP, ARP, or ND. It is also a non-goal at this point to produce new or change the current security mechanisms in the existing routing protocols. The RPSEC working group is charged with the following tasks: - - Document threat models for routing systems - - Document security requirements for routing systems - - Document security analysis and requirements for specific routing protocols (e.g., OSPF, BGP) - - Provide a common area for discussion between security and routing experts on the topic of securing the routing system Goals and Milestones: July 06 Submit BGP Attack-Tree analysis for publication as Informational RFC. July 06 Submit OSPF vulnerability analysis for publication as Informational RFC. July 06 Submit BGP security requirements for publication as Informational RFC. July 06 Initial draft of requirements for point-to-point security of BGP peering sessions. December 06 Submit initial document discussing security requirements in an OSPFv3 mobile ad hoc environment December 06 Evaluate progress, recharter with new goals or shutdown. -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.0.5 (Build 5050) iQA/AwUBQ+ntBBEdu7FIVPTkEQKeJACgwPN0aU31t3aa1fNLl9//iUyV+a4An0HQ 0rs9VQrVKy1UvLb5Km9f/j5c =ZjrE -----END PGP SIGNATURE----- _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Wed Feb 08 10:17:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6r4k-0002Y0-LD; Wed, 08 Feb 2006 10:17:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6r4i-0002Tr-DB for rpsec@megatron.ietf.org; Wed, 08 Feb 2006 10:17:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00600 for ; Wed, 8 Feb 2006 10:16:02 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6rHJ-0008Qh-Qh for rpsec@ietf.org; Wed, 08 Feb 2006 10:30:47 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id k18FHQIC006917; Wed, 8 Feb 2006 10:17:26 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <03235919BBDE634289BB6A0758A20B363587D0@NT-SJCA-0751.brcm.ad.broadcom.com> References: <03235919BBDE634289BB6A0758A20B363587D0@NT-SJCA-0751.brcm.ad.broadcom.com> Date: Wed, 8 Feb 2006 10:14:30 -0500 To: "Bora Akyol" From: Stephen Kent Subject: RE: [RPSEC] Re: no TCP-MD5 replacement please Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Bora, Good observation re the potential circularity. However, with appropriate caching it is not always necessary to use the net to access data for cert validation. Cert chains and OCSP responses or CRLs can be passed between peers, for example, to avoid the need to retrieve this data from repositories. With reasonable parameters for the required "freshness" for revocation status data, this should all be manageable. Steve _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Feb 10 00:01:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7QP0-0001uT-4A; Fri, 10 Feb 2006 00:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7QOt-0001ox-DJ for rpsec@megatron.ietf.org; Fri, 10 Feb 2006 00:00:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12254 for ; Thu, 9 Feb 2006 23:59:03 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7Qbd-0000yy-6Y for rpsec@ietf.org; Fri, 10 Feb 2006 00:14:06 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 09 Feb 2006 21:00:30 -0800 X-IronPort-AV: i="4.02,101,1139212800"; d="scan'208"; a="254647465:sNHT30045792" Received: from [10.32.244.211] (stealth-10-32-244-211.cisco.com [10.32.244.211]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k1A50UQJ007938; Thu, 9 Feb 2006 21:00:30 -0800 (PST) Message-ID: <43EC1E25.9090007@cisco.com> Date: Thu, 09 Feb 2006 21:01:25 -0800 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Jakma Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please References: <20060202163458.8BD1D3BFDE3@berkshire.machshav.com> <43E7A15D.9060209@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org Paul Jakma wrote: > On Mon, 6 Feb 2006, Brian Weis wrote: > >> Still, it is true that there is increased risk during the occasional >> change of IKE pre-shared authentication key. > > > With IPSec and IKE the keys could well be public-key certificates valid > for year(s)[1]. Expiry would be known *well* in advance and could be > done well in advance as part of planned maintenance, without co-ordination. > > Ie worrying about PSK updates is, imho, possibly short-sighted. It's not being short-sighted, it's being pragmatic. You're absolutely correct about public-key certificates conveniently solving the key rollover problem. But to use public-key certificates exclusively, an ISP must agree to share a Certificate Authority with every one of its peers (i.e., competitors) as well as its customers. And practically speaking, those CAs will need to be arranged in a PKI. There is no such PKI today. (RIR CAs aren't building certificates for *routers*). As Steve Kent points out, there may in the future be a large PKI structure for routing which could provide router certificates. But large PKIs don't get put in place quickly. Pre-shared keys are are a necessity for some time to come. Brian > 1. Some RIRs already operate as PKI cert. authorities. Whatever form of > secure BGP is adopted likely will just further reinforce the need for > RIRs to operate as in such a role. > > regards, -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri Feb 10 16:47:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7g6q-0008E8-Pj; Fri, 10 Feb 2006 16:47:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F7g6o-0008Bw-KA for rpsec@megatron.ietf.org; Fri, 10 Feb 2006 16:47:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04299 for ; Fri, 10 Feb 2006 16:45:24 -0500 (EST) Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F7gJj-0002VS-8c for rpsec@ietf.org; Fri, 10 Feb 2006 17:00:39 -0500 Received: from chris.corp.google.com (chris.corp.google.com [172.24.0.146]) by smtp-out.google.com with ESMTP id k1ALks9X009962 for ; Fri, 10 Feb 2006 13:46:55 -0800 Received: from [172.18.77.11] (dot.corp.google.com [172.18.77.11]) (authenticated bits=0) by chris.corp.google.com with ESMTP id k1ALkqx3031581 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO) for ; Fri, 10 Feb 2006 13:46:52 -0800 Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <43EC1E25.9090007@cisco.com> References: <20060202163458.8BD1D3BFDE3@berkshire.machshav.com> <43E7A15D.9060209@cisco.com> <43EC1E25.9090007@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Warren Kumari Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please Date: Fri, 10 Feb 2006 13:46:51 -0800 To: rpsec@ietf.org X-Mailer: Apple Mail (2.746.2) X-Spam-Score: -4.3 (----) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Feb 9, 2006, at 9:01 PM, Brian Weis wrote: > Paul Jakma wrote: >> On Mon, 6 Feb 2006, Brian Weis wrote: >>> Still, it is true that there is increased risk during the >>> occasional change of IKE pre-shared authentication key. >> With IPSec and IKE the keys could well be public-key certificates >> valid for year(s)[1]. Expiry would be known *well* in advance and >> could be done well in advance as part of planned maintenance, >> without co-ordination. >> Ie worrying about PSK updates is, imho, possibly short-sighted. > > It's not being short-sighted, it's being pragmatic. You're > absolutely correct about public-key certificates conveniently > solving the key rollover problem. But to use public-key > certificates exclusively, an ISP must agree to share a Certificate > Authority with every one of its peers (i.e., competitors) as well > as its customers. And practically speaking, those CAs will need to > be arranged in a PKI. > > There is no such PKI today. (RIR CAs aren't building certificates > for *routers*). As Steve Kent points out, there may in the future > be a large PKI structure for routing which could provide router > certificates. But large PKIs don't get put in place quickly. Pre- > shared keys are are a necessity for some time to come. Pre-shared keys are much easier to deal with in many cases - if I turn up a new router it is much easier to just paste a pre-shared key into the config than to go to my CA, generate a key and cert request, sign the cert request, copy the new cert and key, etc. This is especially true for smaller, less technical companies - I think that you will find that the majority of IPSec deployed in smaller companies use pre-shared keys because of their ease of use. Changing a pre-shared key (or a bunch of pre-shared keys) is also much easier than having to change all of your certs if the person running your CA leaves the company (or your CA gets compromised). Don't get me wrong, I am not denying the increased security and (in most cases) increased ease of management of certificates, just that pre-shared keys have their place too. Warren > > Brian > >> 1. Some RIRs already operate as PKI cert. authorities. Whatever >> form of secure BGP is adopted likely will just further reinforce >> the need for RIRs to operate as in such a role. >> regards, > > > -- > Brian Weis > Advanced Security Development, Security Technology Group, Cisco > Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > _______________________________________________ > RPSEC mailing list > RPSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/rpsec > -- Some people are like Slinkies......Not really good for anything but they still bring a smile to your face when you push them down the stairs. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Tue Feb 14 01:32:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8tjS-0006sJ-An; Tue, 14 Feb 2006 01:32:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8tjQ-0006s9-3E for rpsec@megatron.ietf.org; Tue, 14 Feb 2006 01:32:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00441 for ; Tue, 14 Feb 2006 01:30:26 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1+Ijv7Pqz+Y4sVpRzba8DO2uW/CLR5njag=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8tx7-0006Rd-8a for rpsec@ietf.org; Tue, 14 Feb 2006 01:46:26 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19M0k0Q2vIbHiny2dXfziQ1Ud+bdZkZapQ@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id k1E6VsOv022727; Tue, 14 Feb 2006 06:31:58 GMT Date: Tue, 14 Feb 2006 06:33:00 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Brian Weis Subject: Re: [RPSEC] Re: no TCP-MD5 replacement please In-Reply-To: <43EC1E25.9090007@cisco.com> Message-ID: References: <20060202163458.8BD1D3BFDE3@berkshire.machshav.com> <43E7A15D.9060209@cisco.com> <43EC1E25.9090007@cisco.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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: , Sender: rpsec-bounces@ietf.org Errors-To: rpsec-bounces@ietf.org On Thu, 9 Feb 2006, Brian Weis wrote: > It's not being short-sighted, it's being pragmatic. You're > absolutely correct about public-key certificates conveniently > solving the key rollover problem. But to use public-key > certificates exclusively, an ISP must agree to share a Certificate > Authority with every one of its peers Right. > There is no such PKI today. (RIR CAs aren't building certificates > for *routers*). Nor would they in the future, one strongly hopes. > As Steve Kent points out, there may in the future > be a large PKI structure for routing which could provide router > certificates. But large PKIs don't get put in place quickly. Indeed. And despite the lack of any IDR security solution involving PKI, some RIRs still seem to be investigating it and either are experimenting with PKI infrastructure related directly to routing, or gaining operational PKI experience in other ways. It's a question for the operational community more than anything, but I have a suspicion they'd welcome something better than statically keyed transport security. But: > Pre-shared keys are are a necessity for some time to come. Yes, agreed. And as already stated an IKE implementation can allow for PSK changeover too, with just a mild amount of care. Failing that, the care can still potentially be applied administratively. IMHO we would do our "users" a huge favour to adopt IPSec as transport security for BGP, agreeing on a small set of required 'profiles' (as someone suggested), and then deprecate TCP-MD5. We'd gain for operators a wider choice in additional authentication methods, all far more manageable than shared-keys (e.g. RADIUS and GSS methods for within a single administrative domain, maybe even IXes). It'd also allow the RIRs to figure out details of and gain operational PKI experience of cross-domain authentication while work in SIDR would be (presumably) ongoing. Which potentially could be useful to SIDR itself. > Brian regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: It's stuck in the Web. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec