From rpsec-bounces@ietf.org Mon May 01 17:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagHS-0002go-FE; Mon, 01 May 2006 17:50:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FagHQ-0002fW-5L; Mon, 01 May 2006 17:50:08 -0400 Received: from oak.neustar.com ([209.173.53.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FagHN-0006iz-UZ; Mon, 01 May 2006 17:50:08 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k41LnuBX022257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 May 2006 21:49:57 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FagHE-0005ol-Uj; Mon, 01 May 2006 17:49:56 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 01 May 2006 17:49:56 -0400 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: rpsec chair , rpsec mailing list , rpsec chair , Internet Architecture Board , RFC Editor Subject: [RPSEC] Document Action: 'Generic Threats to Routing Protocols' to Informational RFC 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 The IESG has approved the following document: - 'Generic Threats to Routing Protocols ' as an Informational RFC This document is the product of the Routing Protocol Security Requirements Working Group. The IESG contact persons are Bill Fenner and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-07.txt Technical Summary Routing protocols are subject to attacks that can harm individual users or network operations as a whole. This document provides a description and a summary of generic threats that affect routing protocols in general. This work describes threats, including threat sources and capabilities, threat actions, and threat consequences as well as a breakdown of routing functions that might be separately attacked. Working Group Summary Version -06 was approved in May, 2004. When it was realized that version had some flaws, it was pulled from the RFC Editor's queue and updated. The updated version passed Working Group Last Call in February, 2005. Protocol Quality Alex Zinin reviewed this document for the initial approval. Bill Fenner reviewed the updated version. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu May 04 00:15:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbVFP-0000Gk-Fn; Thu, 04 May 2006 00:15:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbVFN-0000Gc-Es for rpsec@ietf.org; Thu, 04 May 2006 00:15:25 -0400 Received: from web8514.mail.in.yahoo.com ([202.43.219.107]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbVFL-0004GM-MX for rpsec@ietf.org; Thu, 04 May 2006 00:15:25 -0400 Received: (qmail 90053 invoked by uid 60001); 4 May 2006 04:15:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nnlBJqN4f24a4TtptVxbyl+JhkKgoEfthituS/tVB+Z5c1b+NU7KgACfli8IJCXxGseqvPkTncXhpgtRnWOatkHNamANb6wanWWFVJgRUS+H2kd+BYP8zmPnh/UTrMdQb/He4awLGLGFveFtE8vlp9Rm8zi+iazs1AkmUnmFCqY= ; Message-ID: <20060504041521.90051.qmail@web8514.mail.in.yahoo.com> Received: from [59.144.41.153] by web8514.mail.in.yahoo.com via HTTP; Thu, 04 May 2006 05:15:21 BST Date: Thu, 4 May 2006 05:15:21 +0100 (BST) From: Sandhya Chawla To: rpsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [RPSEC] Using IPSec for Routing Protocols 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="===============0359480646==" Errors-To: rpsec-bounces@ietf.org --===============0359480646== Content-Type: multipart/alternative; boundary="0-1289916614-1146716121=:88050" Content-Transfer-Encoding: 8bit --0-1289916614-1146716121=:88050 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I have a doubt. Why are we working on providing security at each routing protocol (application layer)? Why cant we simply use IPSEC for this? Will not AH in the transport mode provide data integrity and security for all the routing protocols (basically the IP payload) ? If confidentiality is required then one can use ESP. So, what is it that i am missing or i dont understand, because of which we in IETF are working on providing security/authentication features in each protocol besides already having IPSec. Regards, Sandhya --------------------------------- Yahoo! India Answers: Share what you know. Learn something new. Click here --0-1289916614-1146716121=:88050 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi,
 
I have a doubt.
 
Why are we working on providing security at each routing protocol (application layer)? Why cant we simply use IPSEC for this?
 
Will not AH in the transport mode provide data integrity and security for all the routing protocols (basically the IP payload) ? If confidentiality is required then one can use ESP.
 
So, what is it that i am missing or i dont understand, because of which we in IETF are working on providing security/authentication features in each protocol besides already having IPSec.
 
Regards,
Sandhya

Yahoo! India Answers: Share what you know. Learn something new. Click here --0-1289916614-1146716121=:88050-- --===============0359480646== 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 --===============0359480646==-- From rpsec-bounces@ietf.org Thu May 04 03:59:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbYk0-0005HW-Mz; Thu, 04 May 2006 03:59:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbYjz-00058z-1N for rpsec@ietf.org; Thu, 04 May 2006 03:59:15 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbYjx-0005Sv-OX for rpsec@ietf.org; Thu, 04 May 2006 03:59:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id C216626C1A7; Thu, 4 May 2006 09:59:12 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id D51EA26C196; Thu, 4 May 2006 09:59:06 +0200 (CEST) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id D13CE58E9F6; Thu, 4 May 2006 09:59:06 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id C75C416A97B; Thu, 4 May 2006 09:59:06 +0200 (CEST) Date: Thu, 4 May 2006 09:59:06 +0200 From: Stephane Bortzmeyer To: Sandhya Chawla Message-ID: <20060504075906.GA14631@nic.fr> References: <20060504041521.90051.qmail@web8514.mail.in.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060504041521.90051.qmail@web8514.mail.in.yahoo.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: rpsec@ietf.org Subject: [RPSEC] Re: Using IPSec for Routing Protocols 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 On Thu, May 04, 2006 at 05:15:21AM +0100, Sandhya Chawla wrote a message of 50 lines which said: > Why are we working on providing security at each routing protocol > (application layer)? Why cant we simply use IPSEC for this? Wild guess from a non-expert: because IPsec only provides channel security, not data security. For instance, if I have a BGP connection with a peer, I can use IPsec and therefore be sure that the peer is really what it says it is. But what does it buy me when the peer announces a route? How can I be sure that he is entitled to announce this route? (Analogy: showing me your passport can convince me that you are indeed Sandhya Chawla. But it does not make any difference when you tell me that Om Prakash Chautala is an honest man or not: I still have to check the information.) For the same reason, IPsec does not make the DNS safer and we need DNSsec. _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu May 04 04:26:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbZA2-0000Dk-Vw; Thu, 04 May 2006 04:26:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbZA1-0000Df-Sk for rpsec@ietf.org; Thu, 04 May 2006 04:26:09 -0400 Received: from web8513.mail.in.yahoo.com ([202.43.219.106]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbZ9z-0006CA-Pc for rpsec@ietf.org; Thu, 04 May 2006 04:26:09 -0400 Received: (qmail 60360 invoked by uid 60001); 4 May 2006 08:26:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5I1Lrh+k2/zrqR1ppBhb4j941p7j64vcvRJRE1X4VAGyDDWzozmk5VFfFOWM3wJz7s/ErEvvgcPCXFGtMD/XU1pt2rd6us2568KGPoneyRiqcuJXbgzKsH0OboPPW+qq6BKuJ2oGen84ucbpcFM9BUNFN8KoHbzwnjScWlYmYlI= ; Message-ID: <20060504082605.60358.qmail@web8513.mail.in.yahoo.com> Received: from [59.144.52.199] by web8513.mail.in.yahoo.com via HTTP; Thu, 04 May 2006 09:26:05 BST Date: Thu, 4 May 2006 09:26:05 +0100 (BST) From: Sandhya Chawla To: Stephane Bortzmeyer , rpsec@ietf.org In-Reply-To: <20060504075906.GA14631@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [RPSEC] Re: Using IPSec for Routing Protocols 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 Stephane, --- Stephane Bortzmeyer wrote: > On Thu, May 04, 2006 at 05:15:21AM +0100, > Sandhya Chawla wrote > a message of 50 lines which said: > > > Why are we working on providing security at each routing protocol > > (application layer)? Why cant we simply use IPSEC for this? > > Wild guess from a non-expert: because IPsec only provides channel > security, not data security. For instance, if I have a BGP connection We could use ESP will null encryption (null cipher). Using NULL as we really dont want to provide any confidentiality. We only want to authenticate the sender and want to make sure that no one mangles the packet in between. > with a peer, I can use IPsec and therefore be sure that the peer is > really what it says it is. But what does it buy me when the peer > announces a route? How can I be sure that he is entitled to announce > this route? Yes, i understand the need for SO-BGP and S-BGP. What about the IGPs? We would perhaps not want to go in for the complexity of issuing certificates, etc for IGPs. Would we? If not, then why cant we simply use IPSEC to protect and auth my IGP data? I understand that IPSEC works best for, and is perhaps currently defined only for unicast traffic. Is this the reason because of which we cant use IPSEC for IGPs (OSPF)? Regards, Sandhya > > (Analogy: showing me your passport can convince me that you are indeed > Sandhya Chawla. But it does not make any difference when you tell me > that Om Prakash Chautala is an honest man or not: I still have to > check the information.) > > For the same reason, IPsec does not make the DNS safer and we need > DNSsec. > __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new. http://in.answers.yahoo.com _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu May 04 07:06:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbbeR-0002qT-Pr; Thu, 04 May 2006 07:05:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbbeR-0002qO-AK for rpsec@ietf.org; Thu, 04 May 2006 07:05:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbbeR-0005Mb-1o for rpsec@ietf.org; Thu, 04 May 2006 07:05:43 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 04 May 2006 04:05:43 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,87,1146466800"; d="scan'208"; a="27321380:sNHT23766176" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k44B5eTL009966; Thu, 4 May 2006 07:05:42 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 07:05:40 -0400 Received: from [10.82.209.92] ([10.82.209.92]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 07:05:39 -0400 Message-ID: <4459E002.2050103@cisco.com> Date: Thu, 04 May 2006 07:05:38 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sandhya Chawla Subject: Re: [RPSEC] Re: Using IPSec for Routing Protocols References: <20060504082605.60358.qmail@web8513.mail.in.yahoo.com> In-Reply-To: <20060504082605.60358.qmail@web8513.mail.in.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2006 11:05:39.0768 (UTC) FILETIME=[ADAD7380:01C66F6A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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 Sandhya, See inline. Sandhya Chawla wrote: >Hi Stephane, > >--- Stephane Bortzmeyer wrote: > > > >>On Thu, May 04, 2006 at 05:15:21AM +0100, >> Sandhya Chawla wrote >> a message of 50 lines which said: >> >> >> >>>Why are we working on providing security at each routing protocol >>>(application layer)? Why cant we simply use IPSEC for this? >>> >>> >>Wild guess from a non-expert: because IPsec only provides channel >>security, not data security. For instance, if I have a BGP connection >> >> > >We could use ESP will null encryption (null cipher). Using NULL as we really dont want to provide >any confidentiality. We only want to authenticate the sender and want to make sure that no one >mangles the packet in between. > > > >>with a peer, I can use IPsec and therefore be sure that the peer is >>really what it says it is. But what does it buy me when the peer >>announces a route? How can I be sure that he is entitled to announce >>this route? >> >> > >Yes, i understand the need for SO-BGP and S-BGP. What about the IGPs? We would perhaps not want to >go in for the complexity of issuing certificates, etc for IGPs. Would we? > > I would hope not. Though there have been experiments in this area. >If not, then why cant we simply use IPSEC to protect and auth my IGP data? > > There have been some challenges in using IPSec but the draft should be published soon. http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt Work is underway to provide the IPSec for OSPFv2 as well. Acee >I understand that IPSEC works best for, and is perhaps currently defined only for unicast traffic. >Is this the reason because of which we cant use IPSEC for IGPs (OSPF)? > >Regards, >Sandhya > > > >>(Analogy: showing me your passport can convince me that you are indeed >>Sandhya Chawla. But it does not make any difference when you tell me >>that Om Prakash Chautala is an honest man or not: I still have to >>check the information.) >> >>For the same reason, IPsec does not make the DNS safer and we need >>DNSsec. >> >> >> > > > > >__________________________________________________________ >Yahoo! India Answers: Share what you know. Learn something new. >http://in.answers.yahoo.com > >_______________________________________________ >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 Thu May 04 08:25:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbctR-0003x3-Om; Thu, 04 May 2006 08:25:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbctR-0003wy-8r for rpsec@ietf.org; Thu, 04 May 2006 08:25:17 -0400 Received: from wx-out-0102.google.com ([66.249.82.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbctQ-0008HV-Rz for rpsec@ietf.org; Thu, 04 May 2006 08:25:17 -0400 Received: by wx-out-0102.google.com with SMTP id s12so328341wxc for ; Thu, 04 May 2006 05:25:16 -0700 (PDT) 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=k9wkGv7OfktMwI+t8d9GXL4kDYdTlGlg1ZujdQmzm/zsQfOAopWb4IdnEQBoTi78sBdB8HLnlvMvMTd+M4I4lpgn1EpoHLpQy+XXij/noMQNyncmdKq5jj431FdDU9A+apc6b13bu2ZkuhifW5wMV+0Y/NY4SK2J6wv1elf/+A8= Received: by 10.70.34.3 with SMTP id h3mr574116wxh; Thu, 04 May 2006 05:25:16 -0700 (PDT) Received: by 10.70.8.12 with HTTP; Thu, 4 May 2006 05:25:16 -0700 (PDT) Message-ID: <77ead0ec0605040525jd8cead1o346b8e6f1b7b15a0@mail.gmail.com> Date: Thu, 4 May 2006 05:25:16 -0700 From: "Vishwas Manral" To: "Acee Lindem" Subject: Re: [RPSEC] Re: Using IPSec for Routing Protocols In-Reply-To: <4459E002.2050103@cisco.com> MIME-Version: 1.0 References: <20060504082605.60358.qmail@web8513.mail.in.yahoo.com> <4459E002.2050103@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 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="===============1483611673==" Errors-To: rpsec-bounces@ietf.org --===============1483611673== Content-Type: multipart/alternative; boundary="----=_Part_5840_20935079.1146745516521" ------=_Part_5840_20935079.1146745516521 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Acee, One reason we do not use IPsec is that we do not support multicast well in IPsec. I think the way it is used in OSPFv3 is itself a hack. Also in the end of it we are still using manual keying as well as only authentication s= o still the same as for the rpotocols. Stephen Kent would probably have the details of it. Thanks, Vishwas On 5/4/06, Acee Lindem wrote: > > Sandhya, > See inline. > Sandhya Chawla wrote: > > >Hi Stephane, > > > >--- Stephane Bortzmeyer wrote: > > > > > > > >>On Thu, May 04, 2006 at 05:15:21AM +0100, > >> Sandhya Chawla wrote > >> a message of 50 lines which said: > >> > >> > >> > >>>Why are we working on providing security at each routing protocol > >>>(application layer)? Why cant we simply use IPSEC for this? > >>> > >>> > >>Wild guess from a non-expert: because IPsec only provides channel > >>security, not data security. For instance, if I have a BGP connection > >> > >> > > > >We could use ESP will null encryption (null cipher). Using NULL as we > really dont want to provide > >any confidentiality. We only want to authenticate the sender and want to > make sure that no one > >mangles the packet in between. > > > > > > > >>with a peer, I can use IPsec and therefore be sure that the peer is > >>really what it says it is. But what does it buy me when the peer > >>announces a route? How can I be sure that he is entitled to announce > >>this route? > >> > >> > > > >Yes, i understand the need for SO-BGP and S-BGP. What about the IGPs? We > would perhaps not want to > >go in for the complexity of issuing certificates, etc for IGPs. Would we= ? > > > > > I would hope not. Though there have been experiments in this area. > > >If not, then why cant we simply use IPSEC to protect and auth my IGP > data? > > > > > There have been some challenges in using IPSec but the draft should be > published soon. > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt > > Work is underway to provide the IPSec for OSPFv2 as well. > > Acee > > >I understand that IPSEC works best for, and is perhaps currently defined > only for unicast traffic. > >Is this the reason because of which we cant use IPSEC for IGPs (OSPF)? > > > >Regards, > >Sandhya > > > > > > > >>(Analogy: showing me your passport can convince me that you are indeed > >>Sandhya Chawla. But it does not make any difference when you tell me > >>that Om Prakash Chautala is an honest man or not: I still have to > >>check the information.) > >> > >>For the same reason, IPsec does not make the DNS safer and we need > >>DNSsec. > >> > >> > >> > > > > > > > > > >__________________________________________________________ > >Yahoo! India Answers: Share what you know. Learn something new. > >http://in.answers.yahoo.com > > > >_______________________________________________ > >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 > ------=_Part_5840_20935079.1146745516521 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Acee,
 
One reason we do not use IPsec is that we do not support multicast wel= l in IPsec. I think the way it is used in OSPFv3 is itself a hack.&nbs= p;Also in the end of it we are still using manual keying as well as only au= thentication so still the same as for the rpotocols.
 
Stephen Kent would probably have the details of it.
 
Thanks,
Vishwas

 
On 5/4/06, A= cee Lindem <acee@cisco.com>= wrote:
Sandhya,
See inline.
Sandh= ya Chawla wrote:

>Hi Stephane,
>
>--- Stephane Bortzm= eyer < bortzmeyer@nic.fr> wrote:
&g= t;
>
>
>>On Thu, May 04, 2006 at 05:15:21AM +0100,
= >> Sandhya Chawla <s= andhya.chawla@yahoo.co.in > wrote
>> a message of 50 lines which said:
>>>>
>>
>>>Why are we working on providing securi= ty at each routing protocol
>>>(application layer)? Why cant we= simply use IPSEC for this?
>>>
>>>
>>Wild guess from a non-expert: b= ecause IPsec only provides channel
>>security, not data security. = For instance, if I have a BGP connection
>>
>>
>
>We could use ESP will null encryption (null cipher). Using NULL as = we really dont want to provide
>any confidentiality. We only want to = authenticate the sender and want to make sure that no one
>mangles th= e packet in between.
>
>
>
>>with a peer, I can use IPsec and theref= ore be sure that the peer is
>>really what it says it is. But what= does it buy me when the peer
>>announces a route? How can I be su= re that he is entitled to announce
>>this route?
>>
>>
>
>Yes, i under= stand the need for SO-BGP and S-BGP. What about the IGPs? We would perhaps = not want to
>go in for the complexity of issuing certificates, etc fo= r IGPs. Would we?
>
>
I would hope not. Though there have been experiments in= this area.

>If not, then why cant we simply use IPSEC to protect= and auth my IGP data?
>
>
There have been some challenges i= n using IPSec but the draft should be
published soon.

http://www.ietf.org/internet-drafts/draf= t-ietf-ospf-ospfv3-auth-08.txt

Work is underway to provide the I= PSec for OSPFv2 as well.

Acee

>I understand that IPSEC works best for, and is perh= aps currently defined only for unicast traffic.
>Is this the reason b= ecause of which we cant use IPSEC for IGPs (OSPF)?
>
>Regards,
>Sandhya
>
>
>
>>(Analogy: showing me you= r passport can convince me that you are indeed
>>Sandhya Chawla. B= ut it does not make any difference when you tell me
>>that Om Prak= ash Chautala is an honest man or not: I still have to
>>check the information.)
>>
>>For the same rea= son, IPsec does not make the DNS safer and we need
>>DNSsec.
&g= t;>
>>
>>
>
>
>
>
>_____= _____________________________________________________
>Yahoo! India Answers: Share what you know. Learn something new.
= >http://in.answers.yahoo.com=
>
>_______________________________________________
>RPSE= C mailing list
>RPSEC@ietf.org
>https://www1.ietf.org/mai= lman/listinfo/rpsec
>
>
>

____________________= ___________________________
RPSEC mailing list
RPSEC@ietf.org<= /a>
https://www= 1.ietf.org/mailman/listinfo/rpsec

------=_Part_5840_20935079.1146745516521-- --===============1483611673== 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 --===============1483611673==-- From rpsec-bounces@ietf.org Thu May 04 14:45:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbipE-0004KU-He; Thu, 04 May 2006 14:45:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbipD-0004KB-Ub for rpsec@ietf.org; Thu, 04 May 2006 14:45:19 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbipD-0000OJ-6A for rpsec@ietf.org; Thu, 04 May 2006 14:45:19 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k44Ig7ho017623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2006 11:42:07 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k44Ig6Ae022734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 May 2006 11:42:06 -0700 (PDT) Message-Id: <6.2.5.6.2.20060504114102.057e9f98@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 04 May 2006 11:42:01 -0700 To: "Vishwas Manral" , "Acee Lindem" From: Lakshminath Dondeti Subject: Re: [RPSEC] Re: Using IPSec for Routing Protocols In-Reply-To: <77ead0ec0605040525jd8cead1o346b8e6f1b7b15a0@mail.gmail.com > References: <20060504082605.60358.qmail@web8513.mail.in.yahoo.com> <4459E002.2050103@cisco.com> <77ead0ec0605040525jd8cead1o346b8e6f1b7b15a0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: rpsec@ietf.org, msec@securemulticast.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 05:25 AM 5/4/2006, Vishwas Manral wrote: >Hi Acee, > >One reason we do not use IPsec is that we do not support multicast >well in IPsec. This is news to me and probably to many folks in MSEC. Please take a look at the work underway in that group. regards, Lakshminath > I think the way it is used in OSPFv3 is itself a hack. Also in the > end of it we are still using manual keying as well as only > authentication so still the same as for the rpotocols. > >Stephen Kent would probably have the details of it. > >Thanks, >Vishwas > > >On 5/4/06, Acee Lindem <acee@cisco.com> wrote: >Sandhya, >See inline. >Sandhya Chawla wrote: > > >Hi Stephane, > > > >--- Stephane Bortzmeyer < > bortzmeyer@nic.fr> wrote: > > > > > > > >>On Thu, May 04, 2006 at 05:15:21AM +0100, > >> Sandhya Chawla > <sandhya.chawla@yahoo.co.in > wrote > >> a message of 50 lines which said: > >> > >> > >> > >>>Why are we working on providing security at each routing protocol > >>>(application layer)? Why cant we simply use IPSEC for this? > >>> > >>> > >>Wild guess from a non-expert: because IPsec only provides channel > >>security, not data security. For instance, if I have a BGP connection > >> > >> > > > >We could use ESP will null encryption (null cipher). Using NULL as > we really dont want to provide > >any confidentiality. We only want to authenticate the sender and > want to make sure that no one > >mangles the packet in between. > > > > > > > >>with a peer, I can use IPsec and therefore be sure that the peer is > >>really what it says it is. But what does it buy me when the peer > >>announces a route? How can I be sure that he is entitled to announce > >>this route? > >> > >> > > > >Yes, i understand the need for SO-BGP and S-BGP. What about the > IGPs? We would perhaps not want to > >go in for the complexity of issuing certificates, etc for IGPs. Would we? > > > > >I would hope not. Though there have been experiments in this area. > > >If not, then why cant we simply use IPSEC to protect and auth my IGP data? > > > > >There have been some challenges in using IPSec but the draft should be >published soon. > >http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt > >Work is underway to provide the IPSec for OSPFv2 as well. > >Acee > > >I understand that IPSEC works best for, and is perhaps currently > defined only for unicast traffic. > >Is this the reason because of which we cant use IPSEC for IGPs (OSPF)? > > > >Regards, > >Sandhya > > > > > > > >>(Analogy: showing me your passport can convince me that you are indeed > >>Sandhya Chawla. But it does not make any difference when you tell me > >>that Om Prakash Chautala is an honest man or not: I still have to > >>check the information.) > >> > >>For the same reason, IPsec does not make the DNS safer and we need > >>DNSsec. > >> > >> > >> > > > > > > > > > >__________________________________________________________ > >Yahoo! India Answers: Share what you know. Learn something new. > >http://in.answers.yahoo.com > > > >_______________________________________________ > >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 _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Thu May 04 14:51:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbiuo-0006ED-6i; Thu, 04 May 2006 14:51:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbiun-0006E5-81 for rpsec@ietf.org; Thu, 04 May 2006 14:51:05 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbium-0000dh-Rp for rpsec@ietf.org; Thu, 04 May 2006 14:51:05 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k44IorBZ025106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2006 11:50:54 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k44IoqPV015278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 May 2006 11:50:52 -0700 (PDT) Message-Id: <6.2.5.6.2.20060504114213.03e90eb8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 04 May 2006 11:50:50 -0700 To: Sandhya Chawla , Stephane Bortzmeyer , rpsec@ietf.org From: Lakshminath Dondeti Subject: Re: [RPSEC] Re: Using IPSec for Routing Protocols In-Reply-To: <20060504082605.60358.qmail@web8513.mail.in.yahoo.com> References: <20060504075906.GA14631@nic.fr> <20060504082605.60358.qmail@web8513.mail.in.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Hi, Stephane makes an important point and asks the question of whether channel security (doesn't necessarily mean encryption; an integrity protected channel is also "secure," with the property that a third party can't modify data without detection) is sufficient. I'd like to hear others' take on what the requirements are. So, Sandhya, are you saying that integrity protection in transit is the only requirement? And, are you saying that there is no need for the recipient to be able to verify whether the claimed route or reachability information is in fact correct? Put another way, do we care to mitigate the impact of a compromised router? regards, Lakshminath At 01:26 AM 5/4/2006, Sandhya Chawla wrote: >Hi Stephane, > >--- Stephane Bortzmeyer wrote: > > > On Thu, May 04, 2006 at 05:15:21AM +0100, > > Sandhya Chawla wrote > > a message of 50 lines which said: > > > > > Why are we working on providing security at each routing protocol > > > (application layer)? Why cant we simply use IPSEC for this? > > > > Wild guess from a non-expert: because IPsec only provides channel > > security, not data security. For instance, if I have a BGP connection > >We could use ESP will null encryption (null cipher). Using NULL as >we really dont want to provide >any confidentiality. We only want to authenticate the sender and >want to make sure that no one >mangles the packet in between. > > > with a peer, I can use IPsec and therefore be sure that the peer is > > really what it says it is. But what does it buy me when the peer > > announces a route? How can I be sure that he is entitled to announce > > this route? > >Yes, i understand the need for SO-BGP and S-BGP. What about the >IGPs? We would perhaps not want to >go in for the complexity of issuing certificates, etc for IGPs. Would we? > >If not, then why cant we simply use IPSEC to protect and auth my IGP data? > >I understand that IPSEC works best for, and is perhaps currently >defined only for unicast traffic. >Is this the reason because of which we cant use IPSEC for IGPs (OSPF)? > >Regards, >Sandhya > > > > > (Analogy: showing me your passport can convince me that you are indeed > > Sandhya Chawla. But it does not make any difference when you tell me > > that Om Prakash Chautala is an honest man or not: I still have to > > check the information.) > > > > For the same reason, IPsec does not make the DNS safer and we need > > DNSsec. > > > > > > >__________________________________________________________ >Yahoo! India Answers: Share what you know. Learn something new. >http://in.answers.yahoo.com > >_______________________________________________ >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 Thu May 04 15:13:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbjFw-00041b-7i; Thu, 04 May 2006 15:12:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbjFu-0003tg-An for rpsec@ietf.org; Thu, 04 May 2006 15:12:55 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbjFt-0001Ve-VQ for rpsec@ietf.org; Thu, 04 May 2006 15:12:54 -0400 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 04 May 2006 12:12:53 -0700 X-IronPort-AV: i="4.05,89,1146466800"; d="scan'208"; a="1801440258:sNHT29522788" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k44JCqVI026241; Thu, 4 May 2006 12:12:53 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 15:12:52 -0400 Received: from [10.82.209.92] ([10.82.209.92]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 4 May 2006 15:12:52 -0400 Message-ID: <445A5233.7090305@cisco.com> Date: Thu, 04 May 2006 15:12:51 -0400 From: Acee Lindem User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vishwas Manral Subject: Re: [RPSEC] Re: Using IPSec for Routing Protocols References: <20060504082605.60358.qmail@web8513.mail.in.yahoo.com> <4459E002.2050103@cisco.com> <77ead0ec0605040525jd8cead1o346b8e6f1b7b15a0@mail.gmail.com> In-Reply-To: <77ead0ec0605040525jd8cead1o346b8e6f1b7b15a0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2006 19:12:52.0244 (UTC) FILETIME=[BD974D40:01C66FAE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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 Vishwas Manral wrote: > Hi Acee, > > One reason we do not use IPsec is that we do not support multicast > well in > IPsec. I think the way it is used in OSPFv3 is itself a hack. Also in the > end of it we are still using manual keying as well as only > authentication so > still the same as for the rpotocols. Hi Vishwas, Irrespective of the limitations, I belive what is defined will provide for a base for further enhancement. If there were a burning requirement for improvement, one could relegate OSPFv3 to only point-to-point and point-to-multipoint networks types and use dynamic keying and reply protection. Thanks, Acee > > Stephen Kent would probably have the details of it. > > Thanks, > Vishwas > > > On 5/4/06, Acee Lindem wrote: > >> >> Sandhya, >> See inline. >> Sandhya Chawla wrote: >> >> >Hi Stephane, >> > >> >--- Stephane Bortzmeyer wrote: >> > >> > >> > >> >>On Thu, May 04, 2006 at 05:15:21AM +0100, >> >> Sandhya Chawla wrote >> >> a message of 50 lines which said: >> >> >> >> >> >> >> >>>Why are we working on providing security at each routing protocol >> >>>(application layer)? Why cant we simply use IPSEC for this? >> >>> >> >>> >> >>Wild guess from a non-expert: because IPsec only provides channel >> >>security, not data security. For instance, if I have a BGP connection >> >> >> >> >> > >> >We could use ESP will null encryption (null cipher). Using NULL as we >> really dont want to provide >> >any confidentiality. We only want to authenticate the sender and >> want to >> make sure that no one >> >mangles the packet in between. >> > >> > >> > >> >>with a peer, I can use IPsec and therefore be sure that the peer is >> >>really what it says it is. But what does it buy me when the peer >> >>announces a route? How can I be sure that he is entitled to announce >> >>this route? >> >> >> >> >> > >> >Yes, i understand the need for SO-BGP and S-BGP. What about the >> IGPs? We >> would perhaps not want to >> >go in for the complexity of issuing certificates, etc for IGPs. >> Would we? >> > >> > >> I would hope not. Though there have been experiments in this area. >> >> >If not, then why cant we simply use IPSEC to protect and auth my IGP >> data? >> > >> > >> There have been some challenges in using IPSec but the draft should be >> published soon. >> >> http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt >> >> Work is underway to provide the IPSec for OSPFv2 as well. >> >> Acee >> >> >I understand that IPSEC works best for, and is perhaps currently >> defined >> only for unicast traffic. >> >Is this the reason because of which we cant use IPSEC for IGPs (OSPF)? >> > >> >Regards, >> >Sandhya >> > >> > >> > >> >>(Analogy: showing me your passport can convince me that you are indeed >> >>Sandhya Chawla. But it does not make any difference when you tell me >> >>that Om Prakash Chautala is an honest man or not: I still have to >> >>check the information.) >> >> >> >>For the same reason, IPsec does not make the DNS safer and we need >> >>DNSsec. >> >> >> >> >> >> >> > >> > >> > >> > >> >__________________________________________________________ >> >Yahoo! India Answers: Share what you know. Learn something new. >> >http://in.answers.yahoo.com >> > >> >_______________________________________________ >> >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 Fri May 05 04:56:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbw6U-0006zN-5h; Fri, 05 May 2006 04:56:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbw6S-0006zI-KK for rpsec@ietf.org; Fri, 05 May 2006 04:56:00 -0400 Received: from mx2.nic.fr ([192.134.4.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbw6R-0001VR-Bh for rpsec@ietf.org; Fri, 05 May 2006 04:56:00 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.nic.fr (Postfix) with ESMTP id 810E826C245; Fri, 5 May 2006 10:55:58 +0200 (CEST) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id 72CFC26C242; Fri, 5 May 2006 10:55:57 +0200 (CEST) Received: from batilda.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id 6CE0E58ED19; Fri, 5 May 2006 10:55:57 +0200 (CEST) Received: by batilda.nic.fr (Postfix, from userid 1000) id 656C816A97B; Fri, 5 May 2006 10:55:57 +0200 (CEST) Date: Fri, 5 May 2006 10:55:57 +0200 From: Stephane Bortzmeyer To: Lakshminath Dondeti Message-ID: <20060505085557.GA9540@nic.fr> References: <20060504075906.GA14631@nic.fr> <20060504082605.60358.qmail@web8513.mail.in.yahoo.com> <6.2.5.6.2.20060504114213.03e90eb8@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.5.6.2.20060504114213.03e90eb8@qualcomm.com> X-Operating-System: Debian GNU/Linux 3.1 X-Kernel: Linux 2.6.8-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at mx2.nic.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: rpsec@ietf.org Subject: [RPSEC] Re: Using IPSec for Routing Protocols 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 On Thu, May 04, 2006 at 11:50:50AM -0700, Lakshminath Dondeti wrote a message of 77 lines which said: > So, Sandhya, are you saying that integrity protection in transit is > the only requirement? And, are you saying that there is no need for > the recipient to be able to verify whether the claimed route or > reachability information is in fact correct? The charter of the WG does not mention it but the ID draft-ietf-rpsec-routing-threats-07.txt is very clear that falsification of routes by a router, even authentified, is a problem. Therefore, IPsec cannot be the only approach in this WG. See section 4.5 _______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www1.ietf.org/mailman/listinfo/rpsec From rpsec-bounces@ietf.org Fri May 05 08:03:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbz1M-0002sU-6E; Fri, 05 May 2006 08:02:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbz1L-0002sP-OT for rpsec@ietf.org; Fri, 05 May 2006 08:02:55 -0400 Received: from wx-out-0102.google.com ([66.249.82.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbz1L-0000i5-9k for rpsec@ietf.org; Fri, 05 May 2006 08:02:55 -0400 Received: by wx-out-0102.google.com with SMTP id s12so543810wxc for ; Fri, 05 May 2006 05:02:55 -0700 (PDT) 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=mUy3AEkytApYt2Wt2vJaJzJKJzEPw9q8v2SxWh4Nl19yl2JlBLDJfR2u2tQEVj7EhTiF9IH/zZ5meU4KKpqJcQBdeQ1zaltnjjCLpuJO2N8pSOqc1SlDb36KtKHR16sFQHq8OzIF3UBfAVSz2HKfJcUxeazec0lDwhtdvVAvJvE= Received: by 10.70.42.17 with SMTP id p17mr964894wxp; Fri, 05 May 2006 05:02:54 -0700 (PDT) Received: by 10.70.8.12 with HTTP; Fri, 5 May 2006 05:02:53 -0700 (PDT) Message-ID: <77ead0ec0605050502t47f80d7n3bc0afe430512ff2@mail.gmail.com> Date: Fri, 5 May 2006 05:02:53 -0700 From: "Vishwas Manral" To: "Lakshminath Dondeti" Subject: Re: [RPSEC] Re: Using IPSec for Routing Protocols In-Reply-To: <6.2.5.6.2.20060504114102.057e9f98@qualcomm.com> MIME-Version: 1.0 References: <20060504082605.60358.qmail@web8513.mail.in.yahoo.com> <4459E002.2050103@cisco.com> <77ead0ec0605040525jd8cead1o346b8e6f1b7b15a0@mail.gmail.com> <6.2.5.6.2.20060504114102.057e9f98@qualcomm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: rpsec@ietf.org, msec@securemulticast.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="===============0623551642==" Errors-To: rpsec-bounces@ietf.org --===============0623551642== Content-Type: multipart/alternative; boundary="----=_Part_3503_26605297.1146830573968" ------=_Part_3503_26605297.1146830573968 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Lakshminath, I was trying to refer to the conversation on the SAAG list of which you wer= e a part. Thanks, Vishwas On 5/4/06, Lakshminath Dondeti wrote: > > At 05:25 AM 5/4/2006, Vishwas Manral wrote: > >Hi Acee, > > > >One reason we do not use IPsec is that we do not support multicast > >well in IPsec. > > This is news to me and probably to many folks in MSEC. Please take a > look at the work underway in that group. > > regards, > Lakshminath > > > I think the way it is used in OSPFv3 is itself a hack. Also in the > > end of it we are still using manual keying as well as only > > authentication so still the same as for the rpotocols. > > > >Stephen Kent would probably have the details of it. > > > >Thanks, > >Vishwas > > > > > >On 5/4/06, Acee Lindem <acee@cisco.com> wrote: > >Sandhya, > >See inline. > >Sandhya Chawla wrote: > > > > >Hi Stephane, > > > > > >--- Stephane Bortzmeyer < > > bortzmeyer@nic.fr> wrote: > > > > > > > > > > > >>On Thu, May 04, 2006 at 05:15:21AM +0100, > > >> Sandhya Chawla > > <sandhya.chawla@yahoo.co.in > wrote > > >> a message of 50 lines which said: > > >> > > >> > > >> > > >>>Why are we working on providing security at each routing protocol > > >>>(application layer)? Why cant we simply use IPSEC for this? > > >>> > > >>> > > >>Wild guess from a non-expert: because IPsec only provides channel > > >>security, not data security. For instance, if I have a BGP connection > > >> > > >> > > > > > >We could use ESP will null encryption (null cipher). Using NULL as > > we really dont want to provide > > >any confidentiality. We only want to authenticate the sender and > > want to make sure that no one > > >mangles the packet in between. > > > > > > > > > > > >>with a peer, I can use IPsec and therefore be sure that the peer is > > >>really what it says it is. But what does it buy me when the peer > > >>announces a route? How can I be sure that he is entitled to announce > > >>this route? > > >> > > >> > > > > > >Yes, i understand the need for SO-BGP and S-BGP. What about the > > IGPs? We would perhaps not want to > > >go in for the complexity of issuing certificates, etc for IGPs. Would > we? > > > > > > > >I would hope not. Though there have been experiments in this area. > > > > >If not, then why cant we simply use IPSEC to protect and auth my IGP > data? > > > > > > > >There have been some challenges in using IPSec but the draft should be > >published soon. > > > > > http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-auth-08.txt > > > >Work is underway to provide the IPSec for OSPFv2 as well. > > > >Acee > > > > >I understand that IPSEC works best for, and is perhaps currently > > defined only for unicast traffic. > > >Is this the reason because of which we cant use IPSEC for IGPs (OSPF)? > > > > > >Regards, > > >Sandhya > > > > > > > > > > > >>(Analogy: showing me your passport can convince me that you are indee= d > > >>Sandhya Chawla. But it does not make any difference when you tell me > > >>that Om Prakash Chautala is an honest man or not: I still have to > > >>check the information.) > > >> > > >>For the same reason, IPsec does not make the DNS safer and we need > > >>DNSsec. > > >> > > >> > > >> > > > > > > > > > > > > > > >__________________________________________________________ > > >Yahoo! India Answers: Share what you know. Learn something new. > > >http://in.answers.yahoo.com > > > > > >_______________________________________________ > > >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 > > ------=_Part_3503_26605297.1146830573968 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Lakshminath,
 
I was trying to refer to the conversation on the SAAG list of which yo= u were a part.
 
Thanks,
Vishwas

 
On 5/4/06, L= akshminath Dondeti <ldondet= i@qualcomm.com> wrote:
At 05:25 AM 5/4/2006, Vishwas Ma= nral wrote:
>Hi Acee,
>
>One reason we do not use IPsec i= s that we do not support multicast
>well in IPsec.

This is news to me and probably to many folks= in MSEC.  Please take a
look at the work underway in that gro= up.

regards,
Lakshminath

>  I think the way i= t is used in OSPFv3 is itself a hack. Also in the
> end of it we are still using manual keying as well as only
>= authentication so still the same as for the rpotocols.
>
>Step= hen Kent would probably have the details of it.
>
>Thanks,
>Vishwas
>
>
>On 5/4/06, Acee Lindem <<mailto:acee@cisco.com>acee@cisco.com> wrote:
>Sandhya,
>See inlin= e.
>Sandhya Chawla wrote:
>
> >Hi Stephane,
> >=
> >--- Stephane Bortzmeyer <
> <mailto:bortzmeyer@nic.fr> bortzmeyer@nic.fr> wrote:
> >
> >
> >
= > >>On Thu, May 04, 2006 at 05:15:21AM +0100,
> >> San= dhya Chawla
> <<mailto: sandhya.chawla@yahoo.co.in>sandhya.chawla@yahoo.co.in > wrote
> >> a message o= f 50 lines which said:
> >>
> >>
> >>
> >>>Why are we working on providing security at each routi= ng protocol
> >>>(application layer)? Why cant we simply use= IPSEC for this?
> >>>
> >>>
> >>= Wild guess from a non-expert: because IPsec only provides channel
> >>security, not data security. For instance, if I have a BGP= connection
> >>
> >>
> >
> >We c= ould use ESP will null encryption (null cipher). Using NULL as
> we r= eally dont want to provide
> >any confidentiality. We only want to authenticate the sender a= nd
> want to make sure that no one
> >mangles the packet in = between.
> >
> >
> >
> >>with a peer= , I can use IPsec and therefore be sure that the peer is
> >>really what it says it is. But what does it buy me when th= e peer
> >>announces a route? How can I be sure that he is enti= tled to announce
> >>this route?
> >>
> >&= gt;
> >
> >Yes, i understand the need for SO-BGP and S-BGP. = What about the
> IGPs? We would perhaps not want to
> >go in= for the complexity of issuing certificates, etc for IGPs. Would we?
> >
> >
>I would hope not. Though there have been expe= riments in this area.
>
> >If not, then why cant we simply u= se IPSEC to protect and auth my IGP data?
> >
> >
>There have been some challenges in using IPSec but the draft should be<= br>>published soon.
>
><http://www.ietf.org/inter= net-drafts/draft-ietf-ospf-ospfv3-auth-08.txt >http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-= auth-08.txt
>
>Work is underway to provide the IPSec for OS= PFv2 as well.
>
>Acee
>
> >I understand that IPSEC works best= for, and is perhaps currently
> defined only for unicast traffic.> >Is this the reason because of which we cant use IPSEC for IGPs (O= SPF)?
> >
> >Regards,
> >Sandhya
> >
>= >
> >
> >>(Analogy: showing me your passport can c= onvince me that you are indeed
> >>Sandhya Chawla. But it does = not make any difference when you tell me
> >>that Om Prakash Chautala is an honest man or not: I still = have to
> >>check the information.)
> >>
> &g= t;>For the same reason, IPsec does not make the DNS safer and we need
> >>DNSsec.
> >>
> >>
> >>=
> >
> >
> >
> >
> >__________= ________________________________________________
> >Yahoo! India A= nswers: Share what you know. Learn something new.
> ><http://in.answers.= yahoo.com>http://in.answers.= yahoo.com
> >
> >____________________________________= ___________
> >RPSEC mailing list
> ><mailto:RPSEC@ietf.org>RPSEC= @ietf.org
> > https://www1.ietf.org/mailman/listinfo/rpsec
> >
> ><= br>> >
>
>_______________________________________________=
>RPSEC mailing list
><mailto: RPSEC@ietf.org>RPSEC@ietf.org<= br>>https://www= 1.ietf.org/mailman/listinfo/rpsec
>
>
>______________= _________________________________
>RPSEC mailing list
>RPSEC@i= etf.org
>https://www1.ietf.org/mailman/listinfo/rpsec


------=_Part_3503_26605297.1146830573968-- --===============0623551642== 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 --===============0623551642==--