From ipsec-bounces@ietf.org Sun Jul 02 10:18:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx2lG-0001Hx-Nh; Sun, 02 Jul 2006 10:17:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx2lF-0001Hr-Go for ipsec@ietf.org; Sun, 02 Jul 2006 10:17:21 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx2lD-0007ug-Vr for ipsec@ietf.org; Sun, 02 Jul 2006 10:17:21 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k62EH2NG022138; Sun, 2 Jul 2006 17:17:02 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DDB414F-C480-43D7-A724-5EA676192B67@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD Date: Sun, 2 Jul 2006 17:17:00 +0300 To: Stephen Kent X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com 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 Jun 28, 2006, at 7:11 PM, Stephen Kent wrote: > At 6:22 PM +0300 6/28/06, wrote: >> It's good to note that the INTERNAL_IP*_SUBNET attributes do not >> necessarily affect the SPD at all. They contain the gateway's policy >> about what traffic it would like to see sent via this tunnel... but >> unless the client trusts the gateway unconditionally, it should not >> change its SPD based on the information. >> >> But I guess you were considering the case where the client does >> trust the information to be correct. I'd say that in most cases >> it does not really change the SPD, but rather the routing table >> (and thus source address selection). Traffic that is sent via the >> tunnel uses the IP address assigned by the gateway as the source >> address; traffic that should bypass the tunnel most likely would >> use the IP address assigned by the local DHCP server. >> >> Best regards, >> Pasi > > Thanks for clarifying the "clarification." I was worried by the > suggestion that sending this attribute via IKE caused a change to > the SPD. > > Steve > I'm not sure you can avoid it. Since the client does not have the IP address assigned through the Configuration payload, we either have no triggering packet, or we use a source IP address of 0.0.0.0 like in DHCP. Suppose the SPD entry has ANY for the local address and ANY for the remote addresses (what else can it have) The relationships described in section 4.4.2.2 of RFC 4301 do not describe a way to get from "Any" to a list of ranges on either side, and the values on the triggering packet are no help either. The SA that was created has a single assigned IP address as the local, and a list of ranges as the remote. I don't see how we can make the client policy fit the model in RFC 4301 unless we allow a temporary change in the SPD. Yoav _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 03 05:31:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxKly-0007i8-O5; Mon, 03 Jul 2006 05:31:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxKlx-0007ha-Ut for ipsec@ietf.org; Mon, 03 Jul 2006 05:31:17 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxKil-0007fL-PY for ipsec@ietf.org; Mon, 03 Jul 2006 05:28:01 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k639RreI007125; Mon, 3 Jul 2006 12:27:54 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 12:27:53 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 12:27:53 +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 Subject: RE: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD Date: Mon, 3 Jul 2006 12:27:51 +0300 Message-ID: In-Reply-To: <7DDB414F-C480-43D7-A724-5EA676192B67@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD Thread-Index: Acad4kCaKVxXlkLZT6WSjD2KJVN2pwAnriUg From: To: X-OriginalArrivalTime: 03 Jul 2006 09:27:53.0325 (UTC) FILETIME=[F5CA49D0:01C69E82] X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Yoav Nir wrote: > > Thanks for clarifying the "clarification." I was worried by the =20 > > suggestion that sending this attribute via IKE caused a change=20 > > to the SPD. >=20 > I'm not sure you can avoid it. >=20 > Since the client does not have the IP address assigned through the =20 > Configuration payload, we either have no triggering packet,=20 > or we use a source IP address of 0.0.0.0 like in DHCP. >=20 > Suppose the SPD entry has ANY for the local address and ANY for the =20 > remote addresses (what else can it have) The relationships=20 > described in section 4.4.2.2 of RFC 4301 do not describe a way to=20 > get from "Any" to a list of ranges on either side, and the values on=20 > the triggering packet are no help either. The SA that was created has > a single assigned IP address as the local, and a list of ranges as the > remote. >=20 > I don't see how we can make the client policy fit the model in RFC =20 > 4301 unless we allow a temporary change in the SPD. When you're assigned a new IP address (either via INTERNAL_IP*_ADDRESS configuration payload, or some other means such as manual configuration), it might be necessary to create a new SPD entry that specifies how packets to/from that address are to be protected. Triggering based on outgoing packet is not possible before you get the INTERNAL_IP*_ADDRESS, because before that your TCP/IP stack can't send packets from that address -- so requesting the internal address has to be triggered by some other means. After the address is assigned, creation of additional CHILD_SAs can be triggered by outgoing packets as well. However, the original question (and Stephen's concern) was about INTERNAL_IP*_SUBNET, not INTERNAL_IP*_ADDRESS; the former do not necessarily cause any changes to the SPD.=20 Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 03 08:12:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxNHg-0002kL-0h; Mon, 03 Jul 2006 08:12:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxNHe-0002jn-4k for ipsec@ietf.org; Mon, 03 Jul 2006 08:12:10 -0400 Received: from athena.kddi.com ([210.141.112.39] helo=UTMC1103.kddi.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxNHc-0006SO-Oa for ipsec@ietf.org; Mon, 03 Jul 2006 08:12:10 -0400 Received: from usjk1037 (unknown [10.5.16.67]) by UTMC1103.kddi.com (Postfix) with SMTP id 976B22530; Mon, 3 Jul 2006 21:12:07 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with SMTP id 941B41AA7; Mon, 3 Jul 2006 21:12:01 +0900 (JST) Received: from UTMC1116.kddi.com (unknown [10.5.16.25]) by UTMC1122.kddi.com (Postfix) with ESMTP id 5CB9B1A7C; Mon, 3 Jul 2006 21:11:59 +0900 (JST) Received: from [10.100.120.154] ([10.100.120.154] [10.100.120.154]) by post-ims.kddi.com with ESMTP; Mon, 3 Jul 2006 21:11:59 +0900 Message-Id: <44A90990.5050702@kddi.com> Date: Mon, 03 Jul 2006 21:12:00 +0900 From: Kimihiro OHKI User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Stephen Kent Subject: Re: [Ipsec] IPv6 Configuration in IKEv2 References: <44A47F41.1030008@kddi.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WAuditID: 0607032112010000001199 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com 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 Stephen Kent wrote: > At 10:32 AM +0900 6/30/06, Kimihiro OHKI wrote: >>> ... >> >> Actually my confusion on this whole discussion might be, it was not >> clear for me how the negotiation of configuration payloads / traffic >> selectors affects its SPD or routing to the "interface". >> It seems, it is clearly defined that the negotiation of traffic >> selectors affects its SPD, on the other hand actual IPsec >> implementations may need to take care of any other details such as the >> difference between "SPD" and "interface" for the interoperability. >> >> Best Regards, >> Kimihiro Ohki > > the SPD is not modified by IKE negotiation of traffic selectors. The > SPD controls the traffic selector negotiation process. The SAD entry > and SPD cache entry created for an SA are affected by the IKE negotiation. Thanks for your comment. Well, 'the negotiation of traffic selectors affects its SPD "(cache) entries"' seems to be more correct statement. Best Regards, Kimihiro Ohki _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 03 10:10:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxP86-0007V5-Ol; Mon, 03 Jul 2006 10:10:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxP86-0007Uz-4r for ipsec@ietf.org; Mon, 03 Jul 2006 10:10:26 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxP83-0007vB-Iw for ipsec@ietf.org; Mon, 03 Jul 2006 10:10:26 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k63EAKNG010515; Mon, 3 Jul 2006 17:10:20 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5E40DD04-D2B2-44AF-9BD5-77FC3107B73A@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD Date: Mon, 3 Jul 2006 17:10:18 +0300 To: "" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Let's look at an example. The client connects with no triggering packet. It receives the IP address 192.0.2.1. The gateway protects two subnets: 192.0.3.0/24, 192.0.5.0/24 and policy dictates that separate SAs be used. CP(CFG_REPLY) INTERNAL_ADDRESS(192.0.2.1) INTERNAL_NETMASK(255.255.255.0) INTERNAL_SUBNET(192.0.3.0/255.255.255.0, 192.0.5.0/255.255.255.0) TSi = (0, 0-65535, 192.0.2.1-192.0.2.1) TSr = (0, 0-65535, 192.0.3.0-192.0.3.255) Upon receiving it, the client adds an SPD entry: local=192.0.2.1 remote=Any An SPD cache entry: local=192.0.2.1 remote=192.0.3.0-192.0.3.255 And some route entries (using a Windows syntax): route add 192.0.3.0 mask 255.255.255.0 192.0.2.1 route add 192.0.5.0 mask 255.255.255.0 192.0.2.1 It looks like it would work. I'm not sure that it's generally true that VPN tunnels are virtual interfaces that interact with the routing table, but for those clients that implement tunnels as interfaces, this would work. Thanks On Jul 3, 2006, at 12:27 PM, wrote: > Yoav Nir wrote: >>> Thanks for clarifying the "clarification." I was worried by the >>> suggestion that sending this attribute via IKE caused a change >>> to the SPD. >> >> I'm not sure you can avoid it. >> >> Since the client does not have the IP address assigned through the >> Configuration payload, we either have no triggering packet, >> or we use a source IP address of 0.0.0.0 like in DHCP. >> >> Suppose the SPD entry has ANY for the local address and ANY for the >> remote addresses (what else can it have) The relationships >> described in section 4.4.2.2 of RFC 4301 do not describe a way to >> get from "Any" to a list of ranges on either side, and the values on >> the triggering packet are no help either. The SA that was created >> has > >> a single assigned IP address as the local, and a list of ranges as >> the > >> remote. >> >> I don't see how we can make the client policy fit the model in RFC >> 4301 unless we allow a temporary change in the SPD. > > When you're assigned a new IP address (either via INTERNAL_IP*_ADDRESS > configuration payload, or some other means such as manual > configuration), it might be necessary to create a new SPD entry that > specifies how packets to/from that address are to be protected. > > Triggering based on outgoing packet is not possible before you get > the INTERNAL_IP*_ADDRESS, because before that your TCP/IP stack can't > send packets from that address -- so requesting the internal address > has to be triggered by some other means. After the address is > assigned, > creation of additional CHILD_SAs can be triggered by outgoing packets > as well. > > However, the original question (and Stephen's concern) was about > INTERNAL_IP*_SUBNET, not INTERNAL_IP*_ADDRESS; the former do not > necessarily cause any changes to the SPD. > > Best regards, > Pasi > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 03 10:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPLs-0004L6-AF; Mon, 03 Jul 2006 10:24:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPLr-0004L1-3O for ipsec@ietf.org; Mon, 03 Jul 2006 10:24:39 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxPLp-0000FC-La for ipsec@ietf.org; Mon, 03 Jul 2006 10:24:39 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k63EOVXw014762; Mon, 3 Jul 2006 17:24:32 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 17:24:32 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 17:24:31 +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 Subject: RE: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD Date: Mon, 3 Jul 2006 17:24:27 +0300 Message-ID: In-Reply-To: <5E40DD04-D2B2-44AF-9BD5-77FC3107B73A@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD Thread-Index: Acaeqnd4UhgAg2W6Txm/5vluk3WZDQAAH0Kw From: To: X-OriginalArrivalTime: 03 Jul 2006 14:24:31.0352 (UTC) FILETIME=[663DAF80:01C69EAC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Yoav Nir wrote: > It looks like it would work. I'm not sure that it's generally true =20 > that VPN tunnels are virtual interfaces that interact with the =20 > routing table, but for those clients that implement tunnels as =20 > interfaces, this would work. I think most clients that support assigning IP addresses with configuration payloads treat the VPN as some kind of virtual interface.=20 This is because the clients will want to use that address as source address for TCP/UDP/etc. traffic, and at least in the TCP/IP stacks I'm familiar with, that pretty much=20 requires assigning the address to some kind of interface. E.g. in Linux 2.6 kernel IPsec, you could assign the internal=20 IP address to the "dummy" interface ("ifconfig dummy0 10.0.0.1") and then create SPD entries that protect traffic from 10.0.0.1/32=20 to 0.0.0.0/0 using a tunnel mode SA to the gateway. (But this is not the same thing as treating IPsec tunnel mode SAs or IP-in-IP tunnels as interfaces, as suggested=20 in RFC 3884. E.g. in the Linux 2.6 example above, dummy0=20 is not a tunnel, and is not specific to IPsec.) Best regards, Pasi=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 10 18:19:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G044z-0000Bc-Pe; Mon, 10 Jul 2006 18:18:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G044y-0000BX-K6 for ipsec@ietf.org; Mon, 10 Jul 2006 18:18:12 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G044x-00053g-8Y for ipsec@ietf.org; Mon, 10 Jul 2006 18:18:12 -0400 Received: from [172.16.52.3] (h0fdc-net84db.lab.risq.net [132.219.15.220] (may be forged)) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6AMI9T3058318 for ; Mon, 10 Jul 2006 15:18:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 10 Jul 2006 18:18:27 -0400 To: IPsec WG From: The IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Ipsec] Document Action: 'IKEv2 Clarifications and Implementation Guidelines' to Informational RFC 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 The IESG has approved the following document: - 'IKEv2 Clarifications and Implementation Guidelines ' as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Russ Housley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-09.txt Technical Summary This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable IKEv2 implementations. Working Group Summary This document is an individual submission. This document was discussed on the IPsec Mail List. Protocol Quality Thin document incorporates many lessons learned during interoperability testing. This document was reviewed by Russ Housley for the IESG. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 11 16:20:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Oi7-0005IJ-VC; Tue, 11 Jul 2006 16:19:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Oi6-0005IE-Rp for ipsec@ietf.org; Tue, 11 Jul 2006 16:19:58 -0400 Received: from [202.54.124.178] (helo=rediffmail.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0Oi5-0007o8-3Q for ipsec@ietf.org; Tue, 11 Jul 2006 16:19:58 -0400 Received: (qmail 10632 invoked by uid 510); 11 Jul 2006 20:17:52 -0000 Date: 11 Jul 2006 20:17:52 -0000 Message-ID: <20060711201752.10631.qmail@webmail9.rediffmail.com> Received: from unknown (69.26.216.147) by rediffmail.com via HTTP; 11 jul 2006 20:17:52 -0000 MIME-Version: 1.0 From: "sudeep " To: ipsec@ietf.org X-Spam-Score: 1.6 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ipsec] IKEv2 PRF Keylengths confusion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sudeep List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1269614521==" Errors-To: ipsec-bounces@ietf.org This is a multipart mime message --===============1269614521== Content-type: multipart/alternative; boundary="Next_1152649072---0-202.54.124.178-10628" This is a multipart mime message --Next_1152649072---0-202.54.124.178-10628 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, =A0=0A=0AIncase of IKEv2 exchange, what is the maximum nonce size a= llowed? =0AIncase of variable-key prf functions (like HMAC-SHA1) the key is= =0Aconstructed by concatenating initiator nonce and responder nonce. But = =0Aaccording to rfc-2104, HMAC can take keys of lengths only upto 64 =0AByt= es. So what if both initiator and responder nonce add upto more =0Athan 64 = Bytes? How do we truncate them to get correct key for HMAC. =0ADoes IKEv2 s= pec (rfc 4306) specify anything?=0A=0APlease someone clarify me on this...= =0A=0AThanks=0ASudeep --Next_1152649072---0-202.54.124.178-10628 Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

=0AHi all, 
=0A
=0AIncase of IKEv2 exchange, what is the max= imum nonce size allowed?
=0AIncase of variable-key prf functions (like = HMAC-SHA1) the key is
=0Aconstructed by concatenating initiator nonce a= nd responder nonce. But
=0Aaccording to rfc-2104, HMAC can take keys of= lengths only upto 64
=0ABytes. So what if both initiator and responder= nonce add upto more
=0Athan 64 Bytes? How do we truncate them to get c= orrect key for HMAC.
=0ADoes IKEv2 spec (rfc 4306) specify anything?=0A
=0APlease someone clarify me on this...
=0A
=0AThanks
=0AS= udeep=0A

=0A

=0A=0A --Next_1152649072---0-202.54.124.178-10628-- --===============1269614521== 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 --===============1269614521==-- From ipsec-bounces@ietf.org Tue Jul 11 17:38:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Pvn-0003Ee-G8; Tue, 11 Jul 2006 17:38:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Pvn-0003EV-20 for ipsec@ietf.org; Tue, 11 Jul 2006 17:38:11 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Pvk-0006Ca-Ga for ipsec@ietf.org; Tue, 11 Jul 2006 17:38:11 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2006 13:43:29 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,230,1149490800"; d="scan'208,217"; a="31868495:sNHT42504908" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6BKhTZS010989; Tue, 11 Jul 2006 16:43:29 -0400 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k6BKhTP1014830; Tue, 11 Jul 2006 13:43:29 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 13:43:22 -0700 Received: from sfluhrerhpc ([10.32.244.82]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 13:43:21 -0700 From: "Scott Fluhrer" To: "'sudeep'" , Subject: RE: [Ipsec] IKEv2 PRF Keylengths confusion Date: Tue, 11 Jul 2006 16:43:22 -0400 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <20060711201752.10631.qmail@webmail9.rediffmail.com> Thread-Index: AcalJ20j1JROeUoESjychtyA/qo8NgAAhd7w Message-ID: X-OriginalArrivalTime: 11 Jul 2006 20:43:21.0784 (UTC) FILETIME=[A5F05B80:01C6A52A] DKIM-Signature: a=rsa-sha1; q=dns; l=4265; t=1152650609; x=1153514609; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sfluhrer@cisco.com; z=From:=22Scott=20Fluhrer=22=20 |Subject:RE=3A=20[Ipsec]=20IKEv2=20PRF=20Keylengths=20confusion |To:=22'sudeep'=22=20,=20; X=v=3Dcisco.com=3B=20h=3DlN/EieH5iEeI3q9gIN8RHPhYT2k=3D; b=uEWrMUgOo+I7Z9u1JVXCnFam1RO1Psdyp2kNwDpqQKCh6IM7QSTLPf5hF2JVTQTwa/7DKZRT 9lQULWx2BdDEpqmqsABlGIgpQkW2ZvmWnNVaJNav4a/bVKCUgfYCcHTa; Authentication-Results: rtp-dkim-2.cisco.com; header.From=sfluhrer@cisco.com; dkim=pass ( 63 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: 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="===============0325179356==" Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0325179356== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C9_01C6A509.1FB93D00" This is a multi-part message in MIME format. ------=_NextPart_000_00C9_01C6A509.1FB93D00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit _____ From: sudeep [mailto:sudeep_patwardhan@rediffmail.com] Sent: Tuesday, July 11, 2006 4:18 PM To: ipsec@ietf.org Subject: [Ipsec] IKEv2 PRF Keylengths confusion Hi all, Incase of IKEv2 exchange, what is the maximum nonce size allowed? Incase of variable-key prf functions (like HMAC-SHA1) the key is constructed by concatenating initiator nonce and responder nonce. But according to rfc-2104, HMAC can take keys of lengths only upto 64 Bytes. This is incorrect: according to the RFC section 2: Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC. And in section 3: The key for HMAC can be of any length (keys longer than B bytes are first hashed using H). For example, if you are implementing HMAC-SHA1 and if you get a key longer than 64 bytes, you would run SHA1 on the key, and use the resulting 20 bytes as K, which is xor'ed into the ipad/opad So what if both initiator and responder nonce add upto more than 64 Bytes? How do we truncate them to get correct key for HMAC. Does IKEv2 spec (rfc 4306) specify anything? Please someone clarify me on this... ------=_NextPart_000_00C9_01C6A509.1FB93D00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: sudeep=20 [mailto:sudeep_patwardhan@rediffmail.com]
Sent: Tuesday, = July 11,=20 2006 4:18 PM
To: ipsec@ietf.org
Subject: [Ipsec] = IKEv2 PRF=20 Keylengths confusion

Hi all, 

Incase of IKEv2 exchange, what is the maximum = nonce=20 size allowed?
Incase of variable-key prf functions (like = HMAC-SHA1) the=20 key is
constructed by concatenating initiator nonce and responder = nonce.=20 But
according to rfc-2104, HMAC can take keys of lengths only upto = 64=20
Bytes. 

This is incorrect: according to the = RFC=20 section 2:

Applications that use keys longer = than B bytes=20 will first hash the key using H and then use the resultant L byte string = as the=20 actual key to HMAC.

And in section 3:

The key for HMAC can be of any = length (keys=20 longer than B bytes are first hashed using=20 H).

 

For example, if you are implementing = HMAC-SHA1=20 and  if you get a key longer than 64 bytes, you would run SHA1 on = the key,=20 and use the resulting 20 bytes as K, which is xor'ed into the=20 ipad/opad

  So what if both = initiator and=20 responder nonce add upto more
than 64 Bytes? How do we truncate = them to=20 get correct key for HMAC.
Does IKEv2 spec (rfc 4306) specify=20 anything?

Please someone clarify me on=20 this...

------=_NextPart_000_00C9_01C6A509.1FB93D00-- --===============0325179356== 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 --===============0325179356==-- From ipsec-bounces@ietf.org Tue Jul 11 17:39:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Pwz-0003mb-PB; Tue, 11 Jul 2006 17:39:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Pwy-0003mV-4G for ipsec@ietf.org; Tue, 11 Jul 2006 17:39:24 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Pww-0006Y1-Kz for ipsec@ietf.org; Tue, 11 Jul 2006 17:39:24 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6BLdKjK009071; Wed, 12 Jul 2006 00:39:21 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 00:39:19 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 00:39:19 +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 Subject: RE: [Ipsec] IKEv2 PRF Keylengths confusion Date: Wed, 12 Jul 2006 00:39:18 +0300 Message-ID: In-Reply-To: <20060711201752.10631.qmail@webmail9.rediffmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] IKEv2 PRF Keylengths confusion Thread-Index: AcalJ5AXTYmcP8DYQXGSCAYXSFuBTwACk/xQ From: To: , X-OriginalArrivalTime: 11 Jul 2006 21:39:19.0188 (UTC) FILETIME=[771B8D40:01C6A532] X-Spam-Score: 0.2 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 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, See RFC 2104 Section 3: "The key for HMAC can be of any length (keys longer than B bytes are first hashed using H)." Best regards Pasi > -----Original Message----- > From: ext sudeep [mailto:sudeep_patwardhan@rediffmail.com]=20 > Sent: 11 July, 2006 23:18 > To: ipsec@ietf.org > Subject: [Ipsec] IKEv2 PRF Keylengths confusion > > Hi all, =20 >=20 > Incase of IKEv2 exchange, what is the maximum nonce size allowed? > Incase of variable-key prf functions (like HMAC-SHA1) the key is > constructed by concatenating initiator nonce and responder > nonce. But according to rfc-2104, HMAC can take keys of lengths only > upto 64 Bytes. So what if both initiator and responder nonce add > upto more than 64 Bytes? How do we truncate them to get correct key > for HMAC. Does IKEv2 spec (rfc 4306) specify anything? > > Please someone clarify me on this... > > Thanks > Sudeep=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From 6kbg5Dk8Xn@mail.ru Wed Jul 12 09:53:12 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0f9M-0002IZ-87; Wed, 12 Jul 2006 09:53:12 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0f9M-0005ro-6N; Wed, 12 Jul 2006 09:53:12 -0400 Received: from bb121-6-126-251.singnet.com.sg ([121.6.126.251]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0f9J-0004xp-MR; Wed, 12 Jul 2006 09:53:12 -0400 Date: Wed, 12 Jul 2006 13:53:11 -0480 From: "Deirdre Ziegler" X-Mailer: The Bat! (v3.01 RC8) Educational Reply-To: "Deirdre Ziegler" X-Priority: 3 (Normal) Message-ID: <08071250.20060712135311@mail.ru> To: ipo-archive@lists.ietf.org Subject: RYX MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 "Well, if you can't, you can't. I understand you, Red, and I can't pass miles an hour in the entry! You have to be smooth! Firm but smooth, He wants to go up. And what if something gets you at twenty yards? "We're free to go where we wish and to be what we are," Jonathan From ipsec-bounces@ietf.org Wed Jul 12 12:43:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hoD-0004DN-9d; Wed, 12 Jul 2006 12:43:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hoC-0004DD-EJ for ipsec@ietf.org; Wed, 12 Jul 2006 12:43:32 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0hoB-0005aH-SJ for ipsec@ietf.org; Wed, 12 Jul 2006 12:43:32 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6CGhTPc016675 for ; Wed, 12 Jul 2006 19:43:31 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 19:43:19 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 19:43:20 +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: Wed, 12 Jul 2006 19:43:18 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Review: Recharter of Robust HeaderCompression (rohc) Thread-Index: Acak9gWn/UmTKIp5R9upgjC/tGnwhgA26ddw From: To: X-OriginalArrivalTime: 12 Jul 2006 16:43:20.0762 (UTC) FILETIME=[48AC89A0:01C6A5D2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Subject: [Ipsec] FW: WG Review: Recharter of Robust HeaderCompression (rohc) 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 FYI: ROHC's new proposed charter includes a work item=20 related to IPsec: > - to develop and/or document proper protocol solutions to apply ROHC=20 > over IPsec tunnels.=20 Best regards, Pasi -----Original Message----- From: IESG Secretary To: ietf-announce@ietf.org Subject: WG Review: Recharter of Robust Header Compression (rohc) Date: Tue, 11 Jul 2006 10:27:41 -0400 A modified charter has been submitted for the Robust Header Compression=20 (rohc) working group in the Transport Area of the IETF. The IESG has not made=20 any determination as yet. The modified charter is provided below for=20 informational purposes only. Please send your comments to the IESG mailing=20 list (iesg at ietf.org) by August 2nd. +++ Robust Header Compression (rohc) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Current Status: Active Working Group Chair(s): Lars-Erik Jonsson =20 Transport Area Director(s): Magnus Westerlund =20 Lars Eggert =20 Transport Area Advisor: Magnus Westerlund =20 Technical Advisor(s): Erik Nordmark =20 Carsten Bormann =20 Mailing Lists: General Discussion: rohc at ietf.org To Subscribe: rohc-request at ietf.org Archive: http://www.ietf.org/mail-archive/web/rohc/index.html Description of Working Group:=20 The Robust Header Compression (ROHC) Working Group was formed to develop new header compression protocols, designed to suit today's and future=20 target link technologies. Most specifically, the ROHC protocols were to=20 take into account typical needs presented by various wireless link=20 technologies, and perform well for cellular links built using=20 technologies such as WCDMA, EDGE, and CDMA-2000. Protocol development=20 has thus focused on coping with issues such as high loss rates and long=20 round trip times.=20 The WG has specified a common compression protocol platform, the ROHC=20 framework, along with a number of compression protocols (profiles). Most focus has been on compression of the Real-time Transport Protocol (RTP)=20 headers, but profiles have also been specified for compression of UDP,=20 ESP, IP-only, UDP-Lite, and TCP headers. The WG has further produced a=20 ROHC link integration specification for PPP, an optimized RTP=20 compression scheme for "0-byte compression", a ROHC MIB, as well as=20 various informational documents related to ROHC header compression=20 and/or header compression in general.=20 In addition to the work on header compression, the ROHC WG has also=20 developed the SigComp (Signaling Compression) protocol for end-to-end=20 compression of text-based signaling protocol messages.=20 The working group maintains connections with other standardization=20 organizations developing cellular technology for IP, such as 3GPP and=20 3GPP-2, to ensure that its output fulfills their requirements and will=20 be put to good use.=20 The current aims of the working group are:=20 - to carry out a re-work of the ROHC framework and profiles=20 specifications, hereafter referred to as the ROHCv2 project. The purpose of the ROHCv2 project is to generate a separate framework specification=20 as well as a set of revised compression profiles. One specific goal with the ROHCv2 profiles is to improve tolerance to packet reordering between compressor and decompressor.=20 - to update and correct the original profile specifications through=20 publication of the "Corrections and Clarifications to RFC 3095"-=20 document.=20 - to finalize the ROHC profile work for TCP header compression.=20 - to develop and/or document proper protocol solutions to apply ROHC=20 over IPsec tunnels.=20 - to finalize the "SigComp implementer's guide" and "SigComp for SIP"=20 documents.=20 The longer term goal of the working group is to advance all its=20 specifications to Draft Standard status (with an exception for the=20 original profiles being revised as part of the ROHCv2 activity).=20 Goals and Milestones:=20 Done Problem analysis ROHC-over-channels-that-can-reorder-packets=20 submitted to IESG for publication as Informational.=20 Done I-Ds of ROHC IP/UDP/RTP bis, framework and profiles separated.=20 Aug 2006 RFC 3095 Implementer's Guide submitted to IESG for publication=20 as Proposed Standard.=20 Sep 2006 IP/TCP compression scheme submitted to IESG for publication as=20 Proposed Standard.=20 Nov 2006 ROHC framework submitted to IESG for publication as Proposed=20 Standard.=20 Nov 2006 SigComp for SIP submitted to IESG for publication as Proposed=20 Standard.=20 Dec 2006 Revised ROHC IPUDP//RTP profiles submitted to IESG for=20 publication as Proposed Standard.=20 Dec 2006 SigComp Implementer's Guide submitted to IESG for publication=20 as Informational.=20 Jan 2007 RObust Header Compression Protocol Number Registration submitted=20 to IESG for publication as Proposed Standard.=20 Feb 2007 ROHC encapsulation profile(s) for IPHC/CRTP/eCRTP submitted to=20 IESG for publication as Proposed Standard.=20 Mar 2007 IKE/IPsec extensions for HC-session Parameter Negotiation=20 submitted to IESG for publication as Proposed Standard.=20 Mar 2007 Header Compression over IPsec (HCoIPsec) submitted to IESG for=20 publication as Informational.=20 Jun 2007 Recharter of WG to develop additional profiles if needed, or=20 possible additional compression schemes. Consideration of=20 concluding the working group. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From abbcd@0451.com Thu Jul 27 12:40:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G68u2-0007vn-5N; Thu, 27 Jul 2006 12:40:02 -0400 Received: from static-213-182-106-63.teleos-web.de ([213.182.106.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G68tx-0006r5-Jf; Thu, 27 Jul 2006 12:40:02 -0400 Date: Thu, 27 Jul 2006 16:40:25 -0060 From: "Elisa Fox" X-Mailer: The Bat! (v2.00) Personal Reply-To: "Elisa Fox" X-Priority: 3 (Normal) Message-ID: <403527804.20060727164025@0451.com> To: iporpr-archive@lists.ietf.org Subject: Your cash, passing strake MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Even if you have no erectin problems SOFT CIAYLIS would help you to make BETTER SEWX MORE OFTEN! and to bring unimagnable plesure to her. Just disolve half a pil under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medic ation were able to have PERFECT ERJECTION during 36 hours! VISIT US, AND GET OUR SPECIAL 70% DISC1OUNT OFER! http://wfwrcl.bigbacks.info/?99865114 ========== Outcast. "Family?" "... for his reckless irresponsibility " the solemn voice intoned, "There is a steady leak of materials from the Visitation Zones into the was very nearly Fletcher's top speed. twenty feet away and it's completely rusted out, but they look like they've inventiveness marvelous to behold. "At ease, sergeant," said. "I'm pleased."