From ipsec-bounces@ietf.org Tue May 02 05:53:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FarYf-0003X9-5u; Tue, 02 May 2006 05:52:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FarYe-0003Wl-EU for ipsec@ietf.org; Tue, 02 May 2006 05:52:40 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FarYZ-0002GJ-P6 for ipsec@ietf.org; Tue, 02 May 2006 05:52:40 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 2B6DF1FAD3B; Tue, 2 May 2006 11:52:32 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29000-01-92; Tue, 2 May 2006 11:52:32 +0200 (CEST) Received: from mail.dif.um.es (dif.um.es [155.54.204.60]) by mail.um.es (Postfix) with ESMTP id EDEF61FAC58; Tue, 2 May 2006 11:52:26 +0200 (CEST) Received: from diffie (unknown [155.54.210.175]) by mail.dif.um.es (Postfix) with ESMTP id 686E21054004; Tue, 2 May 2006 11:51:02 +0200 (CEST) From: Alejandro Perez Mendez To: Yoav Nir Content-Type: text/plain Date: Tue, 02 May 2006 11:52:34 +0200 Message-Id: <1146563554.11429.10.camel@diffie> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ipsec@ietf.org Subject: [Ipsec] Original initiator and responder after an IKE_SA rekeying in Repeated authentication scenario in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Hi! We need some clarifications about how to know who are the original initiator and responder in Repeated Authentication scenario in IKEv2. The Repeated Authentication document assumes that only the original responder can send the AUTH_LIFETIME notification, but after an IKE_SA rekeying, the original responder can change (see IKEv2 clarifications document section 5.9). After that, the original responder may be different to the "original authentication responder" (the peer that acts as responder in the IKE_AUTH exchange). In this case, who is the "original responder" in order to send AUTH_LIFETIME notifications? -- Alejandro Perez Mendez Pedro J. Fernandez Ruiz University of Murcia OpenIKEv2 http://openikev2.sf.net _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 02 06:01:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fargp-0001P8-Gh; Tue, 02 May 2006 06:01:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fargo-0001P3-JW for ipsec@ietf.org; Tue, 02 May 2006 06:01:06 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fargn-0002kS-2u for ipsec@ietf.org; Tue, 02 May 2006 06:01:06 -0400 Received: from [194.29.46.41] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k42A0v4Q023144; Tue, 2 May 2006 13:00:58 +0300 (IDT) Message-ID: <44572DD8.3010301@checkpoint.com> Date: Tue, 02 May 2006 13:00:56 +0300 From: Yoav Nir Organization: Check Point User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <1146563554.11429.10.camel@diffie> In-Reply-To: <1146563554.11429.10.camel@diffie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ipsec@ietf.org Subject: [Ipsec] Re: Original initiator and responder after an IKE_SA rekeying in Repeated authentication scenario in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org By "original responder" I mean the party that was Responder in the original Initial and AUTH exchanges, so perhaps "original authentication responder" would be better. The reason for the whole "authentication timeout" is to ask the "original authentication initiator" to do the whole Initial+AUTH again, because for some reason the original authentication responder can't do it (EAP is one good example). This fact is not altered by the role reversal that happens in rekeying. Hope this helps. Yoav Alejandro Perez Mendez wrote: > Hi! We need some clarifications about how to know who are the original > initiator and responder in Repeated Authentication scenario in IKEv2. > > The Repeated Authentication document assumes that only the original > responder can send the AUTH_LIFETIME notification, but after an IKE_SA > rekeying, the original responder can change (see IKEv2 clarifications > document section 5.9). After that, the original responder may be > different to the "original authentication responder" (the peer that acts > as responder in the IKE_AUTH exchange). > > In this case, who is the "original responder" in order to send > AUTH_LIFETIME notifications? > > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 02 06:01:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FarhX-00024y-JU; Tue, 02 May 2006 06:01:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FarhV-0001z9-JJ for ipsec@ietf.org; Tue, 02 May 2006 06:01:49 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FarhU-0002lk-2z for ipsec@ietf.org; Tue, 02 May 2006 06:01:49 -0400 Received: from [194.29.46.41] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k42A1j4Q023357; Tue, 2 May 2006 13:01:45 +0300 (IDT) Message-ID: <44572E07.1080100@checkpoint.com> Date: Tue, 02 May 2006 13:01:43 +0300 From: Yoav Nir Organization: Check Point User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <1146563554.11429.10.camel@diffie> In-Reply-To: <1146563554.11429.10.camel@diffie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ipsec@ietf.org Subject: [Ipsec] Re: Original initiator and responder after an IKE_SA rekeying in Repeated authentication scenario in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org By "original responder" I mean the party that was Responder in the original Initial and AUTH exchanges, so perhaps "original authentication responder" would be better. The reason for the whole "authentication timeout" is to ask the "original authentication initiator" to do the whole Initial+AUTH again, because for some reason the original authentication responder can't do it (EAP is one good example). This fact is not altered by the role reversal that happens in rekeying. Hope this helps. Yoav Alejandro Perez Mendez wrote: > Hi! We need some clarifications about how to know who are the original > initiator and responder in Repeated Authentication scenario in IKEv2. > > The Repeated Authentication document assumes that only the original > responder can send the AUTH_LIFETIME notification, but after an IKE_SA > rekeying, the original responder can change (see IKEv2 clarifications > document section 5.9). After that, the original responder may be > different to the "original authentication responder" (the peer that acts > as responder in the IKE_AUTH exchange). > > In this case, who is the "original responder" in order to send > AUTH_LIFETIME notifications? > > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 03 15:39:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbNBr-0005JY-Dx; Wed, 03 May 2006 15:39:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbNBp-0005IZ-Vq for ipsec@ietf.org; Wed, 03 May 2006 15:39:13 -0400 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FbNBo-0006rS-Ov for ipsec@ietf.org; Wed, 03 May 2006 15:39:13 -0400 Received: (qmail 12280 invoked by uid 0); 3 May 2006 19:32:25 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.126.181.72) by woodstock.binhost.com with SMTP; 3 May 2006 19:32:25 -0000 Message-Id: <7.0.0.16.2.20060503152913.07452050@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 03 May 2006 15:32:29 -0400 To: ipsec@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ipsec] draft-housley-gigabeam-radio-link-encrypt-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org http://www.ietf.org/internet-drafts/draft-housley-gigabeam-radio-link-encrypt-00.txt Pleas take a look at this document. It makes use of IKE to establish cryptographic keys to encrypt a point-to-point radio link. Review of the IKE-related portions of this document from members of this mail list would be greatly appreciated. Thanks in advance, Russ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 04 05:30:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fba9d-0001ue-JA; Thu, 04 May 2006 05:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fba9c-0001uW-9F for ipsec@ietf.org; Thu, 04 May 2006 05:29:48 -0400 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fba9b-0000Lk-Jp for ipsec@ietf.org; Thu, 04 May 2006 05:29:48 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k449Tje3027827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 May 2006 12:29:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k449TiIk026379; Thu, 4 May 2006 12:29:44 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17497.51592.37783.866971@fireball.kivinen.iki.fi> Date: Thu, 4 May 2006 12:29:44 +0300 From: Tero Kivinen To: Russ Housley Subject: [Ipsec] draft-housley-gigabeam-radio-link-encrypt-00.txt In-Reply-To: <7.0.0.16.2.20060503152913.07452050@vigilsec.com> References: <7.0.0.16.2.20060503152913.07452050@vigilsec.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 14 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Russ Housley writes: > http://www.ietf.org/internet-drafts/draft-housley-gigabeam-radio-link-encrypt-00.txt > > Pleas take a look at this document. It makes use of IKE to establish > cryptographic keys to encrypt a point-to-point radio link. Review of > the IKE-related portions of this document from members of this mail > list would be greatly appreciated. As this uses only agressive mode the security considerations should list the known problems with the aggressive mode (i.e. no DH-group negotiation, no identity protection, no protection against DoS attacks) and also general problems in the IKEv1, not mentioned in the RFC2409 because those were found later (some parts of message not authenticated (header, version rollback, commit bit, vendor-IDs, initial contact)). It should also probably try to specify what to do some problematic cases in IKEv1, i.e. what to do with life times (what to send, what to accept), how to handle the case that the delete notifications can (and will) be lost, thus some kind of black hole detection might be needed, how to recover from various problems (initial contact), how to do the rekey properly, i.e. when new keying material is negotiated with the different KEYSEL bit (i.e. different bit in the SPI), when the other end can switch to use it (i.e. probably both ends install the inbound handling before the last message, and the responder starts using it after seeing message 3 of quick mode, and initiator only after it sees that responder have started using it). There might also need to be some text explaining how to do the delete of the previous SA cleanly, as it might happen that the delete for that is lost and that might cause the next rekey selects wrong SA (there is only 1 bit selecting keys there) etc.... I.e. if this protocol is supposed to run over the obsolete IKEv1 protocol, it should also try to explain the problems and probably also provide some solutions to the problems in it. Of course the easy fix would be to select to use IKEv2 that already fixes all those problems... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 11 00:17:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe2Yv-0000kF-Mx; Thu, 11 May 2006 00:14:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe2Yu-0000k7-At for ipsec@ietf.org; Thu, 11 May 2006 00:14:04 -0400 Received: from web53406.mail.yahoo.com ([206.190.37.53]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fe2Yp-0001vJ-DQ for ipsec@ietf.org; Thu, 11 May 2006 00:14:04 -0400 Received: (qmail 67055 invoked by uid 60001); 11 May 2006 04:13:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YfgpzpETdpZVmbIWkHLa8XB9YLbA3pfPLrW3Vxir7M4lV7DEnBUNaRz9DrBqRjA/0lQRKrKkTpMA0+wMZEmyp2JIqxpntuaZckn/DRyh3N/JF1EM3OZFloeaCj973o9wL8mRCX8uptjqd9rYroZ+6ebvQ8A4wot/TNauMNfePPM= ; Message-ID: <20060511041359.67053.qmail@web53406.mail.yahoo.com> Received: from [152.118.24.10] by web53406.mail.yahoo.com via HTTP; Wed, 10 May 2006 21:13:59 PDT Date: Wed, 10 May 2006 21:13:59 -0700 (PDT) From: dani arisandy To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ipsec] Test Bed IPv6 with IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0824986027==" Errors-To: ipsec-bounces@ietf.org --===============0824986027== Content-Type: multipart/alternative; boundary="0-2097330229-1147320839=:66003" Content-Transfer-Encoding: 8bit --0-2097330229-1147320839=:66003 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear all, Right now, I am a college student who is working on my final assignment to graduate from my university. My topic is about the deployment of IPSec in the IPv6 local network. So I build a small network in the lab that contain 4 PCs with Windows XP SP 2 and I PC with Windows Server 2003. I use two of them as routers and the other 2 as clients. I've read an article that we have to configure the IPSec manually if we want to deploy it on IPv6 network. I've already followed the instructions but still it didn't work. When I try to load the SPD file there is a message "Bad IPv6 Address". I configured the address of their interface manually by using public address : 2001:0DC6:FF00::/48 and I do subnetting for my test bed. I've also tried to use the address that Windows give automatically (link local address and site local address). But those address don't change anything, there is still the message above. So, is there anyone who knows why?? I am looking forward to the replies for my problems. Thank you!!!! Regards, Dani Arisandy --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. --0-2097330229-1147320839=:66003 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear all,
Right now, I am a college student who is working on my final assignment to graduate from my university. My topic is about the deployment of IPSec in the IPv6 local network. So I build a small network in the lab that contain 4 PCs with Windows XP SP 2 and I PC with Windows Server 2003. I use two of them as routers and the other 2 as clients.
I've read an article that we have to configure the IPSec manually if we want to deploy it on IPv6 network. I've already followed the instructions but still it didn't work. When I try to load the SPD file there is a message "Bad IPv6 Address".
I configured the address of their interface manually by using public address : 2001:0DC6:FF00::/48 and I do subnetting for my test bed.
I've also tried to use the address that Windows give automatically (link local address and site local address). But those address don't change anything, there is still the message above.
So, is there anyone who knows why?? I am looking forward to the replies for my problems.

Thank you!!!!

Regards,

Dani Arisandy

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. --0-2097330229-1147320839=:66003-- --===============0824986027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0824986027==-- From ipsec-bounces@ietf.org Sat May 13 03:25:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeoSt-0007VU-EI; Sat, 13 May 2006 03:23:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeoSs-0007VP-R4 for ipsec@ietf.org; Sat, 13 May 2006 03:23:02 -0400 Received: from colo.trepanning.net ([69.55.226.174] helo=mail1.trepanning.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeoSr-0001Kj-HZ for ipsec@ietf.org; Sat, 13 May 2006 03:23:02 -0400 Received: from www.trepanning.net (localhost [127.0.0.1]) by mail1.trepanning.net (Postfix) with ESMTP id 3655D9667F0; Sat, 13 May 2006 00:22:50 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 13 May 2006 00:22:50 -0700 (PDT) Message-ID: <47259.69.12.173.8.1147504970.squirrel@www.trepanning.net> In-Reply-To: <17458.25837.559125.769859@fireball.acr.fi> References: <7.0.0.16.2.20060329193457.02cd98e8@vigilsec.com> <17458.25837.559125.769859@fireball.acr.fi> Date: Sat, 13 May 2006 00:22:50 -0700 (PDT) Subject: Re: [Ipsec] IKEv1 Security Considerations From: "Dan Harkins" To: "Tero Kivinen" User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ipsec@ietf.org, Russ Housley X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Hi Tero, I can't really say I'm too happy with the term "consumed entropy" either but there is a reason you want to rekey the IKE SA after a certain number of Quick Mode rekeys. You're right that the value of breaking the Diffie-Hellman secret increases when more keys are derived from it. It also increases when the information being protected by those keys is high. Regardless though, you want to rekey the IKE SA after a certain number of Quick Mode rekeys. Can you articulate a reason why that does not use the words "consumed" and "entropy"? Dan. > Russ Housley writes: >> RFC 2409 says: >> >> Repeated re-keying using Quick Mode can consume the entropy of the >> Diffie-Hellman shared secret. Implementors should take note of thi= s >> fact and set a limit on Quick Mode Exchanges between >> exponentiations. >> This memo does not prescribe such a limit. >> >> What limit do implementors impose? > > Usually none. > > There are quite a many people who do not really agree on that text. I > do not think entropy really get consumed, but of course the value of > breaking that one Diffie-Hellman increases when more and more keying > material is derived from it. > > In most implementations IKE SAs do have lifetime that is around few > hours (from 4-8 hours or so), and using gigabit link with 3DES means > you need to rekey avery few minutes, which would mean that you would > be doing around 50 quick mode exchanges before the IKE SA expires. > The 50 unknown keying materials generated from the same Diffie-Hellman > secret, should yet give any way to crack that Diffie-Hellman itself. > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 15 18:43:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfljD-0002S6-Ds; Mon, 15 May 2006 18:39:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfljB-0002Ry-Gn; Mon, 15 May 2006 18:39:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfljA-0000pm-9J; Mon, 15 May 2006 18:39:49 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k4FMdlXO008237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 May 2006 22:39:48 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fflj9-00015a-Qx; Mon, 15 May 2006 18:39:47 -0400 X-test-idtracker: no To: IETF-Announce , saag@mit.edu, ipsec@ietf.org From: The IESG Message-Id: Date: Mon, 15 May 2006 18:39:47 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Subject: [Ipsec] Last Call: 'GigaBeam High-Speed Radio Link Encryption' to Informational RFC (draft-housley-gigabeam-radio-link-encrypt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'GigaBeam High-Speed Radio Link Encryption ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-06-12. This document has already received review on the ipsec mailing list, and the author expects to make changes to address this review: http://www1.ietf.org/mail-archive/web/ipsec/current/msg02065.html The file can be obtained via http://www.ietf.org/internet-drafts/draft-housley-gigabeam-radio-link-encrypt-00.txt _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 23 17:40:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FieaP-0002vF-OD; Tue, 23 May 2006 17:38:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FieaO-0002vA-IG for ipsec@ietf.org; Tue, 23 May 2006 17:38:40 -0400 Received: from web36407.mail.mud.yahoo.com ([209.191.85.142]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FieaN-0005TH-6p for ipsec@ietf.org; Tue, 23 May 2006 17:38:40 -0400 Received: (qmail 32653 invoked by uid 60001); 23 May 2006 21:38:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ustb1Essx6ys1AD9zceoMELGRfxsmx1bU8l6JLAEvmr0GRaALeVOZr4nyi6HvFFnmIqyScf8yWDWQkkT/U8dGN56G3FUHlnvf7ur/U7513Ij2k3tO83qHfXNlMW+Kw2ZHeJqBfqh+EibNPWRMMrZ1H86ebSkdJONY2UcyiZw5vQ= ; Message-ID: <20060523213838.32651.qmail@web36407.mail.mud.yahoo.com> Received: from [201.198.239.67] by web36407.mail.mud.yahoo.com via HTTP; Tue, 23 May 2006 16:38:38 CDT Date: Tue, 23 May 2006 16:38:38 -0500 (CDT) From: Randall Solano To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ipsec] Request SCTP over IPSEC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Hello: I´d like to know if i can use IPsec with SCTP. My network design is using between MGCs and MGs the Megaco Protocol, but i don´t if this is correct: MEGACO/SCTP/IP/IPSEC/ETHERNET/PHYSICAL LAYER Other point if i can use SCTP between MGCs different, like this: MGC(a)------SigTRAN-------MGC(2) All of this Protocol stack is: isup/m3ua/sctp/ip/ipsec/ethernet/physical Cheers, Ran __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 23 18:20:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FifCB-0000qB-4D; Tue, 23 May 2006 18:17:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FifC9-0000q6-MF for ipsec@ietf.org; Tue, 23 May 2006 18:17:41 -0400 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FifC8-0007IO-Dk for ipsec@ietf.org; Tue, 23 May 2006 18:17:41 -0400 Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 80B4FFB2EB; Tue, 23 May 2006 18:17:33 -0400 (EDT) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 4C8153C02BD; Tue, 23 May 2006 18:17:32 -0400 (EDT) Date: Tue, 23 May 2006 18:17:32 -0400 From: "Steven M. Bellovin" To: Randall Solano Subject: Re: [Ipsec] Request SCTP over IPSEC Message-Id: <20060523181732.14d7e931.smb@cs.columbia.edu> In-Reply-To: <20060523213838.32651.qmail@web36407.mail.mud.yahoo.com> References: <20060523213838.32651.qmail@web36407.mail.mud.yahoo.com> Organization: Columbia University X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org On Tue, 23 May 2006 16:38:38 -0500 (CDT), Randall Solano wrote: > Hello: >=20 > I=B4d like to know if i can use IPsec with SCTP. My > network design is using between MGCs and MGs the > Megaco Protocol, but i don=B4t if this is correct: >=20 > MEGACO/SCTP/IP/IPSEC/ETHERNET/PHYSICAL LAYER=20 >=20 > Other point if i can use SCTP between MGCs different, > like this: >=20 > MGC(a)------SigTRAN-------MGC(2) >=20 > All of this Protocol stack is: >=20 > isup/m3ua/sctp/ip/ipsec/ethernet/physical=20 >=20 I'm not sure what you mean by "can" you use it. SCTP with IPsec is defined in RFC 3554. However, your stack diagrams are wrong. IPsec is on top of IP; if you're using tunnel mode, there's a second IP header on top of IPsec. Thus, your first diagram should be MEGACO/SCTP/IPSEC/IP/ETHERNET/PHYSICAL LAYER=20 for transport mode and MEGACO/SCTP/IP/IPSEC/IP/ETHERNET/PHYSICAL LAYER=20 for tunnel mode. (I don't remember which Megaco wants.) --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 23 18:22:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FifEP-0002He-5U; Tue, 23 May 2006 18:20:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FifEN-0002HY-1y for ipsec@ietf.org; Tue, 23 May 2006 18:19:59 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FifEL-0007aM-SG for ipsec@ietf.org; Tue, 23 May 2006 18:19:59 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FifEL-0001gb-4i; Tue, 23 May 2006 18:19:57 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060523213838.32651.qmail@web36407.mail.mud.yahoo.com> References: <20060523213838.32651.qmail@web36407.mail.mud.yahoo.com> Date: Tue, 23 May 2006 18:17:42 -0400 To: Randall Solano From: Stephen Kent Subject: Re: [Ipsec] Request SCTP over IPSEC Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org At 4:38 PM -0500 5/23/06, Randall Solano wrote: >Hello: > >I=B4d like to know if i can use IPsec with SCTP. My >network design is using between MGCs and MGs the >Megaco Protocol, but i don=B4t if this is correct: > >MEGACO/SCTP/IP/IPSEC/ETHERNET/PHYSICAL LAYER > >Other point if i can use SCTP between MGCs different, >like this: > >MGC(a)------SigTRAN-------MGC(2) > >All of this Protocol stack is: > >isup/m3ua/sctp/ip/ipsec/ethernet/physical > > >Cheers, > >Ran Ran, yes you can use IPsec with SCTP in this context.=20 Depending on the IPsec implementation, the stack=20 might not show IPsec as below IP, but that's a=20 minor detail. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 24 19:02:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj2I4-0008SI-8m; Wed, 24 May 2006 18:57:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj2I3-0008SD-T0 for ipsec@ietf.org; Wed, 24 May 2006 18:57:19 -0400 Received: from web36413.mail.mud.yahoo.com ([209.191.85.148]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fj2I2-0007fg-KK for ipsec@ietf.org; Wed, 24 May 2006 18:57:19 -0400 Received: (qmail 92129 invoked by uid 60001); 24 May 2006 22:57:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kcW0XWmiI0pBHB2gAQdX0cPABv0i/5r7+w1hjiM2z8OEBYSk0T7yqqNnNGSNKYIESpnNjWGM3HwrMzSASB/DOFBM0Sxgp1tYS5TNpMTOR/kHzyoOAnFzYubZydxRvwlqqmW7pK2n/OjEPDjBxOWVL1IXVKw0SBcTNhpkpC2uKzQ= ; Message-ID: <20060524225718.92127.qmail@web36413.mail.mud.yahoo.com> Received: from [201.198.239.67] by web36413.mail.mud.yahoo.com via HTTP; Wed, 24 May 2006 17:57:18 CDT Date: Wed, 24 May 2006 17:57:18 -0500 (CDT) From: Randall Solano To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ipsec] Ipsec // Tunn-Encry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Hello All: IPsec for signaling links (control call) between MGCs and MG. What would you use? IPsec Tunneling or Encry. Ran __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 25 03:32:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjAIR-0007Wq-1X; Thu, 25 May 2006 03:30:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjAIP-0007Wl-BX for ipsec@ietf.org; Thu, 25 May 2006 03:30:13 -0400 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjAIO-00065O-47 for ipsec@ietf.org; Thu, 25 May 2006 03:30:13 -0400 Received: by py-out-1112.google.com with SMTP id n25so2452453pyg for ; Thu, 25 May 2006 00:30:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=bqVkyBYzHuJHFZVtNWCsG+8PB8BjNhUdCAxk9bU6fNROfcy0bcdEqcpAH2AEOwJgpmsroeUJUHuxz+NANDtk3/K9vUIfx1WWphMeFm7mm8AGlsmRImavyi76HYsw8WDKJcHRj6wU+Gwo3Fmkums6MXQYc0B4iQLiZ1ggeGk0rCA= Received: by 10.35.91.10 with SMTP id t10mr889095pyl; Thu, 25 May 2006 00:30:11 -0700 (PDT) Received: by 10.70.7.14 with HTTP; Thu, 25 May 2006 00:30:11 -0700 (PDT) Message-ID: <77ead0ec0605250030i6a36e546k525bb2cdbac94d5c@mail.gmail.com> Date: Thu, 25 May 2006 13:00:11 +0530 From: "Vishwas Manral" To: ipsec@ietf.org, "Russ Housley" MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [Ipsec] draft-manral-ipsec-rfc4305-bis-errata-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0892096645==" Errors-To: ipsec-bounces@ietf.org --===============0892096645== Content-Type: multipart/alternative; boundary="----=_Part_70290_4820353.1148542211801" ------=_Part_70290_4820353.1148542211801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Russ, Based on comments on this mailing list that we would rather have the RFC rewritten(-bis draft) rather than an errata draft, I have posted the draft http://www.ietf.org/internet-drafts/draft-manral-ipsec-rfc4305-bis-errata-0= 0.txt As we already have had a lot of discussion on the topic, I would want to know how I should progress the draft from here. Any comments on this version of the draft would be very welcome. Thanks, Vishwas ------=_Part_70290_4820353.1148542211801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi Russ,
 
Based on comments on this mailing list that we would rather have the R= FC rewritten(-bis draft) rather than an errata draft, I have posted th= e draft
 
As we already have had a lot of discussion on the topic, I would want = to know how I should progress the draft from here. 
 
Any comments on this version of the draft would be very welcome.
 
Thanks,
Vishwas
 
------=_Part_70290_4820353.1148542211801-- --===============0892096645== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0892096645==-- From ipsec-bounces@ietf.org Thu May 25 04:45:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjBSQ-000609-AA; Thu, 25 May 2006 04:44:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjBSO-0005zy-Kh for ipsec@ietf.org; Thu, 25 May 2006 04:44:36 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjBSN-0003mY-3O for ipsec@ietf.org; Thu, 25 May 2006 04:44:36 -0400 Received: from [194.29.46.41] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k4P8iL40009394; Thu, 25 May 2006 11:44:21 +0300 (IDT) Message-ID: <44756E65.5020806@checkpoint.com> Date: Thu, 25 May 2006 11:44:21 +0300 From: Yoav Nir Organization: Check Point User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Randall Solano Subject: Re: [Ipsec] Ipsec // Tunn-Encry References: <20060524225718.92127.qmail@web36413.mail.mud.yahoo.com> In-Reply-To: <20060524225718.92127.qmail@web36413.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by michael.checkpoint.com id k4P8iL40009394 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Hi Ran. First, this is the IPsec mailing list, so you should not assume that=20 everybody knows what an MGC is. Anyway, the answer depends on the MGC and MG. If they're both=20 IPsec-capable computers, they don't need tunneling. If they're behind=20 IPsec-capable gateways, they do need tunneling. The question is whether the signaling info is secret - whether it is=20 required that it be hidden (encrypted) or it's enough that the MG know=20 that it really came from the MGC. If you only need authentication AH is=20 enough. If you need encryption, you need ESP. This really depends on the=20 application requirements. So, for IPsec-capable MG and MGC, you can use Transport mode IPsec. For=20 non-IPsec capable peers, you need tunnel mode. For authentication only you need AH. For encryption, you need ESP. For some applications (I have no idea about yours) there is some=20 specification of what kind of IPsec to apply. For example, L2TP=20 mandates ESP in Transport mode. If there is such a standard for MGC-MG=20 connections, you should probably stick with that. Yoav Randall Solano wrote: > Hello All: > > IPsec for signaling links (control call) between MGCs > and MG. > What would you use? IPsec Tunneling or Encry. > > > > Ran > > > __________________________________________________ > Correo Yahoo! > Espacio para todos tus mensajes, antivirus y antispam =A1gratis!=20 > Reg=EDstrate ya - http://correo.espanol.yahoo.com/=20 > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > =20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 25 11:56:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIAE-00085Z-AT; Thu, 25 May 2006 11:54:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIAD-00085E-CZ for ipsec@ietf.org; Thu, 25 May 2006 11:54:17 -0400 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjIAC-00052O-4I for ipsec@ietf.org; Thu, 25 May 2006 11:54:17 -0400 Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 96538FB2CF; Thu, 25 May 2006 11:54:10 -0400 (EDT) Received: by berkshire.machshav.com (Postfix, from userid 54047) id B906E3C000F; Thu, 25 May 2006 11:53:48 -0400 (EDT) Date: Thu, 25 May 2006 11:53:48 -0400 From: "Steven M. Bellovin" To: Randall Solano Subject: Re: [Ipsec] Ipsec // Tunn-Encry Message-Id: <20060525115348.85bd9b5b.smb@cs.columbia.edu> In-Reply-To: <20060524225718.92127.qmail@web36413.mail.mud.yahoo.com> References: <20060524225718.92127.qmail@web36413.mail.mud.yahoo.com> Organization: Columbia University X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org On Wed, 24 May 2006 17:57:18 -0500 (CDT), Randall Solano wrote: > Hello All: > > IPsec for signaling links (control call) between MGCs > and MG. > What would you use? IPsec Tunneling or Encry. > See RFC 3525; it describes how to use IPsec for Megaco. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 25 19:48:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjPWm-0007AY-7i; Thu, 25 May 2006 19:46:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjPWl-0007AT-PH for ipsec@ietf.org; Thu, 25 May 2006 19:46:03 -0400 Received: from web55512.mail.re4.yahoo.com ([206.190.58.221]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FjPWg-0005eW-Gd for ipsec@ietf.org; Thu, 25 May 2006 19:46:03 -0400 Received: (qmail 30376 invoked by uid 60001); 25 May 2006 20:39:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CsnHK/0p4lRPPdPxIZBz9yL1eKCgOZqjFzAxddiMkOMwjYEFlm4LvNKT5XQGucRVHkyiRmZdXfof419P7yWJm0YtE561BrYX2jqyAwpnTnRw/aJZq6VX+BymG4eB1odheISBgOOlkMAPCE3H1Ou6DMfn5vk9wj08pFPXDuXhC1Q= ; Message-ID: <20060525203916.30374.qmail@web55512.mail.re4.yahoo.com> Received: from [201.198.239.67] by web55512.mail.re4.yahoo.com via HTTP; Thu, 25 May 2006 20:39:16 GMT Date: Thu, 25 May 2006 20:39:16 +0000 (GMT) From: Noel Keith To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ipsec] Tunneling IPSec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Hello IPSec Forum: What´s RFC of Transport IPSec? N. ___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 25 19:52:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjPcm-0003KF-RK; Thu, 25 May 2006 19:52:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjPcm-0003GM-7A for ipsec@ietf.org; Thu, 25 May 2006 19:52:16 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjPcg-0006RM-SV for ipsec@ietf.org; Thu, 25 May 2006 19:52:16 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k4PNq9QU004476 for ; Thu, 25 May 2006 16:52:10 -0700 (PDT) Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k4PNq9e3020366 for ; Thu, 25 May 2006 19:52:09 -0400 (EDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k4PNpC97001116; Thu, 25 May 2006 19:51:12 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.13.6+Sun/8.13.6/Submit) id k4PNpCmJ001115; Thu, 25 May 2006 19:51:12 -0400 (EDT) Date: Thu, 25 May 2006 19:51:12 -0400 From: Dan McDonald To: Noel Keith Subject: Re: [Ipsec] Tunneling IPSec Message-ID: <20060525235112.GG1012@everywhere.east.sun.com> References: <20060525203916.30374.qmail@web55512.mail.re4.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline In-Reply-To: <20060525203916.30374.qmail@web55512.mail.re4.yahoo.com> User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Networking & Security Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nwkea-mail-5.sun.com id k4PNq9QU004476 X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org On Thu, May 25, 2006 at 08:39:16PM +0000, Noel Keith wrote: > Hello IPSec Forum: >=20 > What=B4s RFC of Transport IPSec? Same as the ones for Tunnelling IPsec: THE OLD ONE: RFC 2401 & friends. THE NEW ONE: RFC 4301 & friends. Dan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 25 23:50:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjTKH-0005tH-0M; Thu, 25 May 2006 23:49:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjTKF-0005oZ-QW for ipsec@ietf.org; Thu, 25 May 2006 23:49:23 -0400 Received: from mail.flextronicssoftware.com ([203.187.132.2] helo=delta.hssblr.co.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjTKB-0002d2-GQ for ipsec@ietf.org; Thu, 25 May 2006 23:49:23 -0400 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.13.6/8.13.6) with ESMTP id l4O3mSiU025879; Thu, 24 May 2007 09:18:29 +0530 In-Reply-To: <20060525235112.GG1012@everywhere.east.sun.com> To: Dan McDonald Subject: Re: [Ipsec] Tunneling IPSec MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Sri Pavani B S Date: Fri, 26 May 2006 09:18:09 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 05/26/2006 09:18:15 AM, Serialize complete at 05/26/2006 09:18:15 AM X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1569116662==" Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1569116662== Content-Type: multipart/alternative; boundary="=_alternative 0014E8716525717A_=" This is a multipart message in MIME format. --=_alternative 0014E8716525717A_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable how about Remote IPSec ? Pavani Dan McDonald =20 05/26/2006 05:21 AM To Noel Keith cc ipsec@ietf.org Subject Re: [Ipsec] Tunneling IPSec On Thu, May 25, 2006 at 08:39:16PM +0000, Noel Keith wrote: > Hello IPSec Forum: >=20 > What=B4s RFC of Transport IPSec? Same as the ones for Tunnelling IPsec: THE OLD ONE: RFC 2401 & friends. THE NEW ONE: RFC 4301 & friends. Dan =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec *********************** FSS-Unclassified *********************** --=_alternative 0014E8716525717A_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
how about Remote IPSec ?

Pavani


Dan McDonald <danm= cd@sun.com>

05/26/2006 05:21 AM

To
Noel Keith <noel=5Fk= eith=5Fnk@yahoo.com.ar>
cc
ipsec@ietf.org
Subject
Re: [Ipsec] Tunneling I= PSec





On Thu, May 25, 2006 at 08:39:16PM +0000, Noel Keith wrote:
> Hello IPSec Forum:
>
> What=B4s RFC of Transport IPSec?

Same as the ones for Tunnelling IPsec:

                THE OLD ONE:                 RFC 2401 & friends.

                THE NEW ONE:                 RFC 4301 & friends.

Dan

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec


***********************  FSS-Unclassified   *********************= ** --=_alternative 0014E8716525717A_=-- --===============1569116662== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1569116662==-- From ipsec-bounces@ietf.org Fri May 26 09:54:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjckg-0006NA-Cu; Fri, 26 May 2006 09:53:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjckf-0006N5-Mp for ipsec@ietf.org; Fri, 26 May 2006 09:53:17 -0400 Received: from web38306.mail.mud.yahoo.com ([209.191.125.22]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fjcka-0002bD-Uk for ipsec@ietf.org; Fri, 26 May 2006 09:53:17 -0400 Received: (qmail 90063 invoked by uid 60001); 26 May 2006 13:53:12 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FzCIYDPlqE+OwkGtN6+A9A8LSS/2u6ChPjf6oPJzDp5pVRX/Y1gOIBD63ilDtfhvpfCH4z85RciW6/g1wyboyenTzzWllzkesOS6TxjCXIuirr+aTczSspMWnuysROl9W+FabgMJR9I9PeC1tBOui0GHMledey5u4EtRROOH61o= ; Message-ID: <20060526135312.90061.qmail@web38306.mail.mud.yahoo.com> Received: from [203.145.155.11] by web38306.mail.mud.yahoo.com via HTTP; Fri, 26 May 2006 06:53:12 PDT Date: Fri, 26 May 2006 06:53:12 -0700 (PDT) From: azhar zafar Subject: Fwd: [Ipsec] Tunneling IPSec To: Noel Keith MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-861289666-1148651592=:88463" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org --0-861289666-1148651592=:88463 Content-Type: multipart/alternative; boundary="0-1131164283-1148651592=:88463" --0-1131164283-1148651592=:88463 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, I have confusion that how MS gets IP address of Security Gateway before EAP-SIM authentication.What is the role of access point during authentication. If anybody knows please clear my doubts. Happy Weekned, Thanks, azhar --------------------------------- Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less. --0-1131164283-1148651592=:88463 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi all,
             I have confusion that how MS gets IP address of Security Gateway before EAP-SIM authentication.What is the role of access point during authentication.
If anybody knows please clear my doubts.
 
Happy Weekned,
Thanks,
 azhar

 

Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less. --0-1131164283-1148651592=:88463-- --0-861289666-1148651592=:88463 Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit X-Apparently-To: azharzafar1@yahoo.com via 209.191.125.29; Thu, 25 May 2006 16:52:39 -0700 X-Originating-IP: [156.154.16.145] Authentication-Results: mta314.mail.mud.yahoo.com from=yahoo.com.ar; domainkeys=fail (bad sig) Received: from 156.154.16.145 (EHLO megatron.ietf.org) (156.154.16.145) by mta314.mail.mud.yahoo.com with SMTP; Thu, 25 May 2006 16:52:35 -0700 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjPWm-0007AY-Eq; Thu, 25 May 2006 19:46:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjPWl-0007AT-PH for ipsec@ietf.org; Thu, 25 May 2006 19:46:03 -0400 Received: from web55512.mail.re4.yahoo.com ([206.190.58.221]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FjPWg-0005eW-Gd for ipsec@ietf.org; Thu, 25 May 2006 19:46:03 -0400 Received: (qmail 30376 invoked by uid 60001); 25 May 2006 20:39:16 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=CsnHK/0p4lRPPdPxIZBz9yL1eKCgOZqjFzAxddiMkOMwjYEFlm4LvNKT5XQGucRVHkyiRmZdXfof419P7yWJm0YtE561BrYX2jqyAwpnTnRw/aJZq6VX+BymG4eB1odheISBgOOlkMAPCE3H1Ou6DMfn5vk9wj08pFPXDuXhC1Q= ; Received: from [201.198.239.67] by web55512.mail.re4.yahoo.com via HTTP; Thu, 25 May 2006 20:39:16 GMT Date: Thu, 25 May 2006 20:39:16 +0000 (GMT) From: Noel Keith To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ipsec] Tunneling IPSec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Hello IPSec Forum: What´s RFC of Transport IPSec? N. ___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --0-861289666-1148651592=:88463 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --0-861289666-1148651592=:88463-- From ipsec-bounces@ietf.org Fri May 26 11:24:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeAW-0003f9-FX; Fri, 26 May 2006 11:24:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjeAQ-0003a5-IK for ipsec@ietf.org; Fri, 26 May 2006 11:23:58 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fje0m-0005fp-EA for ipsec@ietf.org; Fri, 26 May 2006 11:14:02 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4QFDueY015490 for ; Fri, 26 May 2006 18:13:59 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 18:13:14 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 18:13:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 May 2006 18:13:09 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Matching ID_IPV4_ADDR and ID_IPV6_ADDR Thread-Index: AcaA1uXoT4dVC599QXmz5pByQHUe5A== From: To: X-OriginalArrivalTime: 26 May 2006 15:13:15.0135 (UTC) FILETIME=[E94110F0:01C680D6] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Ipsec] Matching ID_IPV4_ADDR and ID_IPV6_ADDR X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Hi, During the IESG evaluation of draft-eronen-ipsec-ikev2-clarifications,=20 Sam Hartman raised a discuss about Section 7.1. Currently the text reads as follows: 7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header (of IKEv2 packets), or anything in the TSi/TSr payloads. The contents of IDi/IDr is used purely to fetch the policy and authentication data related to the other party. Sam's comments (from the I-D Tracker): Discuss [2006-05-25]: Based on the most recent mail from Steve Kent, the text in 7.1=20 is inaccurate in the following way. If you are matching against the PAD using ip addresses, then these ip addresses must be used to look up policy in the SPD. That requires them to influence the traffic selectors. So, the IP address you claim as an Id will indirectly appear in the traffic selectors. Comment [2006-05-24]: I'm not sure I agree with the text in 7.1 that claims the IP address ID payloads don't impact the traffic selectors. As far as a direct implication, it is true. However you do search the SPD based on the IP address payload and that does effect traffic selectors. For example I don't see how to configure the SPD to allow someone claiming an Id of 10.0.0.6 to match a policy that doesn't have 10.0.0.6 in one of the traffic selectors. The clarification text addresses two quite different issues, and to better separate them, we propose to rewrite Section 7.1 as follows: When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match anything in the TSi/TSr payloads. For example, in a site-to-site VPN between two security gateways, the gateways could authenticate each other as ID_IPV4_ADDR(192.0.1.1) and ID_IPV4_ADDR(192.0.2.1), and then create a CHILD_SA for protecting traffic between 192.0.1.55/32 (a host behind the first security gateway) and 192.0.2.240/28 (a network behind the second security gateway). The authenticated identities (IDi/IDr) are linked to the authorized traffic selectors (TSi/TSr) using "Child SA Authorization Data" in the Peer Authorization Database (PAD). Furthermore, IKEv2 does not require that the addresses in ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the IKE packets. However, other specifications may place additional requirements regarding this. For example, [PKI4IPsec] requires that implementation must be capable of comparing the addresses in the ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the IKE packets, and this comparison must be enabled by default. However, this rewrite does not significantly change the meaning from the original text, and thus Sam's comment still applies (to the first paragraph). Thus, we'd like to get other opinions from IPsec=20 experts on whether the text is correct or not. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 26 14:02:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjgct-0007qy-AQ; Fri, 26 May 2006 14:01:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjgcr-0007qc-W2 for ipsec@ietf.org; Fri, 26 May 2006 14:01:29 -0400 Received: from mxout2.netvision.net.il ([194.90.9.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjgco-0001GX-Fi for ipsec@ietf.org; Fri, 26 May 2006 14:01:29 -0400 Received: from [192.168.0.70] ([217.132.226.206]) by mxout2.netvision.net.il (Sun Java System Messaging Server 6.2-4.03 (built Sep 22 2005)) with ESMTP id <0IZV009FDWQ9LQ00@mxout2.netvision.net.il> for ipsec@ietf.org; Fri, 26 May 2006 21:01:21 +0300 (IDT) Date: Fri, 26 May 2006 21:01:20 +0300 From: Yoav Nir Subject: Re: [Ipsec] Matching ID_IPV4_ADDR and ID_IPV6_ADDR In-reply-to: To: Pasi.Eronen@nokia.com Message-id: <3EAEF7B9-726A-4974-BBD7-BAB6F8007369@netvision.net.il> MIME-version: 1.0 X-Mailer: Apple Mail (2.750) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org An IKE gateway will usually have at least two interfaces, an external interface (usually with a routable address), and an internal interface (which may have routable or non-routable addresses). The traffic selectors will only be for addresses behind the gateway. The gateway's external interface will not be in any selector. However, since the gateway's external interface has a routable (and therefore unique) address, it makes sense to use that address to identify the gateway. In that case the ID won't match anything in the SPD. It will, however, match the IP header of the IKE packets. You can easily find an example where it's the other way around. On May 26, 2006, at 6:13 PM, Pasi.Eronen@nokia.com wrote: > > I'm not sure I agree with the text in 7.1 that claims the IP > address ID payloads don't impact the traffic selectors. As far > as a direct implication, it is true. However you do search the > SPD based on the IP address payload and that does effect traffic > selectors. For example I don't see how to configure the SPD to > allow someone claiming an Id of 10.0.0.6 to match a policy that > doesn't have 10.0.0.6 in one of the traffic selectors. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 29 00:25:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkZGx-0004GR-TW; Mon, 29 May 2006 00:22:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkZGw-0004GM-70 for ipsec@ietf.org; Mon, 29 May 2006 00:22:30 -0400 Received: from delta.hssblr.co.in ([203.145.155.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkZGt-0001Em-Ty for ipsec@ietf.org; Mon, 29 May 2006 00:22:30 -0400 Received: from espion.blr.hss.hns.com (espion.blr.hss.hns.com [10.203.193.21]) by delta.hssblr.co.in (8.13.6/8.13.6) with ESMTP id l4R4LoZp002565; Sun, 27 May 2007 09:51:50 +0530 In-Reply-To: <20060526135312.90061.qmail@web38306.mail.mud.yahoo.com> To: azhar zafar Subject: Re: Fwd: [Ipsec] Tunneling IPSec MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Sri Pavani B S Date: Mon, 29 May 2006 09:51:02 +0530 X-MIMETrack: Serialize by Router on Espion/BLR/HSS(Release 6.5.5|November 30, 2005) at 05/29/2006 09:51:19 AM, Serialize complete at 05/29/2006 09:51:19 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0154806023==" Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0154806023== Content-Type: multipart/alternative; boundary="=_alternative 0017EB256525717D_=" This is a multipart message in MIME format. --=_alternative 0017EB256525717D_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable hi, Same doubt with me..Someone plz clarify... azhar zafar =20 05/26/2006 07:23 PM To Noel Keith cc ipsec@ietf.org Subject Fwd: [Ipsec] Tunneling IPSec Hi all, I have confusion that how MS gets IP address of Security=20 Gateway before EAP-SIM authentication.What is the role of access point=20 during authentication. If anybody knows please clear my doubts. =20 Happy Weekned, Thanks, azhar=20 =20 Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+=20 countries) for 2=A2/min or less. ----- Message from Noel Keith on Thu, 25 M= ay=20 2006 20:39:16 +0000 (GMT) ----- To: ipsec@ietf.org Subject: [Ipsec] Tunneling IPSec Hello IPSec Forum: What=B4s RFC of Transport IPSec? N. =20 =20 =20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=20 1GB gratis, Antivirus y Antispam=20 Correo Yahoo!, el mejor correo web del mundo=20 http://correo.yahoo.com.ar=20 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec *********************** FSS-Unclassified *********************** --=_alternative 0017EB256525717D_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
hi,

Same doubt with me..Someone plz clar= ify...



azhar zafar <azhar= zafar1@yahoo.com>

05/26/2006 07:23 PM

To
Noel Keith <noel=5Fk= eith=5Fnk@yahoo.com.ar>
cc
ipsec@ietf.org
Subject
Fwd: [Ipsec] Tunneling = IPSec






Hi all,
             I have confusion that how MS gets IP address of Security Gateway before EAP-SIM authentication.What is the role of access point during authentication.
If anybody knows please clear my doubts.
 
Happy Weekned,
Thanks,
 azhar

Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countrie= s) for 2=A2/min or less.
----- Message from Noel Keith <noel=5Fkeith=5Fnk@yahoo.com.ar> on Thu, 25 May 2006 20:39:16 +0000 (GMT) -----
To:
ipsec@ietf.org
Subject:
[Ipsec] Tunneling IPSec

Hello IPSec Forum:

What=B4s RFC of Transport IPSec?

N.


               
               
                                 
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
1GB gratis, Antivirus y Antispam
Correo Yahoo!, el mejor correo web del mundo
http://correo.yahoo.com.ar


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec


***********************  FSS-Unclassified   *********************= ** --=_alternative 0017EB256525717D_=-- --===============0154806023== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0154806023==-- From ipsec-bounces@ietf.org Mon May 29 04:23:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkd0o-0003rr-PY; Mon, 29 May 2006 04:22:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkd0n-0003nj-5Z for ipsec@ietf.org; Mon, 29 May 2006 04:22:05 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkd0d-0000aE-GW for ipsec@ietf.org; Mon, 29 May 2006 04:22:05 -0400 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D6352C47 for ; Mon, 29 May 2006 10:21:52 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 10:21:52 +0200 Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 10:21:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ipsec] Tunneling IPSec Date: Mon, 29 May 2006 10:21:50 +0200 Message-ID: <6EFBDA899F5A1947875F4F75A10C5BB802CD51A7@esealmw106.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] Tunneling IPSec Thread-Index: AcaAzHE9UMfItgqdTGqEK6FyKv10cgCKJ2lQ From: =?iso-8859-1?Q?Stefan_Holmstr=F6m_Q_=28AL/EAB=29?= To: X-OriginalArrivalTime: 29 May 2006 08:21:51.0130 (UTC) FILETIME=[EFAE0FA0:01C682F8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1795681386==" Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1795681386== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C682F8.EF8EF9E0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C682F8.EF8EF9E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 Provsioning UNC and Provisioning UNC-SGW FQDN or IP-address must = initially be configured just like any other new service. Since UMA is = focused on mobiles configuration will probably be provided via SMS. =20 After URR Discovery and successful registration the MS shall store the = "address" of Provisioning UNC and Default UNC along with associated SGWs =20 The AP being any generic wireless internet access point. NAT-T must be = supported. =20 Regards /Stefan ________________________________ From: azhar zafar [mailto:azharzafar1@yahoo.com]=20 Sent: den 26 maj 2006 15:53 To: Noel Keith Cc: ipsec@ietf.org Subject: Fwd: [Ipsec] Tunneling IPSec Hi all, I have confusion that how MS gets IP address of Security = Gateway before EAP-SIM authentication.What is the role of access point = during authentication. If anybody knows please clear my doubts. =20 Happy Weekned, Thanks, azhar=20 =20 ________________________________ Yahoo! Messenger with Voice. Make PC-to-Phone Calls = to the US (and 30+ countries) for = 2=A2/min or less. ------_=_NextPart_001_01C682F8.EF8EF9E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Provsioning UNC and Provisioning UNC-SGW FQDN = or=20 IP-address must initially be configured just like any other new service. = Since=20 UMA is focused on mobiles configuration will probably be provided=20 via SMS.
 
After=20 URR Discovery and successful registration the MS shall store the = "address" of=20 Provisioning UNC and Default UNC along with associated=20 SGWs
 
The AP=20 being any generic wireless internet access point. NAT-T must be=20 supported.
 
Regards /Stefan

From: azhar zafar = [mailto:azharzafar1@yahoo.com]=20
Sent: den 26 maj 2006 15:53
To: Noel = Keith
Cc:=20 ipsec@ietf.org
Subject: Fwd: [Ipsec] Tunneling=20 IPSec


Hi all,
           &n= bsp; I=20 have confusion that how MS gets IP address of Security Gateway before = EAP-SIM=20 authentication.What is the role of access point during = authentication.
If anybody knows please clear my doubts.
 
Happy Weekned,
Thanks,
 azhar

 

Yahoo! Messenger with Voice. Make=20 PC-to-Phone Calls to the US (and 30+ countries) for 2=A2/min or=20 less. ------_=_NextPart_001_01C682F8.EF8EF9E0-- --===============1795681386== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1795681386==-- From ipsec-bounces@ietf.org Mon May 29 09:30:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkhnZ-0005KE-4z; Mon, 29 May 2006 09:28:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkhnX-0005K9-Td for ipsec@ietf.org; Mon, 29 May 2006 09:28:43 -0400 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkhnW-0005ll-BY for ipsec@ietf.org; Mon, 29 May 2006 09:28:43 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k4TDSTq8011866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 May 2006 16:28:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k4TDST9u021386; Mon, 29 May 2006 16:28:29 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17530.63229.26833.776082@fireball.kivinen.iki.fi> Date: Mon, 29 May 2006 16:28:29 +0300 From: Tero Kivinen To: Subject: [Ipsec] Matching ID_IPV4_ADDR and ID_IPV6_ADDR In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > The clarification text addresses two quite different issues, and to > better separate them, we propose to rewrite Section 7.1 as follows: > > When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in > IDi/IDr payloads, IKEv2 does not require this address to match > anything in the TSi/TSr payloads. For example, in a site-to-site > VPN between two security gateways, the gateways could > authenticate each other as ID_IPV4_ADDR(192.0.1.1) and > ID_IPV4_ADDR(192.0.2.1), and then create a CHILD_SA for > protecting traffic between 192.0.1.55/32 (a host behind the first > security gateway) and 192.0.2.240/28 (a network behind the second > security gateway). The authenticated identities (IDi/IDr) are > linked to the authorized traffic selectors (TSi/TSr) using "Child > SA Authorization Data" in the Peer Authorization Database (PAD). > > Furthermore, IKEv2 does not require that the addresses in > ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of > the IKE packets. However, other specifications may place > additional requirements regarding this. For example, [PKI4IPsec] > requires that implementation must be capable of comparing the > addresses in the ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in > the IP header of the IKE packets, and this comparison must be > enabled by default. > > However, this rewrite does not significantly change the meaning from > the original text, and thus Sam's comment still applies (to the > first paragraph). Thus, we'd like to get other opinions from IPsec > experts on whether the text is correct or not. If I understood correctly Sam's comment was saying that as ID payloads are used to search for the correct policy from the PAD and SPD they do indirectly affect the traffic selectors. I think the The authenticated identities (IDi/IDr) are linked to the authorized traffic selectors (TSi/TSr) using "Child SA Authorization Data" in the Peer Authorization Database (PAD). text takes care of that concern. I have no problem with the new (or old) text. The new text is clearer and better, but both of them are ok. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec