From ipsec-bounces@ietf.org Wed Apr 2 03:48:33 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72FEC3A6E03; Wed, 2 Apr 2008 03:48:33 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44B13A6F00 for ; Wed, 2 Apr 2008 03:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.704 X-Spam-Level: X-Spam-Status: No, score=-1.704 tagged_above=-999 required=5 tests=[AWL=0.895, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3vWIGfvZgiB for ; Wed, 2 Apr 2008 03:48:30 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dyn32-54.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6CD423A6E03 for ; Wed, 2 Apr 2008 03:48:30 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E0E78294003; Wed, 2 Apr 2008 13:48:29 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 33DF9294001 for ; Wed, 2 Apr 2008 13:48:29 +0300 (IDT) Received: from MBP.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m32AmSfU016567 for ; Wed, 2 Apr 2008 13:48:28 +0300 (IDT) Message-Id: From: Yoav Nir To: ipsec@ietf.org Content-Type: multipart/mixed; boundary=Apple-Mail-7--954642321 Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 13:48:27 +0300 References: <20080402074502.2101928C3E9@core3.amsl.com> X-Mailer: Apple Mail (2.919.2) Subject: [IPsec] Fwd: I-D Action:draft-nir-ike-qcd-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --Apple-Mail-7--954642321 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi all This is the second draft (with a title change) of my draft for quick discovery of a rebooted peer. In this version I've changed the following: - Changed "Quick Crash Recovery" to "Quick Crash Detection" - Added interaction with IFARE - Added discussion of backup gateways, whether IFARE type or high- availability cluster configurations. Your comments are most welcome Yoav Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: April 2, 2008 10:45:02 AM GMT+03:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-nir-ike-qcd-00.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : A Quick Crash Detection Method for IKE > Author(s) : Y. Nir > Filename : draft-nir-ike-qcd-00.txt > Pages : 15 > Date : 2008-04-02 > > This document describes an extension to the IKEv2 protocol that > allows for faster crash recovery using a saved token. > > When an IPsec tunnel between two IKEv2 implementations is > disconnected due to a restart of one peer, it can take as much as > several minutes for the other peer to discover that the reboot has > occurred, thus delaying recovery. In this text we propose an > extension to the protocol, that allows for recovery within a few > seconds of the reboot. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nir-ike-qcd-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. --Apple-Mail-7--954642321 Content-Disposition: attachment; filename=mime-attachment Content-Type: message/external-body; x-unix-mode=0666; name="mime-attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2008-04-02003042.I-D@ietf.org>

--Apple-Mail-7--954642321 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-7--954642321 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://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-7--954642321-- From hekmagnaridersvez@magnariders.com Wed Apr 2 06:02:01 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2232E3A6A1B; Wed, 2 Apr 2008 06:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.995 X-Spam-Level: **** X-Spam-Status: No, score=4.995 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hUKnGn6hzTT; Wed, 2 Apr 2008 06:02:00 -0700 (PDT) Received: from dxb-b138587.alshamil.net.ae (dxb-b138587.alshamil.net.ae [86.98.88.233]) by core3.amsl.com (Postfix) with ESMTP id D256B28C4EB; Wed, 2 Apr 2008 05:59:52 -0700 (PDT) Received: from [86.98.88.233] by mail.domainnameservers.net; Wed, 2 Apr 2008 04:59:54 -0800 Date: Wed, 2 Apr 2008 04:59:54 -0800 From: "Selma Denton" X-Mailer: The Bat! (v2.11) Educational Reply-To: hekmagnaridersvez@magnariders.com X-Priority: 3 (Normal) Message-ID: <513892957.08868425477326@magnariders.com> To: agentx-archive@lists.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------33AE90901D33A7C4" ------------33AE90901D33A7C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Our purpose is to render low price PC and Macintosh lawful soft and computer solutions for anyone's budget. Whether you are a corporate client, an owner of small enterprise, or go shopping for your home PC, we suppose we'll assist you. SEE WHAT WE GOT TO OFFER! http://shelbysodenkq945.blogspot.com ------------33AE90901D33A7C4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Our purpose is to render low price PC and Macintosh lawful soft and computer solutions for anyone's budget.
Whether you are a corporate client, an owner of small enterprise,
or go shopping for your home PC, we suppose we'll assist you.
SEE WHAT WE GOT TO OFFER!
http://shelbysodenkq945.blogspot.com
------------33AE90901D33A7C4-- From ipsec-bounces@ietf.org Wed Apr 2 12:14:46 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21E028C62D; Wed, 2 Apr 2008 12:14:46 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26F8928C636 for ; Wed, 2 Apr 2008 12:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_GOOD=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+D+bBgCJOE9 for ; Wed, 2 Apr 2008 12:14:37 -0700 (PDT) Received: from blnkms23.securesites.net (blnkms23.securesites.net [161.58.211.245]) by core3.amsl.com (Postfix) with ESMTP id ED96328C6F2 for ; Wed, 2 Apr 2008 12:08:34 -0700 (PDT) Received: from [172.16.1.35] (adsl-67-119-110-158.dsl.snfc21.pacbell.net [67.119.110.158]) (authenticated bits=0) by blnkms23.securesites.net (8.13.6.20060614/8.13.6) with ESMTP id m32J9lFN007069; Wed, 2 Apr 2008 19:09:52 GMT Message-ID: <47F3D9B1.7060500@blunkmicro.com> Date: Wed, 02 Apr 2008 12:08:33 -0700 From: Sean Lawless Organization: Blunk Microsystems User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] AH ICV calculation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all, We are in the process of implementing static keyed IPSec for the IPv6 portion of a commercial TCP/IP stack and are having problems computing the AH ICV correctly. Using NULL as the authentication type there are no problems communicating with other hosts (Windows XP) so I have ruled out problems with packet decoding, SPI assignment, etc. However, using any HMAC algorithm (MD5-96 or SHA1-96) the calculated ICV never matches. I should also note that the HMAC algorithm we are using works correctly with our TLS 1.0 implementation and so I feel we can rule out HMAC and MD5/SHA1 algorithms as the problem. The ICV calculation matches if I test one Windows XP machine against another or one of our development boards running our stack against another. This means our ICV calculation is consistent (but incorrect) upon inbound and outbound processing. I have read through the NetBSD code (ah_core.c) and cannot find any difference in how they are muting the IPv6 header fields vs. how we are... I have walked us through an example below that uses MD5 as the AH algorithm with our implementation receiving an ICMPv6 ping from a Windows XP host with outbound SPI 3001 (0x00000BB9), configured with HMAC-MD5-96 and key file "0123456789ABCDEF": Complete ICMPv6 packet captured with Ethereal: 0000 00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00 ...T....`..>..`. 0010 00 00 00 40 33 80 fe 80 00 00 00 00 00 00 02 1d ...@3........... 0020 60 ff fe 0d 97 3e fe 80 00 00 00 00 00 00 02 00 `....>.......... 0030 00 ff fe 54 85 00 3a 04 00 00 00 00 0b b9 00 00 ...T..:......... 0040 00 07 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a 80 00 ..1..?.m.X...... 0050 59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6a Y3....abcdefghij 0060 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 klmnopqrstuvwabc 0070 64 65 66 67 68 69 defghi Packet after mutable field hop limit and ICV are zero'd: 0000 00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00 0010 00 00 00 40 33 00 FE 80 00 00 00 00 00 00 02 1D 0020 60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00 02 00 0030 00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9 00 00 0040 00 07 00 00 00 00 00 00 00 00 00 00 00 00 80 00 0050 59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6A 0060 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63 0070 64 65 66 67 68 69 The manual key being used is "0123456789ABCDEF" which has a key length of 16. After the HMAC init function is called with the key and key length, the packet is processed with HMAC-MD5. There are 104 bytes processed from packet offset 000E to 0075: 60 00 00 00 00 40 33 00 FE 80 00 00 00 00 00 00 02 1D 60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00 02 00 00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9 00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 80 00 59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 After the HMAC calculation is finished, the first 96 bits of the hash of the above data is: 70 14 6d d1 15 4c 85 2c 26 a7 31 68 Which does not match the ICV in the packet: 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a I have double checked and the HMAC-MD5-96 hash we calculated is correct for the key and data being processed, therefore I can only assume that the data we are processing is incorrect (or the manual key requires preprocessing?). I've reread the RFCs many times and am at a loss for what could be the problem. Can anyone spot what I am doing wrong? Also it would be very helpful to me if anyone could point to an example of AH processing on an actual packet. Something similar to the steps outlined above? Best Regards, Sean Lawless Blunk Microsystems LLC _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 3 06:41:09 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A549E28C15E; Thu, 3 Apr 2008 06:41:09 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A41928C15E for ; Thu, 3 Apr 2008 06:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_GOOD=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGvAHliqiYAk for ; Thu, 3 Apr 2008 06:41:03 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 94D853A6B42 for ; Thu, 3 Apr 2008 06:41:02 -0700 (PDT) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m33Df4lD025286 for ; Thu, 3 Apr 2008 09:41:04 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m33DeqIc995430 for ; Thu, 3 Apr 2008 09:40:53 -0400 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m33DegMO009135 for ; Thu, 3 Apr 2008 07:40:43 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m33DegRU009105; Thu, 3 Apr 2008 07:40:42 -0600 In-Reply-To: <47F3D9B1.7060500@blunkmicro.com> References: <47F3D9B1.7060500@blunkmicro.com> To: Sean Lawless MIME-Version: 1.0 X-KeepSent: A963036D:485439F9-85257420:004943C6; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0 August 02, 2007 From: Scott C Moonen Message-ID: Date: Thu, 3 Apr 2008 09:40:41 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.0|August 02, 2007) at 04/03/2008 07:40:42, Serialize complete at 04/03/2008 07:40:42 Cc: ipsec@ietf.org Subject: Re: [IPsec] AH ICV calculation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1024782511==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1024782511== Content-Type: multipart/alternative; boundary="=_alternative 004AE37B85257420_=" This is a multipart message in MIME format. --=_alternative 004AE37B85257420_= Content-Type: text/plain; charset="US-ASCII" Hi Sean. Please take the following with a grain of salt, because it is relayed secondhand, from a year or two ago, and the original tester is actually no longer with our company. Our system test group was able to successfully implement dynamic SAs between our platform and Microsoft Windows. One of our testers had some problems, however, configuring manual SAs between our platform and Windows. We got the impression at the time that Windows doesn't directly use the key data that you enter in its configuration, but that it somehow hashes it to produce the actual key for the SA. My recollection (could be wrong) is that he was able to enter key values longer than 16 bytes on Windows for various algorithms (both HMAC-x and encryption algorithms), and this may have been what led us to conclude that the key was derived from what he entered rather than being exactly what he entered. We couldn't find any documentation on how the keys are derived, and I don't know whether he pursued an answer from Microsoft support. I suspect that he never got manual keys working. It wasn't a high priority test in his case since we were able to successfully interact with numerous other platforms using manual SAs. At very least, we don't currently have any manual SAs in our testbed between our platform and Windows (though we do have dynamic SAs). So you might consider trying your test with another platform than Windows; perhaps Linux or Cisco. Alternatively, you might consider contacting Microsoft (or perhaps a Microsoft representative will comment in response to this) to understand how their implementation derives keys for manual SAs. Lastly, you might consider dynamic SAs, though I realize that this may not be a trivial exercise. :) For what it's worth, with a quick seat-of-the-pants calculation I did arrive at the same ICV value for your sample data that you obtained. That doesn't mean that you and I aren't making the same oversight. :) Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Sean Lawless To: ipsec@ietf.org Date: 04/02/2008 03:16 PM Subject: [IPsec] AH ICV calculation Hi all, We are in the process of implementing static keyed IPSec for the IPv6 portion of a commercial TCP/IP stack and are having problems computing the AH ICV correctly. Using NULL as the authentication type there are no problems communicating with other hosts (Windows XP) so I have ruled out problems with packet decoding, SPI assignment, etc. However, using any HMAC algorithm (MD5-96 or SHA1-96) the calculated ICV never matches. I should also note that the HMAC algorithm we are using works correctly with our TLS 1.0 implementation and so I feel we can rule out HMAC and MD5/SHA1 algorithms as the problem. The ICV calculation matches if I test one Windows XP machine against another or one of our development boards running our stack against another. This means our ICV calculation is consistent (but incorrect) upon inbound and outbound processing. I have read through the NetBSD code (ah_core.c) and cannot find any difference in how they are muting the IPv6 header fields vs. how we are... I have walked us through an example below that uses MD5 as the AH algorithm with our implementation receiving an ICMPv6 ping from a Windows XP host with outbound SPI 3001 (0x00000BB9), configured with HMAC-MD5-96 and key file "0123456789ABCDEF": Complete ICMPv6 packet captured with Ethereal: 0000 00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00 ...T....`..>..`. 0010 00 00 00 40 33 80 fe 80 00 00 00 00 00 00 02 1d ...@3........... 0020 60 ff fe 0d 97 3e fe 80 00 00 00 00 00 00 02 00 `....>.......... 0030 00 ff fe 54 85 00 3a 04 00 00 00 00 0b b9 00 00 ...T..:......... 0040 00 07 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a 80 00 ..1..?.m.X...... 0050 59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6a Y3....abcdefghij 0060 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 klmnopqrstuvwabc 0070 64 65 66 67 68 69 defghi Packet after mutable field hop limit and ICV are zero'd: 0000 00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00 0010 00 00 00 40 33 00 FE 80 00 00 00 00 00 00 02 1D 0020 60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00 02 00 0030 00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9 00 00 0040 00 07 00 00 00 00 00 00 00 00 00 00 00 00 80 00 0050 59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6A 0060 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63 0070 64 65 66 67 68 69 The manual key being used is "0123456789ABCDEF" which has a key length of 16. After the HMAC init function is called with the key and key length, the packet is processed with HMAC-MD5. There are 104 bytes processed from packet offset 000E to 0075: 60 00 00 00 00 40 33 00 FE 80 00 00 00 00 00 00 02 1D 60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00 02 00 00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9 00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 80 00 59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 After the HMAC calculation is finished, the first 96 bits of the hash of the above data is: 70 14 6d d1 15 4c 85 2c 26 a7 31 68 Which does not match the ICV in the packet: 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a I have double checked and the HMAC-MD5-96 hash we calculated is correct for the key and data being processed, therefore I can only assume that the data we are processing is incorrect (or the manual key requires preprocessing?). I've reread the RFCs many times and am at a loss for what could be the problem. Can anyone spot what I am doing wrong? Also it would be very helpful to me if anyone could point to an example of AH processing on an actual packet. Something similar to the steps outlined above? Best Regards, Sean Lawless Blunk Microsystems LLC _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 004AE37B85257420_= Content-Type: text/html; charset="US-ASCII"
Hi Sean.  Please take the following with a grain of salt, because it is relayed secondhand, from a year or two ago, and the original tester is actually no longer with our company.  Our system test group was able to successfully implement dynamic SAs between our platform and Microsoft Windows.  One of our testers had some problems, however, configuring manual SAs between our platform and Windows.  We got the impression at the time that Windows doesn't directly use the key data that you enter in its configuration, but that it somehow hashes it to produce the actual key for the SA.  My recollection (could be wrong) is that he was able to enter key values longer than 16 bytes on Windows for various algorithms (both HMAC-x and encryption algorithms), and this may have been what led us to conclude that the key was derived from what he entered rather than being exactly what he entered.

We couldn't find any documentation on how the keys are derived, and I don't know whether he pursued an answer from Microsoft support.  I suspect that he never got manual keys working.  It wasn't a high priority test in his case since we were able to successfully interact with numerous other platforms using manual SAs.  At very least, we don't currently have any manual SAs in our testbed between our platform and Windows (though we do have dynamic SAs).

So you might consider trying your test with another platform than Windows; perhaps Linux or Cisco.  Alternatively, you might consider contacting Microsoft (or perhaps a Microsoft representative will comment in response to this) to understand how their implementation derives keys for manual SAs.  Lastly, you might consider dynamic SAs, though I realize that this may not be a trivial exercise. :)

For what it's worth, with a quick seat-of-the-pants calculation I did arrive at the same ICV value for your sample data that you obtained.  That doesn't mean that you and I aren't making the same oversight. :)


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen


From: Sean Lawless <sean@blunkmicro.com>
To: ipsec@ietf.org
Date: 04/02/2008 03:16 PM
Subject: [IPsec] AH ICV calculation




Hi all,

We are in the process of implementing static keyed IPSec for the IPv6
portion of a commercial TCP/IP stack and are having problems computing
the AH ICV correctly.  Using NULL as the authentication type there are
no problems communicating with other hosts (Windows XP) so I have ruled
out problems with packet decoding, SPI assignment, etc.  However, using
any HMAC algorithm (MD5-96 or SHA1-96) the calculated ICV never
matches.  I should also note that the HMAC algorithm we are using works
correctly with our TLS 1.0 implementation and so I feel we can rule out
HMAC and MD5/SHA1 algorithms as the problem.

The ICV calculation matches if I test one Windows XP machine against
another or one of our development boards running our stack against
another.  This means our ICV calculation is consistent (but incorrect)
upon inbound and outbound processing.  I have read through the NetBSD
code (ah_core.c) and cannot find any difference in how they are muting
the IPv6 header fields vs. how we are...

I have walked us through an example below that uses MD5 as the AH
algorithm with our implementation receiving an ICMPv6 ping from a
Windows XP host with outbound SPI 3001 (0x00000BB9), configured with
HMAC-MD5-96 and key file "0123456789ABCDEF":

Complete ICMPv6 packet captured with Ethereal:

0000   00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00  ...T....`..>..`.
0010   00 00 00 40 33 80 fe 80 00 00 00 00 00 00 02 1d  ...@3...........
0020   60 ff fe 0d 97 3e fe 80 00 00 00 00 00 00 02 00  `....>..........
0030   00 ff fe 54 85 00 3a 04 00 00 00 00 0b b9 00 00  ...T..:.........
0040   00 07 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a 80 00  ..1..?.m.X......
0050   59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6a  Y3....abcdefghij
0060   6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63  klmnopqrstuvwabc
0070   64 65 66 67 68 69                                defghi

Packet after mutable field hop limit and ICV are zero'd:

0000   00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00
0010   00 00 00 40 33 00 FE 80 00 00 00 00 00 00 02 1D
0020   60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00 02 00
0030   00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9 00 00
0040   00 07 00 00 00 00 00 00 00 00 00 00 00 00 80 00
0050   59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6A
0060   6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63
0070   64 65 66 67 68 69

The manual key being used is "0123456789ABCDEF" which has a key length
of 16.  After the HMAC init function is called with the key and key
length, the packet is processed with HMAC-MD5.  There are 104 bytes
processed from packet offset 000E to 0075:

60 00 00 00 00 40 33 00 FE 80 00 00 00 00 00 00
02 1D 60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00
02 00 00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9
00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00
80 00 59 33 00 00 00 07 61 62 63 64 65 66 67 68
69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61
62 63 64 65 66 67 68 69

After the HMAC calculation is finished, the first 96 bits of the hash of
the above data is:

70 14 6d d1 15 4c 85 2c 26 a7 31 68

Which does not match the ICV in the packet:

31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a

I have double checked and the HMAC-MD5-96 hash we calculated is correct
for the key and data being processed, therefore I can only assume that
the data we are processing is incorrect (or the manual key requires
preprocessing?).  I've reread the RFCs many times and am at a loss for
what could be the problem.  Can anyone spot what I am doing wrong?  Also
it would be very helpful to me if anyone could point to an example of AH
processing on an actual packet.  Something similar to the steps outlined
above?

Best Regards,

Sean Lawless
Blunk Microsystems LLC
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--=_alternative 004AE37B85257420_=-- --===============1024782511== 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://www.ietf.org/mailman/listinfo/ipsec --===============1024782511==-- From ipsec-bounces@ietf.org Thu Apr 3 11:52:26 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9BBA3A6DCE; Thu, 3 Apr 2008 11:52:26 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DDF33A6AF4 for ; Thu, 3 Apr 2008 11:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, MANGLED_GOOD=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxLMq-CzGJoH for ; Thu, 3 Apr 2008 11:52:23 -0700 (PDT) Received: from blnkms23.securesites.net (blnkms23.securesites.net [161.58.211.245]) by core3.amsl.com (Postfix) with ESMTP id 903853A6C56 for ; Thu, 3 Apr 2008 11:52:23 -0700 (PDT) Received: from [172.16.1.35] (adsl-67-119-110-158.dsl.snfc21.pacbell.net [67.119.110.158]) (authenticated bits=0) by blnkms23.securesites.net (8.13.6.20060614/8.13.6) with ESMTP id m33IrV3u094161; Thu, 3 Apr 2008 18:53:34 GMT Message-ID: <47F52762.1070308@blunkmicro.com> Date: Thu, 03 Apr 2008 11:52:18 -0700 From: Sean Lawless Organization: Blunk Microsystems User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Scott C Moonen References: <47F3D9B1.7060500@blunkmicro.com> In-Reply-To: Cc: ipsec@ietf.org Subject: Re: [IPsec] AH ICV calculation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Thanks Scott, your response was helpful. I previously read this thread on the web about Win2003 and Kame and then assumed that Windows was not doing anything special and would interoperate: http://atm.tut.fi/list-archive/snap-users/msg03001.html It sounds like this may not be a safe assumption but I sure wish someone at Microsoft would comment about this. Has anyone successfully interop'ed static keyed Window IPv6 (http://msdn2.microsoft.com/en-us/library/ms737602.aspx) with Kame or another IPSec implementation? If not my next step must be to test with another implementation. Thanks for the help, Sean Scott C Moonen wrote: > > Hi Sean. Please take the following with a grain of salt, because it > is relayed secondhand, from a year or two ago, and the original tester > is actually no longer with our company. Our system test group was > able to successfully implement dynamic SAs between our platform and > Microsoft Windows. One of our testers had some problems, however, > configuring manual SAs between our platform and Windows. We got the > impression at the time that Windows doesn't directly use the key data > that you enter in its configuration, but that it somehow hashes it to > produce the actual key for the SA. My recollection (could be wrong) > is that he was able to enter key values longer than 16 bytes on > Windows for various algorithms (both HMAC-x and encryption > algorithms), and this may have been what led us to conclude that the > key was derived from what he entered rather than being exactly what he > entered. > > We couldn't find any documentation on how the keys are derived, and I > don't know whether he pursued an answer from Microsoft support. I > suspect that he never got manual keys working. It wasn't a high > priority test in his case since we were able to successfully interact > with numerous other platforms using manual SAs. At very least, we > don't currently have any manual SAs in our testbed between our > platform and Windows (though we do have dynamic SAs). > > So you might consider trying your test with another platform than > Windows; perhaps Linux or Cisco. Alternatively, you might consider > contacting Microsoft (or perhaps a Microsoft representative will > comment in response to this) to understand how their implementation > derives keys for manual SAs. Lastly, you might consider dynamic SAs, > though I realize that this may not be a trivial exercise. :) > > For what it's worth, with a quick seat-of-the-pants calculation I did > arrive at the same ICV value for your sample data that you obtained. > That doesn't mean that you and I aren't making the same oversight. :) > > > Scott Moonen (smoonen@us.ibm.com) > z/OS Communications Server TCP/IP Development > http://scott.andstuff.org/ > http://www.linkedin.com/in/smoonen > > > From: Sean Lawless > To: ipsec@ietf.org > Date: 04/02/2008 03:16 PM > Subject: [IPsec] AH ICV calculation > > > ------------------------------------------------------------------------ > > > > Hi all, > > We are in the process of implementing static keyed IPSec for the IPv6 > portion of a commercial TCP/IP stack and are having problems computing > the AH ICV correctly. Using NULL as the authentication type there are > no problems communicating with other hosts (Windows XP) so I have ruled > out problems with packet decoding, SPI assignment, etc. However, using > any HMAC algorithm (MD5-96 or SHA1-96) the calculated ICV never > matches. I should also note that the HMAC algorithm we are using works > correctly with our TLS 1.0 implementation and so I feel we can rule out > HMAC and MD5/SHA1 algorithms as the problem. > > The ICV calculation matches if I test one Windows XP machine against > another or one of our development boards running our stack against > another. This means our ICV calculation is consistent (but incorrect) > upon inbound and outbound processing. I have read through the NetBSD > code (ah_core.c) and cannot find any difference in how they are muting > the IPv6 header fields vs. how we are... > > I have walked us through an example below that uses MD5 as the AH > algorithm with our implementation receiving an ICMPv6 ping from a > Windows XP host with outbound SPI 3001 (0x00000BB9), configured with > HMAC-MD5-96 and key file "0123456789ABCDEF": > > Complete ICMPv6 packet captured with Ethereal: > > 0000 00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00 ...T....`..>..`. > 0010 00 00 00 40 33 80 fe 80 00 00 00 00 00 00 02 1d ...@3........... > 0020 60 ff fe 0d 97 3e fe 80 00 00 00 00 00 00 02 00 `....>.......... > 0030 00 ff fe 54 85 00 3a 04 00 00 00 00 0b b9 00 00 ...T..:......... > 0040 00 07 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a 80 00 ..1..?.m.X...... > 0050 59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6a Y3....abcdefghij > 0060 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 klmnopqrstuvwabc > 0070 64 65 66 67 68 69 defghi > > Packet after mutable field hop limit and ICV are zero'd: > > 0000 00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00 > 0010 00 00 00 40 33 00 FE 80 00 00 00 00 00 00 02 1D > 0020 60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00 02 00 > 0030 00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9 00 00 > 0040 00 07 00 00 00 00 00 00 00 00 00 00 00 00 80 00 > 0050 59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6A > 0060 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63 > 0070 64 65 66 67 68 69 > > The manual key being used is "0123456789ABCDEF" which has a key length > of 16. After the HMAC init function is called with the key and key > length, the packet is processed with HMAC-MD5. There are 104 bytes > processed from packet offset 000E to 0075: > > 60 00 00 00 00 40 33 00 FE 80 00 00 00 00 00 00 > 02 1D 60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00 > 02 00 00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9 > 00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 > 80 00 59 33 00 00 00 07 61 62 63 64 65 66 67 68 > 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 > 62 63 64 65 66 67 68 69 > > After the HMAC calculation is finished, the first 96 bits of the hash of > the above data is: > > 70 14 6d d1 15 4c 85 2c 26 a7 31 68 > > Which does not match the ICV in the packet: > > 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a > > I have double checked and the HMAC-MD5-96 hash we calculated is correct > for the key and data being processed, therefore I can only assume that > the data we are processing is incorrect (or the manual key requires > preprocessing?). I've reread the RFCs many times and am at a loss for > what could be the problem. Can anyone spot what I am doing wrong? Also > it would be very helpful to me if anyone could point to an example of AH > processing on an actual packet. Something similar to the steps outlined > above? > > Best Regards, > > Sean Lawless > Blunk Microsystems LLC > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > ------------------------------------------------------------------------ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 3 20:29:08 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5827B3A6ABE; Thu, 3 Apr 2008 20:29:08 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D6953A6ABE for ; Thu, 3 Apr 2008 20:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.934, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ9GD8Ne44OV for ; Thu, 3 Apr 2008 20:29:06 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 3CE7A3A6885 for ; Thu, 3 Apr 2008 20:29:06 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m343T7Jb051314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Apr 2008 20:29:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <47D06D71.8080705@spawar.navy.mil> References: <47D06D71.8080705@spawar.navy.mil> Date: Thu, 3 Apr 2008 20:29:04 -0700 To: Jeffrey Sun From: Paul Hoffman Cc: IPsec WG Subject: Re: [IPsec] Bug: Section 2.15 - Responder Signed Octets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I'm cleaning up some IKEv2bis issues, and noticed this one had not been replied to. Does everyone agree that this change is correct? --Paul Hoffman At 2:17 PM -0800 3/6/08, Jeffrey Sun wrote: >Current: > >The responder's signed octets can be described as: > > ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR > GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR > RealIKEHDR = SPIi | SPIr | . . . | Length > RealMessage2 = RealIKEHDR | RestOfMessage2 > NonceIPayload = PayloadHeader | NonceIData > ResponderIDPayload = PayloadHeader | RestOfIDPayload > RestOfRespIDPayload = IDType | RESERVED | InitIDData > MACedIDForR = prf(SK_pr, RestOfRespIDPayload) > > > >Suggested: > >The responder's signed octets can be described as: > > ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR > GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR > RealIKEHDR = SPIi | SPIr | . . . | Length > RealMessage2 = RealIKEHDR | RestOfMessage2 > NonceIPayload = PayloadHeader | NonceIData > ResponderIDPayload = PayloadHeader | RestOfIDPayload > RestOfRespIDPayload = IDType | RESERVED | RespIDData > MACedIDForR = prf(SK_pr, RestOfRespIDPayload) > > >Comment: >Changed "InitIDData" to "RespIDData". Unless I'm mistaken that "Init" >stands for "Initiator", it should be "RespIDData". It's really a minor >issue since RestofRespIDPayload infers the IDr Payload (and the >Responder's Identification Data). > > >- Jeff Sun >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Apr 4 04:22:10 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E5DE28C261; Fri, 4 Apr 2008 04:22:10 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA9828C20F for ; Fri, 4 Apr 2008 04:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.971 X-Spam-Level: X-Spam-Status: No, score=-4.971 tagged_above=-999 required=5 tests=[AWL=1.628, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOERARlFX5lh for ; Fri, 4 Apr 2008 04:22:05 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id A601B28C3DC for ; Fri, 4 Apr 2008 04:22:04 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m34BLo8T027210; Fri, 4 Apr 2008 14:22:06 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 14:21:52 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 14:21:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 14:21:50 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7247F2C1@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Bug: Section 2.15 - Responder Signed Octets thread-index: AciWBBNi1nShsjhVS8GoAAmrdP8ctgAQfoVQ References: <47D06D71.8080705@spawar.navy.mil> From: To: X-OriginalArrivalTime: 04 Apr 2008 11:21:52.0839 (UTC) FILETIME=[153F0D70:01C89646] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Bug: Section 2.15 - Responder Signed Octets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Looks correct to me. Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of ext Paul Hoffman > Sent: 04 April, 2008 06:29 > To: Jeffrey Sun > Cc: IPsec WG > Subject: Re: [IPsec] Bug: Section 2.15 - Responder Signed Octets > > I'm cleaning up some IKEv2bis issues, and noticed this one had not > been replied to. Does everyone agree that this change is correct? > > --Paul Hoffman > > At 2:17 PM -0800 3/6/08, Jeffrey Sun wrote: > >Current: > > > >The responder's signed octets can be described as: > > > > ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR > > GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR > > RealIKEHDR = SPIi | SPIr | . . . | Length > > RealMessage2 = RealIKEHDR | RestOfMessage2 > > NonceIPayload = PayloadHeader | NonceIData > > ResponderIDPayload = PayloadHeader | RestOfIDPayload > > RestOfRespIDPayload = IDType | RESERVED | InitIDData > > MACedIDForR = prf(SK_pr, RestOfRespIDPayload) > > > > > > > >Suggested: > > > >The responder's signed octets can be described as: > > > > ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR > > GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR > > RealIKEHDR = SPIi | SPIr | . . . | Length > > RealMessage2 = RealIKEHDR | RestOfMessage2 > > NonceIPayload = PayloadHeader | NonceIData > > ResponderIDPayload = PayloadHeader | RestOfIDPayload > > RestOfRespIDPayload = IDType | RESERVED | RespIDData > > MACedIDForR = prf(SK_pr, RestOfRespIDPayload) > > > > > >Comment: > >Changed "InitIDData" to "RespIDData". Unless I'm mistaken that "Init" > >stands for "Initiator", it should be "RespIDData". It's > really a minor > >issue since RestofRespIDPayload infers the IDr Payload (and the > >Responder's Identification Data). > > > > > >- Jeff Sun > >_______________________________________________ > >IPsec mailing list > >IPsec@ietf.org > >https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Apr 4 04:29:19 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4FD528C628; Fri, 4 Apr 2008 04:29:19 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AF8D3A6969 for ; Fri, 4 Apr 2008 04:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[AWL=1.598, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4bM+LSjXUUS for ; Fri, 4 Apr 2008 04:29:13 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C378728C6B1 for ; Fri, 4 Apr 2008 04:29:12 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m34BSY7h001079; Fri, 4 Apr 2008 14:29:03 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 14:29:02 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 14:29:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 14:29:00 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7247F2DA@vaebe104.NOE.Nokia.com> In-Reply-To: <47E27145.70503@certicom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Obsolete Statements in RFC4306 (IKEv2) thread-index: AciKlKWqMtJ2k/xOQXSlzgmTQ76nmwLsbrOw References: <47E27145.70503@certicom.com> From: To: , X-OriginalArrivalTime: 04 Apr 2008 11:29:02.0802 (UTC) FILETIME=[15863320:01C89647] X-Nokia-AV: Clean Subject: Re: [IPsec] Obsolete Statements in RFC4306 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Chinh Nguyen wrote: > Given this clarification in rfc 4718: > << > Moreover, the combination of ESP and AH (between the same > endpoints) had already become largely obsolete in 1998 when RFC > 2406 was published. Our recommendation is that IKEv2 > implementations should not support this combination, and > implementers should not assume the combination can be made to > work in an interoperable manner. > >> > > Are the following statements obsolete in rfc 4306: > > << > IKE can also negotiate use of IP Compression (IPComp) [IPCOMP] > in connection with an ESP and/or AH SA. > >> > > should be "ESP or AH SA" I agree; thanks for catching this! (Searching for the string "and/or" reveals couple of other places that should be fixed in IKEv2bis.) > << > When SAs are nested, as when data (and IP headers if in tunnel > mode) are encapsulated first with IPComp, then with ESP, and > finally with AH between the same pair of endpoints, all of the > SAs MUST be deleted together. > >> > > should be "first with IPComp, then with ESP or AH" This has been fixed in the current IKEv2bis draft already. > << > If two successive structures have the same Proposal number, it > means that the proposal consists of the first structure AND the > second. So a proposal of AH AND ESP would have two proposal > structures, one for AH and one for ESP and both would have > Proposal #1. > >> > > (In fact, support for proposals with same number not necessary at > all. The only other usage I can think of, IPCOMP, is now a NOTIFY > payload). This has also been fixed already. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Apr 4 04:36:19 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB43A3A6B33; Fri, 4 Apr 2008 04:36:19 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD24F3A6B33 for ; Fri, 4 Apr 2008 04:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.03 X-Spam-Level: X-Spam-Status: No, score=-5.03 tagged_above=-999 required=5 tests=[AWL=1.569, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u06OE3rSmO69 for ; Fri, 4 Apr 2008 04:36:18 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 20AE028C248 for ; Fri, 4 Apr 2008 04:36:16 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m34BZwak009894; Fri, 4 Apr 2008 14:36:18 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 14:36:13 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Apr 2008 14:36:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Apr 2008 14:36:13 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7247F2F4@vaebe104.NOE.Nokia.com> In-Reply-To: <729b68be0803040917wa1da4d6ia676d56409499885@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Fwd: I-D Action:draft-hoffman-ikev2bis-03.txt thread-index: Ach+HKqHdG0yOby3Qmy+PS+KkVX/JgYKpV2w References: <729b68be0803040917wa1da4d6ia676d56409499885@mail.gmail.com> From: To: X-OriginalArrivalTime: 04 Apr 2008 11:36:13.0953 (UTC) FILETIME=[16829F10:01C89648] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Fwd: I-D Action:draft-hoffman-ikev2bis-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org (apologies for a late reply) Jean-Michel Combes wrote: > Hi, > > I have two questions regarding this draft. > > o Protocol ID field (section 3.10 - Protocol ID description) > Is it normal the sentence "For IKE_SA notifications, this field MUST > be one (1)" has been removed (in fact, this sentence has been removed > since the version -01 of the draft)? RFC 4718 Section 7.8 has some explanation about this situation. Basically, RFC 4306 didn't actually say which notifications are about IKE_SA (and thus it was unclear what implementations should send, or can expect to receive, in this field). > o SPI field (section 3.10 - SPI Size description) > It is said that "For a notification concerning the IKE_SA, the SPI > Size MUST be zero.". Does it mean that the SPI MUST be empty too? Or > is it just a way to identify this is a notification concerning the > IKE_SA (and so the SPI field may be not empty) because, in this case, > there is no more assigned value for the Protocol ID field? If the SPI size is zero, the SPI field is also empty (otherwise, it would be difficult to parse the message). For IKE_SA notifications, the SPIs are in the message header, not inside the Notify payload. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Apr 4 13:54:10 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1583A6D82; Fri, 4 Apr 2008 13:54:10 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA5B3A6CA1 for ; Fri, 4 Apr 2008 13:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, MANGLED_GOOD=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hj-2CEM1DxKz for ; Fri, 4 Apr 2008 13:54:07 -0700 (PDT) Received: from blnkms23.securesites.net (blnkms23.securesites.net [161.58.211.245]) by core3.amsl.com (Postfix) with ESMTP id 12C573A6B9B for ; Fri, 4 Apr 2008 13:54:04 -0700 (PDT) Received: from [172.16.1.35] (adsl-67-119-110-158.dsl.snfc21.pacbell.net [67.119.110.158]) (authenticated bits=0) by blnkms23.securesites.net (8.13.6.20060614/8.13.6) with ESMTP id m34Ks5nk072573; Fri, 4 Apr 2008 20:54:08 GMT Message-ID: <47F69574.4080703@blunkmicro.com> Date: Fri, 04 Apr 2008 13:54:12 -0700 From: Sean Lawless Organization: Blunk Microsystems User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Scott C Moonen References: <47F3D9B1.7060500@blunkmicro.com> <47F52762.1070308@blunkmicro.com> In-Reply-To: <47F52762.1070308@blunkmicro.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] AH ICV calculation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, To conclude this thread, I tested our implementation with FreeBSD (Kame) today and found they interoperate just fine with static keys. Thus the issue I encountered is Windows specific. So if anyone else asks, the ipsec6.exe command on Windows cannot be used to configure static keys that inter operate with other IPSec implementations. Maybe the next person who goes down this road will see this thread and avoid this. Regards, Sean Sean Lawless wrote: > Thanks Scott, your response was helpful. I previously read this thread > on the web about Win2003 and Kame and then assumed that Windows was not > doing anything special and would interoperate: > > http://atm.tut.fi/list-archive/snap-users/msg03001.html > > It sounds like this may not be a safe assumption but I sure wish someone > at Microsoft would comment about this. Has anyone successfully > interop'ed static keyed Window IPv6 > (http://msdn2.microsoft.com/en-us/library/ms737602.aspx) with Kame or > another IPSec implementation? If not my next step must be to test with > another implementation. > > Thanks for the help, > Sean > > > Scott C Moonen wrote: > >> Hi Sean. Please take the following with a grain of salt, because it >> is relayed secondhand, from a year or two ago, and the original tester >> is actually no longer with our company. Our system test group was >> able to successfully implement dynamic SAs between our platform and >> Microsoft Windows. One of our testers had some problems, however, >> configuring manual SAs between our platform and Windows. We got the >> impression at the time that Windows doesn't directly use the key data >> that you enter in its configuration, but that it somehow hashes it to >> produce the actual key for the SA. My recollection (could be wrong) >> is that he was able to enter key values longer than 16 bytes on >> Windows for various algorithms (both HMAC-x and encryption >> algorithms), and this may have been what led us to conclude that the >> key was derived from what he entered rather than being exactly what he >> entered. >> >> We couldn't find any documentation on how the keys are derived, and I >> don't know whether he pursued an answer from Microsoft support. I >> suspect that he never got manual keys working. It wasn't a high >> priority test in his case since we were able to successfully interact >> with numerous other platforms using manual SAs. At very least, we >> don't currently have any manual SAs in our testbed between our >> platform and Windows (though we do have dynamic SAs). >> >> So you might consider trying your test with another platform than >> Windows; perhaps Linux or Cisco. Alternatively, you might consider >> contacting Microsoft (or perhaps a Microsoft representative will >> comment in response to this) to understand how their implementation >> derives keys for manual SAs. Lastly, you might consider dynamic SAs, >> though I realize that this may not be a trivial exercise. :) >> >> For what it's worth, with a quick seat-of-the-pants calculation I did >> arrive at the same ICV value for your sample data that you obtained. >> That doesn't mean that you and I aren't making the same oversight. :) >> >> >> Scott Moonen (smoonen@us.ibm.com) >> z/OS Communications Server TCP/IP Development >> http://scott.andstuff.org/ >> http://www.linkedin.com/in/smoonen >> >> >> From: Sean Lawless >> To: ipsec@ietf.org >> Date: 04/02/2008 03:16 PM >> Subject: [IPsec] AH ICV calculation >> >> >> ------------------------------------------------------------------------ >> >> >> >> Hi all, >> >> We are in the process of implementing static keyed IPSec for the IPv6 >> portion of a commercial TCP/IP stack and are having problems computing >> the AH ICV correctly. Using NULL as the authentication type there are >> no problems communicating with other hosts (Windows XP) so I have ruled >> out problems with packet decoding, SPI assignment, etc. However, using >> any HMAC algorithm (MD5-96 or SHA1-96) the calculated ICV never >> matches. I should also note that the HMAC algorithm we are using works >> correctly with our TLS 1.0 implementation and so I feel we can rule out >> HMAC and MD5/SHA1 algorithms as the problem. >> >> The ICV calculation matches if I test one Windows XP machine against >> another or one of our development boards running our stack against >> another. This means our ICV calculation is consistent (but incorrect) >> upon inbound and outbound processing. I have read through the NetBSD >> code (ah_core.c) and cannot find any difference in how they are muting >> the IPv6 header fields vs. how we are... >> >> I have walked us through an example below that uses MD5 as the AH >> algorithm with our implementation receiving an ICMPv6 ping from a >> Windows XP host with outbound SPI 3001 (0x00000BB9), configured with >> HMAC-MD5-96 and key file "0123456789ABCDEF": >> >> Complete ICMPv6 packet captured with Ethereal: >> >> 0000 00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00 ...T....`..>..`. >> 0010 00 00 00 40 33 80 fe 80 00 00 00 00 00 00 02 1d ...@3........... >> 0020 60 ff fe 0d 97 3e fe 80 00 00 00 00 00 00 02 00 `....>.......... >> 0030 00 ff fe 54 85 00 3a 04 00 00 00 00 0b b9 00 00 ...T..:......... >> 0040 00 07 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a 80 00 ..1..?.m.X...... >> 0050 59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6a Y3....abcdefghij >> 0060 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 klmnopqrstuvwabc >> 0070 64 65 66 67 68 69 defghi >> >> Packet after mutable field hop limit and ICV are zero'd: >> >> 0000 00 00 00 54 85 00 00 1d 60 0d 97 3e 86 dd 60 00 >> 0010 00 00 00 40 33 00 FE 80 00 00 00 00 00 00 02 1D >> 0020 60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00 02 00 >> 0030 00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9 00 00 >> 0040 00 07 00 00 00 00 00 00 00 00 00 00 00 00 80 00 >> 0050 59 33 00 00 00 07 61 62 63 64 65 66 67 68 69 6A >> 0060 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 62 63 >> 0070 64 65 66 67 68 69 >> >> The manual key being used is "0123456789ABCDEF" which has a key length >> of 16. After the HMAC init function is called with the key and key >> length, the packet is processed with HMAC-MD5. There are 104 bytes >> processed from packet offset 000E to 0075: >> >> 60 00 00 00 00 40 33 00 FE 80 00 00 00 00 00 00 >> 02 1D 60 FF FE 0D 97 3E FE 80 00 00 00 00 00 00 >> 02 00 00 FF FE 54 85 00 3A 04 00 00 00 00 0B B9 >> 00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 >> 80 00 59 33 00 00 00 07 61 62 63 64 65 66 67 68 >> 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 61 >> 62 63 64 65 66 67 68 69 >> >> After the HMAC calculation is finished, the first 96 bits of the hash of >> the above data is: >> >> 70 14 6d d1 15 4c 85 2c 26 a7 31 68 >> >> Which does not match the ICV in the packet: >> >> 31 02 0c 3f 1d 6d ee 58 9d f1 fb 1a >> >> I have double checked and the HMAC-MD5-96 hash we calculated is correct >> for the key and data being processed, therefore I can only assume that >> the data we are processing is incorrect (or the manual key requires >> preprocessing?). I've reread the RFCs many times and am at a loss for >> what could be the problem. Can anyone spot what I am doing wrong? Also >> it would be very helpful to me if anyone could point to an example of AH >> processing on an actual packet. Something similar to the steps outlined >> above? >> >> Best Regards, >> >> Sean Lawless >> Blunk Microsystems LLC >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From jyxnanettebarattahel@nanettebaratta.com Sun Apr 6 23:21:11 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B3833A6BA2; Sun, 6 Apr 2008 23:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.826 X-Spam-Level: **** X-Spam-Status: No, score=4.826 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwGAlW2s4FMA; Sun, 6 Apr 2008 23:21:10 -0700 (PDT) Received: from [116.71.243.214] (unknown [116.71.243.214]) by core3.amsl.com (Postfix) with ESMTP id 30C023A6BAE; Sun, 6 Apr 2008 23:21:09 -0700 (PDT) Received: from [116.71.243.214] by eforward4.name-services.com; Mon, 7 Apr 2008 11:21:21 +0500 Date: Mon, 7 Apr 2008 11:21:21 +0500 From: "Sheryl Hoyt" X-Mailer: The Bat! (v2.00.5) Personal Reply-To: jyxnanettebarattahel@nanettebaratta.com X-Priority: 3 (Normal) Message-ID: <276381876.00023547464370@nanettebaratta.com> To: agentx-archive@lists.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------86E6E6E6E67291C" ------------86E6E6E6E67291C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Our main purpose is to guarantee PC and Mac lawful software and computer solutions of low cost for anyone. Whether you're a corporate customer, a small enterprise proprietor, or shopping for your home personal computer, we believe we'll assist you. CHECK WHAT WE HAVE TO OFFER! http://frankiesubletteps539.googlepages.com ------------86E6E6E6E67291C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Our main purpose is to guarantee PC and Mac lawful software and computer solutions of low cost for anyone.
Whether you're a corporate customer, a small enterprise proprietor,
or shopping for your home personal computer, we believe we'll assist you.
CHECK WHAT WE HAVE TO OFFER!
http://frankiesubletteps539.googlepages.com
------------86E6E6E6E67291C-- From ipsec-bounces@ietf.org Mon Apr 7 07:34:43 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D5B3A6CF5; Mon, 7 Apr 2008 07:34:43 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B236E3A6DA2 for ; Fri, 4 Apr 2008 11:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.48 X-Spam-Level: X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IP_ADDR=1.119] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rz8a6J1mnZ9h for ; Fri, 4 Apr 2008 11:01:33 -0700 (PDT) Received: from ins2.sd.spawar.navy.mil (ins2.sd.spawar.navy.mil [IPv6:2001:480:10:4::3]) by core3.amsl.com (Postfix) with ESMTP id 9812D28C19D for ; Fri, 4 Apr 2008 11:01:32 -0700 (PDT) Received: from [128.49.163.29] (2872sun.spawar.navy.mil [128.49.163.29]) by ins2.sd.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id m2VG0J06021070; Mon, 31 Mar 2008 09:00:20 -0700 Message-ID: <47F10A93.9080600@nkiconsulting.com> Date: Mon, 31 Mar 2008 09:00:19 -0700 From: Jeffrey Sun User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: IPsec WG X-Mailman-Approved-At: Mon, 07 Apr 2008 07:34:42 -0700 Subject: [IPsec] Redundant IKE_SAs Issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org All, RFC 4306 and RFC 4718 seems to contradict each other and I was hoping someone could provide clarification. RFC 4306 - Section 2.8 talks about the resolving of redundant SAs through a Nonce Comparison test, and in a nutshell, the SA established with the lowest of the four nonces exchanged SHOULD be closed/deleted; note, the term "SA" was used and thus worded agnostic to IKE_SA or CHILD_SA. RFC 4718 - Section 5.11.4 seems to contradicts this by stating: "After the CREATE_CHILD_SA exchanges, three IKE_SAs exist between A and B; the one containing the lowest nonce inherits the CHILD_SAs." RFC 4306 essentially states that the "losing" SA is the SA created with the lowest Nonce; RFC 4718 essentially states that the IKE_SA created with the lowest Nonce inherits the CHILD_SAs. Why would one have the "losing" SA inherit the CHILD_SAs? According to a thread created by Fukumoto Atsushi (http://www.ietf.org/mail-archive/web/ipsec/current/msg01859.html), Tero Kivinen comments in a reply that, by his interpretations, the "winning" IKE_SA is the IKE_SA that inherits the CHILD_SAs. Also, the bis-003 document (http://www.ietf.org/internet-drafts/draft-hoffman-ikev2bis-03.txt) contains no specific reference or context to this at all, but may hint at the intent of what to do. Specifically, Section 2.8.1 is labeled "Simultaneous CHILD_SA rekeying" and there is no equivalent "Simultaneous IKE_SA rekeying". However, the way that 2.8.1 is worded, using the term "SA" rather than "CHILD_SA" alludes to the fact that Section 2.8.1 is SA agnostic. If that is the case, the section should be renamed to "Simultaneous SA rekeying" instead. Thanks in advance for the help. - Jeff Sun _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Apr 7 08:25:57 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C92493A6D9F; Mon, 7 Apr 2008 08:25:57 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 126F73A67D4 for ; Mon, 7 Apr 2008 08:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo3sSGoqC7zW for ; Mon, 7 Apr 2008 08:25:47 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 33DA328C130 for ; Mon, 7 Apr 2008 08:25:42 -0700 (PDT) Received: from [10.71.0.244] (rrcs-72-43-25-26.nys.biz.rr.com [72.43.25.26]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m37FPraj033178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 7 Apr 2008 08:25:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 7 Apr 2008 11:25:51 -0400 To: IPsec WG From: Paul Hoffman Subject: [IPsec] Fwd: [saag] TSVWG last call on "UDP Usage Guidelines for Application Designers" to BCP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org [[ Of interest to us UDP-users. ]] >Hi, > >I would like to inform that currently TSVWG has started the WG last call >on "UDP Usage Guidelines for Application Designers" >(draft-ietf-tsvwg-udp-guidelines-06) with the intended status of BCP. It >runs until the 21st of April. If you like to provide any comments please >send them to the TSVWG mailing list (tsvwg@ietf.org). > >Abstract: > > The User Datagram Protocol (UDP) provides a minimal, message-passing > transport that has no inherent congestion control mechanisms. > Because congestion control is critical to the stable operation of the > Internet, applications and upper-layer protocols that choose to use > UDP as an Internet transport must employ mechanisms to prevent > congestion collapse and establish some degree of fairness with > concurrent traffic. This document provides guidelines on the use of > UDP for the designers of such applications and upper-layer protocols. > Congestion control guidelines are a primary focus, but the document > also provides guidance on other topics, including message sizes, > reliability, checksums and middlebox traversal. > >http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-udp-guidelines-06.txt > >Best Regards > >Magnus Westerlund > >IETF Transport Area Director & TSVWG Chair >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 8 4048287 >F=E4r=F6gatan 6 | Fax +46 8 7575550 >S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 10 04:46:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE33A3A6A14; Thu, 10 Apr 2008 04:46:17 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78D323A6B4D for ; Thu, 10 Apr 2008 04:46:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.504 X-Spam-Level: * X-Spam-Status: No, score=1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgEGFYRVaYoa for ; Thu, 10 Apr 2008 04:46:14 -0700 (PDT) Received: from zns001-0m9003.yokogawa.co.jp (zns001-0m9003.yokogawa.co.jp [203.174.79.161]) by core3.amsl.com (Postfix) with ESMTP id 6EDB83A6A14 for ; Thu, 10 Apr 2008 04:46:14 -0700 (PDT) Received: from zns001-0m9003.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id m3ABkXaB029154 for ; Thu, 10 Apr 2008 20:46:33 +0900 (JST) Received: from zex001-0m9027.jp.ykgw.net (zex001-0m9027.jp.ykgw.net [10.0.11.46]) by zns001-0m9003.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id m3ABkX39029151 for ; Thu, 10 Apr 2008 20:46:33 +0900 (JST) Received: from EXMAIL02.jp.ykgw.net ([10.0.11.28]) by zex001-0m9027.jp.ykgw.net ([10.0.11.46]) with mapi; Thu, 10 Apr 2008 20:46:33 +0900 From: To: Date: Thu, 10 Apr 2008 20:46:32 +0900 Thread-Topic: response to Informational Messages outside of an IKE_SA Thread-Index: AcibAIYDMN9Ze31GQnyzoQfQ46OrEA== Message-ID: <6E54B86AA7254B43B1B0217628D37B3702AFF9452056@EXMAIL02.jp.ykgw.net> Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP MIME-Version: 1.0 Subject: [IPsec] response to Informational Messages outside of an IKE_SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all, I am Hiroki ENDO, a member of TAHI project. I am describing IKEv2 conformance test specfication and developping test tools. I'd like to confirm what is "respond" in RFC 4306 Section 1.5. RFC 4306 says: ------------------------------------------------------------------------ 1.5. Informational Messages outside of an IKE_SA ... If it does not have such an IKE_SA, it MAY send an Informational message without cryptographic protection to the source IP address. Such a message is not part of an informational exchange, and the receiving node MUST NOT respond to it. Doing so could cause a message loop. ^^^^^^^ ------------------------------------------------------------------------ Currently I think that "respond" is to send a response to an Informational message without cryptographic protection or to retransmita message which raises the Informational messsage without cryptographic protection. Because such action can cause a message loop. Though it may be not common case, the current test sequence and check point are as follows: (Initiator) (Responder) NUT Tester | | |---------->| IKE_SA_INIT request (HDR, SAi1, KEi, Ni) | | (Judgment #1) |<----------| IKE_SA_INIT response (HDR, SAi1, KEi, Ni) | | |---------->| IKE_AUTH request (HDR, SK{IDi, UATH, SAi2, TSi, TSr}) | | (Judgment #2) |<----------| IKE_AUTH response (HDR, N(INVALID_IKE_SPI)) | | |-----X | no IKE message | | or |---------->| IKE_SA_INIT request (HDR, SAi1, KEi, Ni) | | (Judgment #3) | | V V Judgment #1 NUT sends IKE_SA_INIT request. Judgment #2 NUT sends IKE_AUTH request. Judgment #3 NUT can send no IKEv2 messages to give up negotiation or send IKE_SA_INIT request to initiate negotiation again. Is what I wrote correct? How do you think the test sequence? Thanks, -- Hiroki ENDO Yokogawa Electric Corporation _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 10 06:13:47 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31A093A6B5D; Thu, 10 Apr 2008 06:13:47 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4681A3A6B5D for ; Thu, 10 Apr 2008 06:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgRk0v6cU+d8 for ; Thu, 10 Apr 2008 06:13:45 -0700 (PDT) Received: from mail.kivinen.iki.fi (unknown [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 8183B3A6D38 for ; Thu, 10 Apr 2008 06:13:44 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id m3ADE0d7027338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Apr 2008 16:14:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id m3ADE0OF021425; Thu, 10 Apr 2008 16:14:00 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18430.4760.110960.13060@fireball.kivinen.iki.fi> Date: Thu, 10 Apr 2008 16:14:00 +0300 From: Tero Kivinen To: In-Reply-To: <6E54B86AA7254B43B1B0217628D37B3702AFF9452056@EXMAIL02.jp.ykgw.net> References: <6E54B86AA7254B43B1B0217628D37B3702AFF9452056@EXMAIL02.jp.ykgw.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 10 min Cc: ipsec@ietf.org Subject: [IPsec] response to Informational Messages outside of an IKE_SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hiroki.Endou@jp.yokogawa.com writes: > Hi all, > > I am Hiroki ENDO, a member of TAHI project. > I am describing IKEv2 conformance test specfication and developping test tools. > > I'd like to confirm what is "respond" in RFC 4306 Section 1.5. > > RFC 4306 says: > ------------------------------------------------------------------------ > 1.5. Informational Messages outside of an IKE_SA > ... > If it > does not have such an IKE_SA, it MAY send an Informational message > without cryptographic protection to the source IP address. Such a > message is not part of an informational exchange, and the receiving > node MUST NOT respond to it. Doing so could cause a message loop. > ^^^^^^^ > ------------------------------------------------------------------------ Respond in that case means that the responder do not send specific reply to that informational message. It does NOT mean that the initiator cannot still continue sending the original message (that is not a response to the information message, that is simply retranmission of packet which have not received reply yet). > Currently I think that "respond" is to send a response to an > Informational message without cryptographic protection or to > retransmita message which raises the Informational messsage without > cryptographic protection. Retransmission is allowed, and in most of the case actually desired. I.e. as the informational message is not cryptographically protected, the initiator will not necessarely act on it directly, but will keep normal retransmissions for the previous message. It might use that message as hint that there is something wrong, i.e. it might for example limit the number of packets it is sending out. It should NOT shorten the retranmission periods based on that. > Because such action can cause a message loop. Loop will only be caused if the responder sends unauthenticated error notify, and the initiator sees that unauthenticated error notify and sends unauthenticated error notify because it received unauthenticated notify, and then responder gets unauthenticated error notify and sends again unauthenticated error notify about that etc... > Though it may be not common case, the current test sequence and > check point are as follows: > > (Initiator) (Responder) > NUT Tester > | | > |---------->| IKE_SA_INIT request (HDR, SAi1, KEi, Ni) > | | (Judgment #1) > |<----------| IKE_SA_INIT response (HDR, SAi1, KEi, Ni) > | | > |---------->| IKE_AUTH request (HDR, SK{IDi, UATH, SAi2, TSi, TSr}) > | | (Judgment #2) > |<----------| IKE_AUTH response (HDR, N(INVALID_IKE_SPI)) Here the initiator will most likely continue retransmission of the IKE_AUTH as the N(INVALID_IKE_SPI) notify is unauthenticated. It might use the unauthenticated N(INVALID_IKE_SPI) notify as hint that the other end might have rebooted, so it might for example time the exchange out after retransmitting its IKE_AUTH request only 2 or 3 times, instead of the normal 10 or so... After it times the exchange out, it will most likely start the exchange again after next packet that triggers SA creation is seen. Note, that it might also act differently on the error cases which cannot be fixed without adminstrator changing policy. For example the the N(INVALID_IKE_SPI) usually just means that responder rebooted between the IKE_SA_INIT and IKE_AUTH, so it should try again immediately when the previous exchange times out, but for example AUTHENTICATION_FAILED will not usually disappear until policy is fixed in one of the ends, so in those cases it might for example wait for few minutes before retrying (just to limit the number of Diffie-Hellmans to be done by misconfiguration). > | | > |-----X | no IKE message > | | or > |---------->| IKE_SA_INIT request (HDR, SAi1, KEi, Ni) > | | (Judgment #3) > | | > V V > > Judgment #1 > NUT sends IKE_SA_INIT request. > Judgment #2 > NUT sends IKE_AUTH request. > Judgment #3 > NUT can send no IKEv2 messages to give up negotiation or send > IKE_SA_INIT request to initiate negotiation again. > > > Is what I wrote correct? > How do you think the test sequence? -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From negoneshotfirearmskap@oneshotfirearms.com Fri Apr 11 00:08:25 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E3828C11D; Fri, 11 Apr 2008 00:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.131 X-Spam-Level: *** X-Spam-Status: No, score=3.131 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, URIBL_GREY=0.25] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9wYYfIattk5; Fri, 11 Apr 2008 00:08:20 -0700 (PDT) Received: from host115-214-static.46-85-b.business.telecomitalia.it (host115-214-static.46-85-b.business.telecomitalia.it [85.46.214.115]) by core3.amsl.com (Postfix) with ESMTP id 484653A6E34; Fri, 11 Apr 2008 00:08:02 -0700 (PDT) Received: from [85.46.214.115] by oneshotfirearms.com; Fri, 11 Apr 2008 08:08:42 +0100 Date: Fri, 11 Apr 2008 08:08:42 +0100 From: "Rosalind Bowles" X-Mailer: The Bat! (v2.00) Educational Reply-To: negoneshotfirearmskap@oneshotfirearms.com X-Priority: 3 (Normal) Message-ID: <138193221.06221903751090@oneshotfirearms.com> To: agentx-archive@lists.ietf.org Subject: Legal software sales MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------86E67215AF21C705" ------------86E67215AF21C705 Content-Type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7bit Our goal is to assure low price PC and Mac lawful soft and computer solutions any could afford. Whether you are a corporate purchaser, a small enterprise possessor, or go shopping for your own home PC, we suppose we can assist you. CHECK WHAT WE HAVE TO OFFER! http://earnestinermsf689.googlepages.com ------------86E67215AF21C705 Content-Type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7bit Our goal is to assure low price PC and Mac lawful soft and computer solutions any could afford.
Whether you are a corporate purchaser, a small enterprise possessor,
or go shopping for your own home PC, we suppose we can assist you.
CHECK WHAT WE HAVE TO OFFER!
http://earnestinermsf689.googlepages.com
------------86E67215AF21C705-- From ipsec-bounces@ietf.org Fri Apr 11 02:26:21 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87AA13A6C61; Fri, 11 Apr 2008 02:26:21 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64B73A6A10 for ; Fri, 11 Apr 2008 02:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.375 X-Spam-Level: X-Spam-Status: No, score=-5.375 tagged_above=-999 required=5 tests=[AWL=1.224, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXrUiDq8aRIN for ; Fri, 11 Apr 2008 02:26:18 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id A8ACA3A6C61 for ; Fri, 11 Apr 2008 02:26:14 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3B9RHa7024377; Fri, 11 Apr 2008 04:28:52 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Apr 2008 12:26:15 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 11 Apr 2008 12:26:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 11 Apr 2008 12:26:14 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7255E413@vaebe104.NOE.Nokia.com> In-Reply-To: <47F10A93.9080600@nkiconsulting.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Redundant IKE_SAs Issues thread-index: AciYvJnLrv5C76i6QyCQv/9EvQqrPwC+LNNA References: <47F10A93.9080600@nkiconsulting.com> From: To: , X-OriginalArrivalTime: 11 Apr 2008 09:26:15.0158 (UTC) FILETIME=[16F53160:01C89BB6] X-Nokia-AV: Clean Subject: Re: [IPsec] Redundant IKE_SAs Issues X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Jeffrey Sun wrote: > All, > RFC 4306 and RFC 4718 seems to contradict each other and I > was hoping someone could provide clarification. RFC 4306 - Section > 2.8 talks about the resolving of redundant SAs through a Nonce > Comparison test, and in a nutshell, the SA established with the > lowest of the four nonces exchanged SHOULD be closed/deleted; note, > the term "SA" was used and thus worded agnostic to IKE_SA or > CHILD_SA. RFC 4718 - Section 5.11.4 seems to contradicts this by > stating: "After the CREATE_CHILD_SA exchanges, three IKE_SAs exist > between A and B; the one containing the lowest nonce inherits the > CHILD_SAs." I think you've found a bug in RFC 4718 :-) That sentence in RFC 4718 should probably say something like "After the CREATE_CHILD_SA exchanges, three IKE_SAs exist between A and B. Of the two new IKE_SAs, the one containing the lowest nonce is closed, and the other one inherits the CHILD_SAs." > Also, the bis-003 document > (http://www.ietf.org/internet-drafts/draft-hoffman-ikev2bis-03.txt) > contains no specific reference or context to this at all, but > may hint at the intent of what to do. Yep, much of the RFC 4718 text about exchange collisions has not yet been included in IKEv2bis. (But the text is so complex that I doubt that many implementors will get it right anyway -- this is something IKEv2 should have handled in some different fashion, but it's too late to change now...) Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From DanaraphaelPage@craigslist.org Tue Apr 15 12:52:54 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB75D28C2C3; Tue, 15 Apr 2008 12:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.329 X-Spam-Level: X-Spam-Status: No, score=-14.329 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DATE_IN_FUTURE_03_06=0.274, FH_RELAY_NODNS=1.451, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DSBL=0.961, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1HKVCujO7Yg; Tue, 15 Apr 2008 12:52:51 -0700 (PDT) Received: from yilmazadibelli.domain.invalid (unknown [85.100.85.183]) by core3.amsl.com (Postfix) with SMTP id DE15E3A684F; Tue, 15 Apr 2008 12:52:49 -0700 (PDT) Received: from 11859651354056634.11127959411191637.12810523364611274.19224062248711319 (HELO localhost.localdomain) (11910404753226757.16482572770946198.14614554646265011.17307170939503676) by 19415240854080257.14473882326690738.12903760921536774.19057178098835165 with SMTP; Tue, 15 Apr 2008 22:51:44 -0200 Date: Tue, 15 Apr 2008 22:51:44 -0200 Message-Id: <2IX643EJXVWDA434@craigslist.org> X-Mailer: MIME::Lite 3.01 (F2.72; A1.62; B3.01; Q3.01) X-Header-CompanyDBUserName: hpccm X-Header-MasterId: 165874 X-Header-Versions: Hewlett-Packard.0t3bn6nd4.fk@us.newsgram.hp.com X-FID: 49E79DBC-3649-74AF-B1E7-52CDEA90DCB3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: , , , , From: "Trevor Guzman" Subject: Doctor Approved And Recommended. In 2 Weeks You Can See Surprising Results. Success Is Certain. http://poweieant.com/ From ipsec-bounces@ietf.org Tue Apr 15 18:38:21 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 048DC3A6F45; Tue, 15 Apr 2008 18:38:21 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358883A6F62 for ; Tue, 15 Apr 2008 18:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.504 X-Spam-Level: * X-Spam-Status: No, score=1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_23=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cg-yPr4C2uh3 for ; Tue, 15 Apr 2008 18:38:19 -0700 (PDT) Received: from zns001-0m9001.yokogawa.co.jp (zns001-0m9001.yokogawa.co.jp [203.174.79.138]) by core3.amsl.com (Postfix) with ESMTP id 1BF3E3A6F32 for ; Tue, 15 Apr 2008 18:38:18 -0700 (PDT) Received: from zns001-0m9001.yokogawa.co.jp (localhost [127.0.0.1]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id m3G1cnAh002756; Wed, 16 Apr 2008 10:38:50 +0900 (JST) Received: from zex001-kz9012.jp.ykgw.net (zex001-kz9012.jp.ykgw.net [10.0.11.111]) by zns001-0m9001.yokogawa.co.jp (8.12.10+Sun/8.12.10) with ESMTP id m3G1claL002709; Wed, 16 Apr 2008 10:38:47 +0900 (JST) Received: from EXMAIL02.jp.ykgw.net ([10.0.11.28]) by zex001-kz9012.jp.ykgw.net ([10.0.11.111]) with mapi; Wed, 16 Apr 2008 10:38:47 +0900 From: To: Date: Wed, 16 Apr 2008 10:38:45 +0900 Thread-Topic: [IPsec] response to Informational Messages outside of an IKE_SA Thread-Index: AcibDMactRlQU6yAQxKvFMJTmFvEGwEU3LlQ Message-ID: <6E54B86AA7254B43B1B0217628D37B3702AFF9452063@EXMAIL02.jp.ykgw.net> In-Reply-To: <18430.4760.110960.13060@fireball.kivinen.iki.fi> Accept-Language: ja-JP Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: ja-JP MIME-Version: 1.0 Cc: ipsec@ietf.org Subject: Re: [IPsec] response to Informational Messages outside of an IKE_SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, Thanks for your reply. It is helpful for me. I realized that it was difficult to test this case. Thanks again, -- Hiroki ENDO Yokogawa Electric Corporation > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Thursday, April 10, 2008 10:14 PM > To: Endou, Hiroki (Hiroki.Endou@jp.yokogawa.com) > Cc: ipsec@ietf.org > Subject: [IPsec] response to Informational Messages outside > of an IKE_SA > > Hiroki.Endou@jp.yokogawa.com writes: > > Hi all, > > > > I am Hiroki ENDO, a member of TAHI project. > > I am describing IKEv2 conformance test specfication and > developping test tools. > > > > I'd like to confirm what is "respond" in RFC 4306 Section 1.5. > > > > RFC 4306 says: > > > ---------------------------------------------------------------------- > > -- 1.5. Informational Messages outside of an IKE_SA > > ... > > > If it > > does not have such an IKE_SA, it MAY send an > Informational message > > without cryptographic protection to the source IP > address. Such a > > message is not part of an informational exchange, and > the receiving > > node MUST NOT respond to it. Doing so could cause a > message loop. > > ^^^^^^^ > > > ---------------------------------------------------------------------- > > -- > > Respond in that case means that the responder do not send > specific reply to that informational message. It does NOT > mean that the initiator cannot still continue sending the > original message (that is not a response to the information > message, that is simply retranmission of packet which have > not received reply yet). > > > Currently I think that "respond" is to send a response to an > > Informational message without cryptographic protection or to > > retransmita message which raises the Informational messsage without > > cryptographic protection. > > Retransmission is allowed, and in most of the case actually desired. > I.e. as the informational message is not cryptographically > protected, the initiator will not necessarely act on it > directly, but will keep normal retransmissions for the > previous message. It might use that message as hint that > there is something wrong, i.e. it might for example limit the > number of packets it is sending out. It should NOT shorten > the retranmission periods based on that. > > > Because such action can cause a message loop. > > Loop will only be caused if the responder sends > unauthenticated error notify, and the initiator sees that > unauthenticated error notify and sends unauthenticated error > notify because it received unauthenticated notify, and then > responder gets unauthenticated error notify and sends again > unauthenticated error notify about that etc... > > > Though it may be not common case, the current test sequence > and check > > point are as follows: > > > > (Initiator) (Responder) > > NUT Tester > > | | > > |---------->| IKE_SA_INIT request (HDR, SAi1, KEi, Ni) > > | | (Judgment #1) > > |<----------| IKE_SA_INIT response (HDR, SAi1, KEi, Ni) > > | | > > |---------->| IKE_AUTH request (HDR, SK{IDi, UATH, > SAi2, TSi, TSr}) > > | | (Judgment #2) > > |<----------| IKE_AUTH response (HDR, N(INVALID_IKE_SPI)) > > Here the initiator will most likely continue retransmission > of the IKE_AUTH as the N(INVALID_IKE_SPI) notify is > unauthenticated. It might use the unauthenticated > N(INVALID_IKE_SPI) notify as hint that the other end might > have rebooted, so it might for example time the exchange out > after retransmitting its IKE_AUTH request only 2 or 3 times, > instead of the normal 10 or so... > > After it times the exchange out, it will most likely start > the exchange again after next packet that triggers SA > creation is seen. > Note, that it might also act differently on the error cases > which cannot be fixed without adminstrator changing policy. > > For example the the N(INVALID_IKE_SPI) usually just means > that responder rebooted between the IKE_SA_INIT and IKE_AUTH, > so it should try again immediately when the previous exchange > times out, but for example AUTHENTICATION_FAILED will not > usually disappear until policy is fixed in one of the ends, > so in those cases it might for example wait for few minutes > before retrying (just to limit the number of Diffie-Hellmans > to be done by misconfiguration). > > > | | > > |-----X | no IKE message > > | | or > > |---------->| IKE_SA_INIT request (HDR, SAi1, KEi, Ni) > > | | (Judgment #3) > > | | > > V V > > > > Judgment #1 > > NUT sends IKE_SA_INIT request. > > Judgment #2 > > NUT sends IKE_AUTH request. > > Judgment #3 > > NUT can send no IKEv2 messages to give up negotiation or send > > IKE_SA_INIT request to initiate negotiation again. > > > > > > Is what I wrote correct? > > How do you think the test sequence? > -- > kivinen@safenet-inc.com > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 16 23:39:59 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 540B828C50C; Wed, 16 Apr 2008 23:39:59 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ABA028C50C for ; Wed, 16 Apr 2008 23:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 965MSuOBIN5F for ; Wed, 16 Apr 2008 23:39:56 -0700 (PDT) Received: from strongswan.org (sidv0150.hsr.ch [152.96.52.150]) by core3.amsl.com (Postfix) with ESMTP id 740CE28C4B5 for ; Wed, 16 Apr 2008 23:39:56 -0700 (PDT) Received: from [152.96.15.205] (unknown [152.96.15.205]) by strongswan.org (Postfix) with ESMTP id 016E2EF99F; Thu, 17 Apr 2008 08:40:30 +0200 (CEST) Message-ID: <4806F0DF.2080302@strongswan.org> Date: Thu, 17 Apr 2008 08:40:31 +0200 From: Andreas Steffen Organization: Linux strongSwan User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: IPsec WG Subject: [IPsec] I-D Action:draft-brunner-ikev2-mediation-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Good morning! strongSwan team member Tobias Brunner has defined and implemented a Mediation Extension for the IKEv2 protocol. An example scenario with two IPsec hosts behind NAT routers can be studied under the following link: http://www.strongswan.org/uml/testresults42/p2pnat/medsrv-psk/ Please let us know what you think about our proposal. Best regards Andreas Steffen A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IKEv2 Mediation Extension Author(s) : T. Brunner Filename : draft-brunner-ikev2-mediation-00.txt Pages : 36 Date : 2008-04-16 This document describes the IKEv2 Mediation Extension (IKE-ME), a connectivity extension to the Internet Key Exchange IKEv2. IKE-ME allows two peers, each behind one or more Network Address Translators (NATs) or firewalls to establish a direct and secure connection without the need to configure any of the intermediate network devices. To establish this direct connection, a process similar to Interactive Connectivity Establishment (ICE) is used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brunner-ikev2-mediation-00.txt ====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From pnavy@leahzicari.com Fri Apr 18 07:59:21 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123573A6919; Fri, 18 Apr 2008 07:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.635 X-Spam-Level: ** X-Spam-Status: No, score=2.635 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, PRICES_ARE_AFFORDABLE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRAjHU8a26pg; Fri, 18 Apr 2008 07:59:20 -0700 (PDT) Received: from 20158147219.user.veloxzone.com.br (20158147219.user.veloxzone.com.br [201.58.147.219]) by core3.amsl.com (Postfix) with SMTP id E64E13A6948; Fri, 18 Apr 2008 07:59:17 -0700 (PDT) Received: from MICRO01 ([213.156.122.85] helo=MICRO01) by db933ac9leahzicari.com (8.11.10/8.11.10) with SMTP id 800B56893302 for ; Fri, 18 Apr 2008 11:59:21 -0300 Message-ID: <001101c8a14b$a3263b30$006493dc@MICRO01> From: Morris Wilder To: imapext-archive@lists.ietf.org Subject: do void Date: Fri, 18 Apr 2008 11:59:21 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C8A14B.A3263B30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.3000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.3000 This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C8A14B.A3263B30 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: quoted-printable thus, permitting affordable prices for people wishing to live in live and breath this artificial world of the VR. The effects the whole picture of a controversial issue which provides the ------=_NextPart_000_000E_01C8A14B.A3263B30 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
newspaper, borrow a book from the library,get a video or play

C A 5N A D/7AN     P 5 0H A RM A 1CY

V/A \G _RA - $1.44
C 0/ A L / S - $2.29
S9 O M A - $0.65
L E2 V / T R A - $3.60
FEMALE V\A\G -R A - $1.59
U 5 L T 5R A M - $1.39
189 Items on Sale Today.

invitations and gold embossed papers? How could one put a wedding ------=_NextPart_000_000E_01C8A14B.A3263B30-- From mfderive@intrav.com Sun Apr 20 11:36:59 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824843A65A6; Sun, 20 Apr 2008 11:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAB+6wdIJKiU; Sun, 20 Apr 2008 11:36:58 -0700 (PDT) Received: from intrav.com (unknown [62.182.93.102]) by core3.amsl.com (Postfix) with SMTP id 8AA723A6C88; Sun, 20 Apr 2008 11:36:57 -0700 (PDT) Received: from 7771a52e4ac0c6 [93.239.206.103] (port=24453 helo=7771a52e4ac0c6) by 665db63eintrav.com (8.11.8/8.11.8) with ESMTP id 781C515B1DB2 for ; Sun, 20 Apr 2008 22:37:06 +0400 Message-ID: <001301c8a337$0fbafaa0$0064cecc@7771a52e4ac0c6> From: icon in To: imapext-archive@lists.ietf.org Subject: no prolonged Date: Sun, 20 Apr 2008 22:37:06 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C8A337.0FBAFAA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2462.1106 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2462.2969 This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C8A337.0FBAFAA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable except for artists, writers, and lawyers. Well, that statement isolated in a indirect way everyday. Each day for several hours is definitely the most powerful medium here. I have found other ------=_NextPart_000_0010_01C8A337.0FBAFAA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
great technological advancements and now we're at a threshold.

C A 7N A D/9AN     P 4 8H A RM A 4CY

V/A \G _RA - $1.44
C 5/ A L / S - $2.25
S8 O M A - $0.67
L E3 V / T R A - $3.64
FEMALE V\A\G -R A - $1.51
U 9 L T 0R A M - $1.34
167 Items on Sale Today.

children to distinguish between fact and fiction. And so long as
= ------=_NextPart_000_0010_01C8A337.0FBAFAA0-- From ipsec-bounces@ietf.org Tue Apr 22 00:00:13 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A6428C457; Tue, 22 Apr 2008 00:00:13 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B1028C455 for ; Tue, 22 Apr 2008 00:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.399 X-Spam-Level: * X-Spam-Status: No, score=1.399 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFYLAVY99Ps6 for ; Tue, 22 Apr 2008 00:00:10 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 215CD3A6B26 for ; Tue, 22 Apr 2008 00:00:09 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m3M70Et6023960 for ; Tue, 22 Apr 2008 16:00:14 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 8136063EE for ; Tue, 22 Apr 2008 16:00:14 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 7CC8063ED for ; Tue, 22 Apr 2008 16:00:14 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m3M70Dqo011886 for ; Tue, 22 Apr 2008 16:00:14 +0900 (JST) Received: from iml.m.ecl.ntt.co.jp (iml0.m.ecl.ntt.co.jp [129.60.5.150]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m3M70D0s011877; Tue, 22 Apr 2008 16:00:13 +0900 (JST) Received: from [127.0.0.1] (tamura-x31.nslab.ecl.ntt.co.jp [129.60.11.21]) by iml.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m3M70D9T013369; Tue, 22 Apr 2008 16:00:13 +0900 (JST) Date: Tue, 22 Apr 2008 16:04:20 +0900 From: Toshihiko Tamura To: ipsec@ietf.org Message-Id: <20080422155817.9967.TAMURA.TOSHIHIKO@lab.ntt.co.jp> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.25 [ja] Subject: [IPsec] IKEv2 TS payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hello, I'm one of the members of TAHI project. There's one unclear point about IKEv2 Traffic Selector payload. We use TS payload, TSi and TSr, for setting IPsec selectors. But I'm afraid that the definition of "i" and "r" is so ambiguous. Of course, it's perfectly clear in the case of initial exchange. But in the case of rekeying, there is a possibility that it becomes problem. (Initiator) (Responder) | | |---------->| IKE SA INIT |<----------| IKE SA INIT |---------->| IKE AUTH | (snip) | |<----------| IKE AUTH | | (Initial Exchange completed) | | | | |<----------| Create Child SA request | | (HDR, SAi1, Ni, TSi, TSr, ...) | | |---------->| Create Child SA response | | (HDR, SAi2, Nr, TSi, TSr, ...) | | V V In above case, a responder at initial exchange initiates rekey. Which is correct, #1 or #2? TSi in Create Child SA message includes the address and port number for #1: the initiator which has established initial SAs. #2: the initiator which initiates rekeying. Vice versa for TSr. Best Regards, ----- Toshihiko TAMURA, NTT _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 00:57:32 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FD293A6FC1; Tue, 22 Apr 2008 00:57:32 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29193A68C3 for ; Tue, 22 Apr 2008 00:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TxLhcAs+Edc for ; Tue, 22 Apr 2008 00:57:26 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dyn32-54.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 9F6B828C468 for ; Tue, 22 Apr 2008 00:57:24 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id DDEEB294002; Tue, 22 Apr 2008 10:57:29 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 45ED0294001; Tue, 22 Apr 2008 10:57:29 +0300 (IDT) Received: from [172.31.24.139] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m3M7vSfU008673; Tue, 22 Apr 2008 10:57:29 +0300 (IDT) Message-Id: From: Yoav Nir To: ipsec@ietf.org, Toshihiko Tamura In-Reply-To: <20080422155817.9967.TAMURA.TOSHIHIKO@lab.ntt.co.jp> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 22 Apr 2008 10:57:27 +0300 References: <20080422155817.9967.TAMURA.TOSHIHIKO@lab.ntt.co.jp> X-Mailer: Apple Mail (2.919.2) Subject: Re: [IPsec] IKEv2 TS payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org #2 - the initiator that initiates rekeying. This is explained in section 2.9 of RFC 4306 The first of the two TS payloads is known as TSi (Traffic Selector- initiator). The second is known as TSr (Traffic Selector- responder). TSi specifies the source address of traffic forwarded from (or the destination address of traffic forwarded to) the initiator of the CHILD_SA pair. Yoav On Apr 22, 2008, at 10:04 AM, Toshihiko Tamura wrote: > > Hello, > > I'm one of the members of TAHI project. > There's one unclear point about IKEv2 Traffic Selector payload. > > We use TS payload, TSi and TSr, for setting IPsec selectors. > But I'm afraid that the definition of "i" and "r" is so ambiguous. > Of course, it's perfectly clear in the case of initial exchange. > But in the case of rekeying, there is a possibility that > it becomes problem. > > > (Initiator) (Responder) > | | > |---------->| IKE SA INIT > |<----------| IKE SA INIT > |---------->| IKE AUTH > | (snip) | > |<----------| IKE AUTH > | | (Initial Exchange completed) > | | > | | > |<----------| Create Child SA request > | | (HDR, SAi1, Ni, TSi, TSr, ...) > | | > |---------->| Create Child SA response > | | (HDR, SAi2, Nr, TSi, TSr, ...) > | | > V V > > In above case, a responder at initial exchange initiates rekey. > Which is correct, #1 or #2? > > > TSi in Create Child SA message includes the address and > port number for > #1: the initiator which has established initial SAs. > #2: the initiator which initiates rekeying. > > Vice versa for TSr. > > Best Regards, > ----- > Toshihiko TAMURA, NTT > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 01:48:16 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A48BC3A69B7; Tue, 22 Apr 2008 01:48:16 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35DE93A69B7 for ; Tue, 22 Apr 2008 01:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.654 X-Spam-Level: X-Spam-Status: No, score=0.654 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fygHV86Kdn9H for ; Tue, 22 Apr 2008 01:48:10 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 78BEA3A6986 for ; Tue, 22 Apr 2008 01:48:10 -0700 (PDT) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.14.2/8.14.2) with ESMTP id m3M8kNDK006573; Tue, 22 Apr 2008 17:46:23 +0900 (JST) Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 032ED63EE; Tue, 22 Apr 2008 17:46:23 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (eclscan2.m.ecl.ntt.co.jp [129.60.5.68]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id D7F8263ED; Tue, 22 Apr 2008 17:46:22 +0900 (JST) Received: from eclscan2.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m3M8kLvC029104; Tue, 22 Apr 2008 17:46:22 +0900 (JST) Received: from iml.m.ecl.ntt.co.jp (iml0.m.ecl.ntt.co.jp [129.60.5.150]) by eclscan2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m3M8kKp8029089; Tue, 22 Apr 2008 17:46:20 +0900 (JST) Received: from [127.0.0.1] (tamura-x31.nslab.ecl.ntt.co.jp [129.60.11.21]) by iml.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id m3M8kK0W025496; Tue, 22 Apr 2008 17:46:20 +0900 (JST) Date: Tue, 22 Apr 2008 17:50:28 +0900 From: Toshihiko Tamura To: ipsec@ietf.org In-Reply-To: References: <20080422155817.9967.TAMURA.TOSHIHIKO@lab.ntt.co.jp> Message-Id: <20080422172935.997D.TAMURA.TOSHIHIKO@lab.ntt.co.jp> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.25 [ja] Cc: Yoav Nir Subject: Re: [IPsec] IKEv2 TS payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Thanks Yoav, > TSi specifies the source address of traffic forwarded from (or the > destination address of traffic forwarded to) the initiator of the > CHILD_SA pair. ^^^^^^^^^^^^^^ So you mean, the word "the initiator" in above sentence means the initiator which initiate rekeying. I also agree to that. But there is a possibility to interpret the meaning of "the initiator" as the initiator which has established initial SAs. (I can say "original initiator"?) Actually I know some IKEv2 supported equipments which implement with not only #2 but #1. I would just like to point out it may be ambiguous. Am I being worried too much? Best regards, Toshihiko Tamura > #2 - the initiator that initiates rekeying. > > This is explained in section 2.9 of RFC 4306 > > The first of the two TS payloads is known as TSi (Traffic Selector- > initiator). The second is known as TSr (Traffic Selector- > responder). > TSi specifies the source address of traffic forwarded from (or the > destination address of traffic forwarded to) the initiator of the > CHILD_SA pair. > > Yoav > > On Apr 22, 2008, at 10:04 AM, Toshihiko Tamura wrote: > > > > > Hello, > > > > I'm one of the members of TAHI project. > > There's one unclear point about IKEv2 Traffic Selector payload. > > > > We use TS payload, TSi and TSr, for setting IPsec selectors. > > But I'm afraid that the definition of "i" and "r" is so ambiguous. > > Of course, it's perfectly clear in the case of initial exchange. > > But in the case of rekeying, there is a possibility that > > it becomes problem. > > > > > > (Initiator) (Responder) > > | | > > |---------->| IKE SA INIT > > |<----------| IKE SA INIT > > |---------->| IKE AUTH > > | (snip) | > > |<----------| IKE AUTH > > | | (Initial Exchange completed) > > | | > > | | > > |<----------| Create Child SA request > > | | (HDR, SAi1, Ni, TSi, TSr, ...) > > | | > > |---------->| Create Child SA response > > | | (HDR, SAi2, Nr, TSi, TSr, ...) > > | | > > V V > > > > In above case, a responder at initial exchange initiates rekey. > > Which is correct, #1 or #2? > > > > > > TSi in Create Child SA message includes the address and > > port number for > > #1: the initiator which has established initial SAs. > > #2: the initiator which initiates rekeying. > > > > Vice versa for TSr. > > > > Best Regards, > > ----- > > Toshihiko TAMURA, NTT > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 01:59:58 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C5763A6FE4; Tue, 22 Apr 2008 01:59:58 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A1D73A6FD1 for ; Tue, 22 Apr 2008 01:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRer+CC8t3Fh for ; Tue, 22 Apr 2008 01:59:53 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 116273A6FAF for ; Tue, 22 Apr 2008 01:59:52 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m3M8xkFa001959 for ; Tue, 22 Apr 2008 11:59:56 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 11:59:40 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Apr 2008 11:59:39 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Apr 2008 11:59:39 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPsec maintenance/extensions WG? Thread-index: AcikVzJFP8ywxWHKStKk3V5BcOU+lQ== From: To: X-OriginalArrivalTime: 22 Apr 2008 08:59:39.0930 (UTC) FILETIME=[32ABF7A0:01C8A457] X-Nokia-AV: Clean Subject: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, During the Philadelphia meeting, several folks expressed interest in forming a working group for IPsec maintenance and extensions. Since IKEv2 is included in, for example, various US Government IPv6 profiles, we'll probably see a number of new IKEv2 implementations during the next couple of years. Having a working group would provide a forum for discussing implementation questions, and ensuring that results from, e.g., interoperability workshops are actually written down in the specifications (which didn't happen for IKEv1). While some maintenance work has already been done (RFC 4718, draft-hoffman-ikev2bis), and the ipsec mailing list still exists, finding those has been difficult for non-insiders. Also, the maintenance work has so far focused largely on the "remote access VPN" (client-to-gateway) use case, which exercises slightly different parts of the specs than host-to-host and gateway-to-gateway IPsec. At the same time, there has been interest in standardizing small improvements and extensions that were not included in the IKEv2 base specifications (just search for drafts containing "-ikev2-" or "-ipsec-"). Some of those extensions could benefit from wider participation that having a working group would bring. To actually form a WG, we would need to agree on the initial charter scope, and have enough people to work on all the items we decide to take on. My current thinking is that the WG charter should describe a small number of specific work items and reasonable timelines for completing them, as opposed to including everything related to IPsec and planning to have the WG around forever. To get some discussion started, please send your opinions on whether having a WG would be a good idea, your thoughts on what the charter should look like, and what you'd consider to be the most important work items. (If you've talked with me about this topic earlier, please still post your opinions on the list for others to see.) Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 02:47:57 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3FC73A6B8E; Tue, 22 Apr 2008 02:47:57 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82A833A6A2D for ; Tue, 22 Apr 2008 02:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT-fe5wke-hY for ; Tue, 22 Apr 2008 02:47:55 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dyn32-54.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 5008B3A685E for ; Tue, 22 Apr 2008 02:47:55 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 88F56294002; Tue, 22 Apr 2008 12:48:00 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id CEF0E294001 for ; Tue, 22 Apr 2008 12:47:59 +0300 (IDT) Received: from [91.90.139.73] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m3M9lwfU027907 for ; Tue, 22 Apr 2008 12:47:59 +0300 (IDT) Message-ID: <480DB453.8050503@checkpoint.com> Date: Tue, 22 Apr 2008 12:48:03 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I strongly support this idea. While the initial charter needs to be well defined, with clear goals and schedules, the new WG should also serve as a forum for discussing implementation issues. This would imply a lifetime beyond the first few RFCs. During the Philadelphia meeting I played a bit with this notion, and here is the draft charter I came up with. Thanks, Yaron Name: IPsec Maintenance The IPsec Maintenance working group is responsible for the maintenance, upkeep, and advancement of the IKE and IPsec protocol specifications and architecture. The working group will address protocol limitations/issues discovered during deployment and operation. It will also serve as a venue for discussing the proper location for working on IKE/IPsec-related issues within the IETF. The group is not chartered to develop major changes or additions to the IPsec suite of specifications. Objectives: - Standardize minor extensions to IKEv2. Changes with architectural ramifications (e.g. changes to the policy description model) are out of scope unless specifically chartered later. A non-exclusive list of relevant extensions is below. - Provide technical guidance to other IETF workgroups, and to other SDOs, on the proper use of IKE/IPsec protocols. Assist such groups in developing specific profiles of IKE/IPsec protocols. Examples include, but are not limited to, the various routing protocol security efforts underway. - Complete and publish the IKEv2bis (IKEv2 clarifications) work. - Track IKE/IPsec interop events, clarify and revise the protocols if necessary following these events. Relevant IPsec Extensions (extensions will become work items only by working group consensus): [Note: this is *not* in priority order. The list should be narrowed down and target dates added.] - IKEv2 IPv6 configuration - IKEv2 session resumption (IFARE) - IPsec secure beacon - IKE crash detection - IPsec with AEAD - ESP-null marking - IKE/GRE interaction - IKEv2 OTP - IKEv2 Captcha - Various crypto algorithm-related drafts - Anything that may be needed from IKE/IPsec with respect to routing protocol security. All new work items not listed above require the approval of the working group and the sponsoring Area Director before they can be taken on by the working group. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 05:54:14 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53663A6978; Tue, 22 Apr 2008 05:54:14 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 870AD3A6978 for ; Tue, 22 Apr 2008 05:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXkwRxo0iLWe for ; Tue, 22 Apr 2008 05:54:12 -0700 (PDT) Received: from mail.ca.certicom.com (mail.ca.certicom.com [38.113.160.197]) by core3.amsl.com (Postfix) with SMTP id 70FFC3A68F5 for ; Tue, 22 Apr 2008 05:54:12 -0700 (PDT) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 90F601002912A; Tue, 22 Apr 2008 08:54:15 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vH11udsatmxa; Tue, 22 Apr 2008 08:54:13 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP; Tue, 22 Apr 2008 08:54:13 -0400 (EDT) Received: from [10.0.8.48] ([10.0.8.48]) by domino1.certicom.com (Lotus Domino Release 7.0.2FP2 HF177) with ESMTP id 2008042208522816-24525 ; Tue, 22 Apr 2008 08:52:28 -0400 Message-ID: <480DE063.7020605@certicom.com> Date: Tue, 22 Apr 2008 08:56:03 -0400 From: Chinh Nguyen User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/22/2008 08:52:28 AM, Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/22/2008 08:52:29 AM, Serialize complete at 04/22/2008 08:52:29 AM Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org IKEv2 is also used in other standards. In some cases, these look to be subtly different than the current IKEv2 standard. 3gpp and 3gpp2 comes to mind. Perhaps the WG can also survey the IKEv2 "landscape" so that IKEv2 implementors are aware of these issues, especially those that deviate from the norm. Chinh -- http://www.certicom.com Pasi.Eronen@nokia.com wrote: > Hi, > > During the Philadelphia meeting, several folks expressed interest > in forming a working group for IPsec maintenance and extensions. > > Since IKEv2 is included in, for example, various US Government IPv6 > profiles, we'll probably see a number of new IKEv2 implementations > during the next couple of years. Having a working group would > provide a forum for discussing implementation questions, and > ensuring that results from, e.g., interoperability workshops are > actually written down in the specifications (which didn't happen > for IKEv1). _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 08:24:53 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E3F33A6E2B; Tue, 22 Apr 2008 08:24:53 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9009E3A6E10 for ; Tue, 22 Apr 2008 08:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZQ-t2o1-cxo for ; Tue, 22 Apr 2008 08:24:45 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9FEAA3A6E01 for ; Tue, 22 Apr 2008 08:24:44 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m3MFOlXM048990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Apr 2008 08:24:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> Date: Tue, 22 Apr 2008 08:24:45 -0700 To: , From: Paul Hoffman Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 11:59 AM +0300 4/22/08, wrote: >Since IKEv2 is included in, for example, various US Government IPv6 >profiles, we'll probably see a number of new IKEv2 implementations >during the next couple of years. Quite right. There are a few commercial VPN gateways with IKEv2, but only a few. There are many more OEM kits that contain IKEv2. >Having a working group would >provide a forum for discussing implementation questions, and >ensuring that results from, e.g., interoperability workshops are >actually written down in the specifications (which didn't happen >for IKEv1). This seems useful if (and only if) it doesn't cause people to think "hey, I should start something because there is a WG". That is, the WG should work on deployable extensions and corrections to the current IKEv1 and IKEv2 base, but not encourage people to develop things that are not widely needed. >My current thinking is that the WG charter should describe a small >number of specific work items and reasonable timelines for >completing them, as opposed to including everything related to >IPsec and planning to have the WG around forever. Yay! Now if you could just get your co-AD to feel the same way about PKIX... >To get some discussion started, please send your opinions on >whether having a WG would be a good idea, your thoughts on what >the charter should look like, and what you'd consider to be the >most important work items. I'm happy to have the infrequently-updated draft-hoffman-ikev2bis as part of the WG. Your draft-eronen-ipsec-ikev2-ipv6-config should certainly be there as well. In fact, it would be grand if the WG spent a fair amount of time making sure that IKEv1 and IKEv2 worked as well as possible with IPv6, both from a standards and from an operations standpoint. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 08:47:41 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5683A6DE4; Tue, 22 Apr 2008 08:47:40 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29E028C14C for ; Tue, 22 Apr 2008 08:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.368 X-Spam-Level: X-Spam-Status: No, score=0.368 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rMWRNESeVzb for ; Tue, 22 Apr 2008 08:47:37 -0700 (PDT) Received: from mailgate-internal4.sri.com (mailgate-internal4.SRI.COM [128.18.84.114]) by core3.amsl.com (Postfix) with SMTP id D56DE3A6A31 for ; Tue, 22 Apr 2008 08:47:36 -0700 (PDT) Received: from smssmtp-internal2.sri.com (128.18.84.116) by mailgate-internal4.sri.com with SMTP; 22 Apr 2008 15:47:42 -0000 X-AuditID: 80125474-adb8dbb000007084-ad-480e089e7f5f Received: from srimail1.sri.com (srimail1.SRI.COM [128.18.30.11]) by smssmtp-internal2.sri.com (Symantec Mail Security) with ESMTP id B89B31B2501 for ; Tue, 22 Apr 2008 08:47:42 -0700 (PDT) Received: from [192.168.2.101] (static-72-90-189-2.nwrknj.east.verizon.net [72.90.189.2]) by mail.sri.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JZQ000Y1H7H6620@mail.sri.com> for ipsec@ietf.org; Tue, 22 Apr 2008 08:47:41 -0700 (PDT) Date: Tue, 22 Apr 2008 11:47:40 -0400 From: Ed Jankiewicz To: ipsec@ietf.org Message-id: <480E089C.1080601@sri.com> MIME-version: 1.0 User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) X-Brightmail-Tracker: AAAAAA== Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org As someone involved with one of the above-mentioned IPv6 Profiles efforts, I would support establishing an IPsec maintenance WG and hope to contribute. We are interacting with several vendors on IPsec topics, IKEv2 in particular, and are encouraging implementations, testing and interoperability events. The draft charter is a good starting point. One additional topic of concern is IKEv2/IKEv1 co-existence. With development cycles, it may be some time before IKEv2 becomes pervasive, and existing IKEv1 implementations will persist. While IKEv2 by design is not interoperable with IKEv1, and I'm not proposing a major change to the protocol to make it so, I would like to see some realistic discussion of approaches to simplify implementation, deployment and management of IKE during the transition period. Perhaps a work item for a Problem Statement on this would be reasonable? No need to commit to a solution until that item is addressed. Forgive me if this is a long-buried dead horse. I was not involved in IETF activities at the time IKEv2 was developed and published, and there may be a long history of debate on the subject. If so, no need to clutter the list with a recap, just drop me a line off-list. -- Ed Jankiewicz - SRI International Fort Monmouth Branch Office - IPv6 Research Supporting DISA Standards Engineering Branch 732-389-1003 or ed.jankiewicz@sri.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 09:32:41 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD2828C47C; Tue, 22 Apr 2008 09:32:41 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75E0D28C46A for ; Tue, 22 Apr 2008 09:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.587 X-Spam-Level: X-Spam-Status: No, score=-0.587 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJ3TJZqzAsSG for ; Tue, 22 Apr 2008 09:32:34 -0700 (PDT) Received: from arwen.velv.hr (arwen.velv.hr [193.198.63.3]) by core3.amsl.com (Postfix) with ESMTP id 5A30228C451 for ; Tue, 22 Apr 2008 09:30:54 -0700 (PDT) Received: from localhost (localhost.velv.hr [127.0.0.1]) by arwen.velv.hr (Postfix) with ESMTP id 22A044261; Tue, 22 Apr 2008 18:30:59 +0200 (CEST) Received: from arwen.velv.hr ([127.0.0.1]) by localhost (arwen [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04646-04; Tue, 22 Apr 2008 18:30:43 +0200 (CEST) Received: by arwen.velv.hr (Postfix, from userid 1790) id 974E24283; Tue, 22 Apr 2008 18:30:43 +0200 (CEST) Date: Tue, 22 Apr 2008 18:30:43 +0200 From: Ana Kukec To: Pasi.Eronen@nokia.com Message-ID: <20080422163043.GH21850@arwen.velv.hr> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at vels.hr Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all, I support the idea of having IPSec maintainance/extensions WG. As you were talking about extensions, i wonder if the CGA extension for IKEv2 could be one of possible work items? CGA [rfc3972] enabled IKEv2 could be extended to provide security without any pre-deployed and/or centralized trust infrastructure based on IKEv2 peer authentication via IPv6 Cryptographically Generated Addresses. In that case, we would need IKEv2 extensions in order to support IKEv2 authentication based on CGA address-proof-of-ownership and PAD extensions (primarily) to ensure a secure initial CGA authentication. I am also wondering about the MOBIKE extensions, as something similar could be done also for MOBIKE. Kind regards, Ana Pasi.Eronen@nokia.com wrote: > Hi, > > During the Philadelphia meeting, several folks expressed interest > in forming a working group for IPsec maintenance and extensions. > > Since IKEv2 is included in, for example, various US Government IPv6 > profiles, we'll probably see a number of new IKEv2 implementations > during the next couple of years. Having a working group would > provide a forum for discussing implementation questions, and > ensuring that results from, e.g., interoperability workshops are > actually written down in the specifications (which didn't happen > for IKEv1). > > While some maintenance work has already been done (RFC 4718, > draft-hoffman-ikev2bis), and the ipsec mailing list still exists, > finding those has been difficult for non-insiders. Also, the > maintenance work has so far focused largely on the "remote access > VPN" (client-to-gateway) use case, which exercises slightly > different parts of the specs than host-to-host and > gateway-to-gateway IPsec. > > At the same time, there has been interest in standardizing small > improvements and extensions that were not included in the IKEv2 > base specifications (just search for drafts containing "-ikev2-" > or "-ipsec-"). Some of those extensions could benefit from wider > participation that having a working group would bring. > > To actually form a WG, we would need to agree on the initial > charter scope, and have enough people to work on all the items > we decide to take on. > > My current thinking is that the WG charter should describe a small > number of specific work items and reasonable timelines for > completing them, as opposed to including everything related to > IPsec and planning to have the WG around forever. > > To get some discussion started, please send your opinions on > whether having a WG would be a good idea, your thoughts on what > the charter should look like, and what you'd consider to be the > most important work items. > > (If you've talked with me about this topic earlier, please > still post your opinions on the list for others to see.) > > Best regards, > Pasi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 10:36:07 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78CFC28C4B6; Tue, 22 Apr 2008 10:36:07 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5A628C4C8 for ; Tue, 22 Apr 2008 10:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNGoJ5nGjHhF for ; Tue, 22 Apr 2008 10:35:56 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id C345E28C4DD for ; Tue, 22 Apr 2008 10:31:52 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m3MHVvJc013793 for ; Tue, 22 Apr 2008 13:31:57 -0400 (EDT) Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor) for ; Tue, 22 Apr 2008 13:31:57 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m3MHVQsG020871 for ; Tue, 22 Apr 2008 13:31:55 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Apr 2008 13:31:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8A49E.8C98DAF6" Date: Tue, 22 Apr 2008 13:30:25 -0400 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91016F6051@CORPUSMX20A.corp.emc.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-black-ipsec-ikev2-aead-modes-01.txt Thread-Index: AciknKBWI5iuGOzyQH+S4H8cNhYWcgAAH5/A To: X-OriginalArrivalTime: 22 Apr 2008 17:31:24.0931 (UTC) FILETIME=[B0474D30:01C8A49E] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow Subject: [IPsec] FW: I-D ACTION:draft-black-ipsec-ikev2-aead-modes-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A49E.8C98DAF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a coincidence, here's one of the drafts for the proposed IPsec maintenance/extensions WG. I think that proposed WG is a good idea, as it should be a more appropriate forum than SAAG for working on ipsec-related drafts such as this. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, April 22, 2008 1:15 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-black-ipsec-ikev2-aead-modes-01.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts=20 directories. Title : Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol Author(s) : D. Black, D. McGrew Filename : draft-black-ipsec-ikev2-aead-modes-01.txt Pages : 19 Date : 2008-4-22 =09 An authenticated encryption algorithm combines encryption and=20 integrity into a single operation; such algorithms may also be=20 referred to as combined modes of an encryption cipher or as combined mode algorithms. This document describes the use of authenticated=20 encryption algorithms with the Encrypted Payload of the Internet Key=20 Exchange version 2 (IKEv2) protocol.=20 The use of two specific authenticated encryption algorithms with the=20 IKEv2 Encrypted Payload is also described; these two algorithms are=20 the Advanced Encryption Standard (AES) in Galois/Counter Mode (AES=20 GCM) and AES in Counter with CBC-MAC Mode (AES CCM). Additional=20 documents may describe the use of other authenticated encryption=20 algorithms with the IKEv2 Encrypted Payload. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-black-ipsec-ikev2-aead-modes-0 1.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C8A49E.8C98DAF6 Content-Type: application/octet-stream; name="draft-black-ipsec-ikev2-aead-modes-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-black-ipsec-ikev2-aead-modes-01.URL Content-Disposition: attachment; filename="draft-black-ipsec-ikev2-aead-modes-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ibGFjay1pcHNlYy1pa2V2Mi1hZWFkLW1vZGVzLTAxLnR4dA0K ------_=_NextPart_001_01C8A49E.8C98DAF6 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://www.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01C8A49E.8C98DAF6-- From ipsec-bounces@ietf.org Tue Apr 22 10:40:06 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 105E33A6FB1; Tue, 22 Apr 2008 10:40:06 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 743E83A6780 for ; Tue, 22 Apr 2008 10:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h86ZWJuXgq5Q for ; Tue, 22 Apr 2008 10:39:56 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 3FF7D3A7049 for ; Tue, 22 Apr 2008 10:38:59 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m3MHcxO1002366 for ; Tue, 22 Apr 2008 13:38:59 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m3MHcx5F225820 for ; Tue, 22 Apr 2008 13:38:59 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m3MHcnVJ001118 for ; Tue, 22 Apr 2008 13:38:49 -0400 Received: from austin.ibm.com (netmail1.austin.ibm.com [9.41.248.175]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m3MHcm3s000628; Tue, 22 Apr 2008 13:38:49 -0400 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.53.40.35]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id m3MHccFL037674; Tue, 22 Apr 2008 12:38:38 -0500 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.14.2/8.12.8) with ESMTP id m3MHLMVx001728; Tue, 22 Apr 2008 12:21:22 -0500 Received: (from jml@localhost) by faith.austin.ibm.com (8.14.2/8.14.2/Submit) id m3MHLMTp001727; Tue, 22 Apr 2008 12:21:22 -0500 Date: Tue, 22 Apr 2008 12:21:22 -0500 From: Joy Latten Message-Id: <200804221721.m3MHLMTp001727@faith.austin.ibm.com> To: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org >At the same time, there has been interest in standardizing small >improvements and extensions that were not included in the IKEv2 >base specifications (just search for drafts containing "-ikev2-" >or "-ipsec-"). Some of those extensions could benefit from wider >participation that having a working group would bring. > >To actually form a WG, we would need to agree on the initial >charter scope, and have enough people to work on all the items >we decide to take on. > >My current thinking is that the WG charter should describe a small >number of specific work items and reasonable timelines for >completing them, as opposed to including everything related to >IPsec and planning to have the WG around forever. > >To get some discussion started, please send your opinions on >whether having a WG would be a good idea, your thoughts on what >the charter should look like, and what you'd consider to be the >most important work items. > I think it is a great idea! I have been involved in government certifications involving IPsec, in particular LSPP in which we used IPsec for MAC on network communications, often called "labeled ipsec". I am in the process of writing internet drafts to extend IKEv1 and IKEv2 to include generic security labels. I would like very much to add this as a work item. This may be a moot topic, if so please ignore, but are there any plans to improve/extend pfkey for ikev2? Just wondering. :-) Thank you! regards, Joy Latten IBM Linux Technology Center _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 11:03:22 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93EAE3A6841; Tue, 22 Apr 2008 11:03:22 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74BED3A6E33 for ; Tue, 22 Apr 2008 11:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjpTvJ4l+hW8 for ; Tue, 22 Apr 2008 11:03:19 -0700 (PDT) Received: from strongswan.org (sidv0150.hsr.ch [152.96.52.150]) by core3.amsl.com (Postfix) with ESMTP id 8803428C4A5 for ; Tue, 22 Apr 2008 11:03:10 -0700 (PDT) Received: from [10.10.0.1] (satay.strongsec.com [10.10.0.1]) by strongswan.org (Postfix) with ESMTP id D831FEF973; Tue, 22 Apr 2008 20:03:12 +0200 (CEST) Message-ID: <480E2860.9010308@strongswan.org> Date: Tue, 22 Apr 2008 20:03:12 +0200 From: Andreas Steffen User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, we also advocate the creation of an IPsec maintainance and extensions WG because we would like to have a constructive feedback on our recent IKEv2 mediation extension proposal (draft-brunner-ikev2-mediation) which handles those NAT Traversal cases where both endpoints are hidden behind Network Address Port Translation (NAPT) devices and therefore need a mediation service in order to establish a peer-to-peer IPsec connection. Best regards Andreas ====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 11:31:54 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09763A6DD0; Tue, 22 Apr 2008 11:31:54 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9A43A6D4F for ; Tue, 22 Apr 2008 11:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ludeOhz25gAG for ; Tue, 22 Apr 2008 11:31:51 -0700 (PDT) Received: from omzesmtp03a.verizonbusiness.com (omzesmtp03a.verizonbusiness.com [199.249.25.201]) by core3.amsl.com (Postfix) with ESMTP id B26783A6C70 for ; Tue, 22 Apr 2008 11:31:03 -0700 (PDT) Received: from pmismtp06.wcomnet.com ([166.37.158.166]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0JZQ0004IORXPA00@firewall.verizonbusiness.com> for ipsec@ietf.org; Tue, 22 Apr 2008 18:31:09 +0000 (GMT) Received: from pmismtp06.wcomnet.com ([127.0.0.1]) by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JZQ007MGORXID@pmismtp06.mcilink.com> for ipsec@ietf.org; Tue, 22 Apr 2008 18:31:09 +0000 (GMT) Received: from ASHSRV140.mcilink.com ([153.39.68.166]) by pmismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JZQ0079JORXOI@pmismtp06.mcilink.com> for ipsec@ietf.org; Tue, 22 Apr 2008 18:31:09 +0000 (GMT) Received: from ASHEVS011.mcilink.com ([153.39.69.138]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Apr 2008 18:31:07 +0000 Date: Tue, 22 Apr 2008 18:31:06 +0000 From: "Snyder, Guy" In-reply-to: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> To: Pasi.Eronen@nokia.com, ipsec@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: [IPsec] IPsec maintenance/extensions WG? Thread-index: AcikVzJFP8ywxWHKStKk3V5BcOU+lQATX0pg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> X-OriginalArrivalTime: 22 Apr 2008 18:31:07.0881 (UTC) FILETIME=[07E21590:01C8A4A7] Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Pasi.Eronen@nokia.com > Sent: Tuesday, April 22, 2008 5:00 AM > To: ipsec@ietf.org > Subject: [IPsec] IPsec maintenance/extensions WG? > > Hi, > > During the Philadelphia meeting, several folks expressed interest > in forming a working group for IPsec maintenance and extensions. > > Since IKEv2 is included in, for example, various US Government IPv6 > profiles, we'll probably see a number of new IKEv2 implementations > during the next couple of years. Having a working group would > provide a forum for discussing implementation questions, and > ensuring that results from, e.g., interoperability workshops are > actually written down in the specifications (which didn't happen > for IKEv1). I agree that it would be good to have a group to discuss issues raised from our bakeoffs. We also have run into issues in our IKEv2 testing that probably need further definition and/or clarification. > While some maintenance work has already been done (RFC 4718, > draft-hoffman-ikev2bis), and the ipsec mailing list still exists, > finding those has been difficult for non-insiders. Also, the > maintenance work has so far focused largely on the "remote access > VPN" (client-to-gateway) use case, which exercises slightly > different parts of the specs than host-to-host and > gateway-to-gateway IPsec. I also feel that a WG would provide more focus on current drafts that otherwise would not get widespread attention. > At the same time, there has been interest in standardizing small > improvements and extensions that were not included in the IKEv2 > base specifications (just search for drafts containing "-ikev2-" > or "-ipsec-"). Some of those extensions could benefit from wider > participation that having a working group would bring. > > To actually form a WG, we would need to agree on the initial > charter scope, and have enough people to work on all the items > we decide to take on. > > My current thinking is that the WG charter should describe a small > number of specific work items and reasonable timelines for > completing them, as opposed to including everything related to > IPsec and planning to have the WG around forever. I agree on the small number of current work items. Although we don't want to stifle creativity, we also do not want everyone to jump on a bandwagon of creating drafts. > To get some discussion started, please send your opinions on > whether having a WG would be a good idea, your thoughts on what > the charter should look like, and what you'd consider to be the > most important work items. Hopefully we will have some good feedback for this potential WG from the upcoming bakeoff for IKEv2. --Guy Snyder, VPN Programs Manager --ICSA Labs _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 12:52:58 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C04D3A68BE; Tue, 22 Apr 2008 12:52:58 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 595763A68BE for ; Tue, 22 Apr 2008 12:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX7la3r9HMGF for ; Tue, 22 Apr 2008 12:52:52 -0700 (PDT) Received: from mail.ca.certicom.com (mail.ca.certicom.com [38.113.160.197]) by core3.amsl.com (Postfix) with SMTP id 427BC3A6A62 for ; Tue, 22 Apr 2008 12:52:52 -0700 (PDT) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 44B931002912C for ; Tue, 22 Apr 2008 15:52:57 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkE4+xc2egSC for ; Tue, 22 Apr 2008 15:52:52 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP for ; Tue, 22 Apr 2008 15:52:52 -0400 (EDT) Received: from [10.0.8.48] ([10.0.8.48]) by domino1.certicom.com (Lotus Domino Release 7.0.2FP2 HF177) with ESMTP id 2008042215510710-27325 ; Tue, 22 Apr 2008 15:51:07 -0400 Message-ID: <480E4282.1040403@certicom.com> Date: Tue, 22 Apr 2008 15:54:42 -0400 From: Chinh Nguyen User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ipsec@ietf.org References: <200804221721.m3MHLMTp001727@faith.austin.ibm.com> In-Reply-To: <200804221721.m3MHLMTp001727@faith.austin.ibm.com> X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/22/2008 03:51:07 PM, Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/22/2008 03:51:07 PM, Serialize complete at 04/22/2008 03:51:07 PM Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Joy Latten wrote: > This may be a moot topic, if so please ignore, but are there any > plans to improve/extend pfkey for ikev2? Just wondering. :-) There are certainly a number of pfkey issues. For example, linux & bsd have slightly different implementation of pfkey. Now, this is a impl. issue not a standards issue but it highlights the fact that people are wishing to extend pfkey. These extensions typically never made it past draft, and have since expired. A second one is that if you were to attempt to convert an "IKEv2" child SA to pfkey format, you will find that there are no IANA numbers assigned to the ipsec side for ENCR_NULL_AUTH_AES_GMAC and AUTH_AES_[128|192|256]_GMAC (http://www.iana.org/assignments/ikev2-parameters). This assumes that pfkey is using the values from http://www.iana.org/assignments/isakmp-registry, which is true for linux. Chinh -- http://www.certicom.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 12:59:33 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4242B3A67B2; Tue, 22 Apr 2008 12:59:33 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6663A69FD for ; Tue, 22 Apr 2008 12:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8KEZTAsb0Qa for ; Tue, 22 Apr 2008 12:59:31 -0700 (PDT) Received: from mail.ca.certicom.com (mail.ca.certicom.com [38.113.160.197]) by core3.amsl.com (Postfix) with SMTP id 3266F3A677D for ; Tue, 22 Apr 2008 12:59:31 -0700 (PDT) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 37C1A1002912C for ; Tue, 22 Apr 2008 15:59:37 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2OAa2UDimlg for ; Tue, 22 Apr 2008 15:59:31 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP for ; Tue, 22 Apr 2008 15:59:31 -0400 (EDT) Received: from [10.0.8.48] ([10.0.8.48]) by domino1.certicom.com (Lotus Domino Release 7.0.2FP2 HF177) with ESMTP id 2008042215574599-27358 ; Tue, 22 Apr 2008 15:57:45 -0400 Message-ID: <480E4411.4070902@certicom.com> Date: Tue, 22 Apr 2008 16:01:21 -0400 From: Chinh Nguyen User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ipsec@ietf.org References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/22/2008 03:57:45 PM, Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/22/2008 03:57:46 PM, Serialize complete at 04/22/2008 03:57:46 PM Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I would certainly like clarifications on IKEv2 Transport Mode negotiation when one or both peers are behind NAT. There are no discussions in the IKEv2 standard or clarification. I do not think it can be done using simple selectors (i.e., TSi = peerA, TSr = peerB) but am willing to be corrected. I have sent to this list a way to do Transport Mode behind NAT using complex selectors but there could be a more elegant/obvious way. Regards, Chinh -- http://www.certicom.com Pasi.Eronen@nokia.com wrote: > Hi, > > During the Philadelphia meeting, several folks expressed interest > in forming a working group for IPsec maintenance and extensions. > > Since IKEv2 is included in, for example, various US Government IPv6 > profiles, we'll probably see a number of new IKEv2 implementations > during the next couple of years. Having a working group would > provide a forum for discussing implementation questions, and > ensuring that results from, e.g., interoperability workshops are > actually written down in the specifications (which didn't happen > for IKEv1). _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 13:30:34 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110E23A6B21; Tue, 22 Apr 2008 13:30:34 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED143A6B21 for ; Tue, 22 Apr 2008 13:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAhD5BmXHyuY for ; Tue, 22 Apr 2008 13:30:26 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id C253E28C156 for ; Tue, 22 Apr 2008 13:30:25 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3MKUVEj008990 for ; Tue, 22 Apr 2008 20:30:31 GMT Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.174.48]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m3MKUVgX060601 for ; Tue, 22 Apr 2008 16:30:31 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m3MKFYak015645; Tue, 22 Apr 2008 16:15:34 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m3MKFXRL015644; Tue, 22 Apr 2008 16:15:33 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Tue, 22 Apr 2008 16:15:33 -0400 From: Dan McDonald To: Chinh Nguyen Message-ID: <20080422201533.GG15188@kebe.east.sun.com> References: <200804221721.m3MHLMTp001727@faith.austin.ibm.com> <480E4282.1040403@certicom.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <480E4282.1040403@certicom.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Tue, Apr 22, 2008 at 03:54:42PM -0400, Chinh Nguyen wrote: > Joy Latten wrote: > > > This may be a moot topic, if so please ignore, but are there any > > plans to improve/extend pfkey for ikev2? Just wondering. :-) There's been prodding by some to produce PF_KEYv3. I've had no cycles, but I do have interest in helping produce a 430x-happy PF_KEYv3. > There are certainly a number of pfkey issues. For example, linux & bsd > have slightly different implementation of pfkey. Now, this is a impl. > issue not a standards issue but it highlights the fact that people are > wishing to extend pfkey. These extensions typically never made it past > draft, and have since expired. Yes - and the BSD and Linux extensions (based on the KAME/WIDE work) are very VERY different than, say, the ones produced in what is now OpenSolaris. When we opened up OpenSolaris, I blogged about it here: http://blogs.sun.com/danmcd/entry/pf_key_in_solaris_or Part of that divergence is my fault - when I co-wrote 2367, I was fighting internal IPsec battles at Sun (old-timers on this list know EXACTLY what I'm talking about). I didn't consider the needs of an actual KMd writer, and I was resistant to anything that to my mind would favor IKEv1 vs. another future KM protocol. I'd like to think anyone could build JFK, IKEv2, or anything else on top of PF_KEY, as that was the point of PF_KEY in the first place. 2367 as published had several weaknesses, which various extension efforts fixed in their own way. > A second one is that if you were to attempt to convert an "IKEv2" child > SA to pfkey format, you will find that there are no IANA numbers > assigned to the ipsec side for ENCR_NULL_AUTH_AES_GMAC and > AUTH_AES_[128|192|256]_GMAC > (http://www.iana.org/assignments/ikev2-parameters). This assumes that > pfkey is using the values from > http://www.iana.org/assignments/isakmp-registry, which is true for linux. And what's worse --> IKEv2/430x uses slightly different values than IKEv1/240x for algorithms like the SHA-2 family. Check this out: From http://www.iana.org/assignments/ikev2-parameters -- we have: For Transform Type 3 (Integrity Algorithm), defined Transform IDs are: Number Name Reference ------ --------------------------------- --------- 0 NONE [RFC4306] 1 AUTH_HMAC_MD5_96 [RFC2403] 2 AUTH_HMAC_SHA1_96 [RFC2404] 3 AUTH_DES_MAC [RFC4306] 4 AUTH_KPDK_MD5 [RFC1826] 5 AUTH_AES_XCBC_96 [RFC3566] 6 AUTH_HMAC_MD5_128 [RFC4595] 7 AUTH_HMAC_SHA1_160 [RFC4595] 8 AUTH_AES_CMAC_96 [RFC4494] 9 AUTH_AES_128_GMAC [RFC4543] 10 AUTH_AES_192_GMAC [RFC4543] 11 AUTH_AES_256_GMAC [RFC4543] 12 AUTH_HMAC_SHA2_256_128 [RFC4868] 13 AUTH_HMAC_SHA2_384_192 [RFC4868] 14 AUTH_HMAC_SHA2_512_256 [RFC4868] But from RFC 4868 we have: For IKE Phase 2 negotiations, IANA has assigned the following authentication algorithm identifiers: HMAC-SHA2-256: 5 HMAC-SHA2-384: 6 HMAC-SHA2-512: 7 So it's DIFFERENT between IKEv1 and IKEv2, and we really would like to keep PF_KEY independent, yet optimized. This used to be simple, now it's quite hard. OpenSolaris uses 5-7 for SHA2 in PF_KEY, but when we switch to a fully 430x-happy IPsec, we need to consider what to do. There are two distinct PF_KEY lists too, the original one -- pf_key@inner.net (Bcc:ing the keeper of that list), and one on vpnc.org. I think PF_KEY falls outside this or any followup IETF group -- after all the IETF isn't supposed to do APIs last time I checked. OTOH, there's plenty of fertile ground for feedback into PF_KEYv3. As I'm learning the hard way how much two implementations have diverged (I'm bringing up racoon2 on OpenSolaris) - I believe there's an opportunity to get it right. I just hope it doesn't get bloated beyond usability. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 13:34:02 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF37B3A6EA1; Tue, 22 Apr 2008 13:34:01 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B070C28C428 for ; Tue, 22 Apr 2008 13:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iz-tQ3dN6kTX for ; Tue, 22 Apr 2008 13:33:52 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by core3.amsl.com (Postfix) with ESMTP id 9C88528C468 for ; Tue, 22 Apr 2008 13:32:00 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3MKW62Q006193 for ; Tue, 22 Apr 2008 20:32:06 GMT Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.174.48]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m3MKW6ja061116 for ; Tue, 22 Apr 2008 16:32:06 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m3MKH46i015654; Tue, 22 Apr 2008 16:17:05 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m3MKH4qa015653; Tue, 22 Apr 2008 16:17:04 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Tue, 22 Apr 2008 16:17:04 -0400 From: Dan McDonald To: Chinh Nguyen Message-ID: <20080422201704.GH15188@kebe.east.sun.com> References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> <480E4411.4070902@certicom.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <480E4411.4070902@certicom.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Tue, Apr 22, 2008 at 04:01:21PM -0400, Chinh Nguyen wrote: > Hi, > > I would certainly like clarifications on IKEv2 Transport Mode > negotiation when one or both peers are behind NAT. There are no > discussions in the IKEv2 standard or clarification. I do not think it > can be done using simple selectors (i.e., TSi = peerA, TSr = peerB) but > am willing to be corrected. If one peer is behind NAT, the concept of NAT-OA should take care of that -- at least that's how it works in IKEv1. (So long as the initiator is behind the NAT.) As for both being behind NAT, there's a strongswan guy who may have a solution there. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 14:22:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2353A6F58; Tue, 22 Apr 2008 14:22:50 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2AB3A6F02 for ; Tue, 22 Apr 2008 14:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kwiKUmChJ1Q for ; Tue, 22 Apr 2008 14:22:49 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 42BD43A6F61 for ; Tue, 22 Apr 2008 14:21:22 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.131.248]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JoPva-0004jU-6K; Tue, 22 Apr 2008 17:21:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> Date: Tue, 22 Apr 2008 16:04:29 -0400 To: From: Stephen Kent Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi, I agree that there could be benefit to a WG that exists to coordinate responses to questions and to clarify the IPsec/IKE specs. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 14:40:45 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C905A3A6E5E; Tue, 22 Apr 2008 14:40:45 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF2FF3A6EE4 for ; Tue, 22 Apr 2008 14:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdxRlSnueMyV for ; Tue, 22 Apr 2008 14:40:43 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 04FF73A69B1 for ; Tue, 22 Apr 2008 14:40:42 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3MLembG025686 for ; Tue, 22 Apr 2008 21:40:48 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m3MLemMW014489 for ; Tue, 22 Apr 2008 17:40:48 -0400 (EDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m3MLTXp1012978 for ; Tue, 22 Apr 2008 17:29:33 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m3MLTWT7012977 for ipsec@ietf.org; Tue, 22 Apr 2008 17:29:32 -0400 (EDT) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Tue, 22 Apr 2008 17:29:32 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20080422212932.GA12955@sun.com> References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org After my PF_KEY reply, I did forget to say that... On Tue, Apr 22, 2008 at 04:04:29PM -0400, Stephen Kent wrote: > Pasi, > > I agree that there could be benefit to a WG that exists to coordinate > responses to questions and to clarify the IPsec/IKE specs. I agree with Pasi, Steve, and others who've said the above. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 14:51:49 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0BCB3A6E51; Tue, 22 Apr 2008 14:51:49 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B67F3A6E1B for ; Tue, 22 Apr 2008 14:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FipCmDg7s0bL for ; Tue, 22 Apr 2008 14:51:47 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 902A43A6CE2 for ; Tue, 22 Apr 2008 14:51:47 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.131.248]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JoQP2-0008Cx-4O; Tue, 22 Apr 2008 17:51:52 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20080422163043.GH21850@arwen.velv.hr> References: <20080422163043.GH21850@arwen.velv.hr> Date: Tue, 22 Apr 2008 17:40:18 -0400 To: Ana Kukec From: Stephen Kent Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 6:30 PM +0200 4/22/08, Ana Kukec wrote: >Hi all, > >I support the idea of having IPSec maintainance/extensions WG. As you were >talking about extensions, i wonder if the CGA extension for IKEv2 could be >one of possible work items? > >CGA [rfc3972] enabled IKEv2 could be extended to provide security without >any pre-deployed and/or centralized trust infrastructure based on IKEv2 >peer authentication via IPv6 Cryptographically Generated Addresses. In >that case, we would need IKEv2 extensions in order to support IKEv2 >authentication based on CGA address-proof-of-ownership and PAD extensions >(primarily) to ensure a secure initial CGA authentication. > >I am also wondering about the MOBIKE extensions, as something similar >could be done also for MOBIKE. > >Kind regards, >Ana > Ana, Can you describe how the proposed CGA approach is better than the ongoing work in BTNS. My understanding of the CGA proposal is that it would allow each peer to verify that the other was using a randomly asserted IPv6 address, as asserted in IPv6 packet headers. This does not strike me as useful for access control, beyond what BTNS could do. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 16:06:57 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B6B3A6A2E; Tue, 22 Apr 2008 16:06:57 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAFC13A6878 for ; Tue, 22 Apr 2008 16:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YnF4oY4otMx for ; Tue, 22 Apr 2008 16:06:54 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by core3.amsl.com (Postfix) with ESMTP id 52FE53A6A2E for ; Tue, 22 Apr 2008 16:06:54 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i26so1953137wxd.31 for ; Tue, 22 Apr 2008 16:07:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=5NM1fGTG77QqlecsfyKwBFtwIGZdyj27dIDHvAmDvgg=; b=KUyZS7XMCiaisBYsBLbMpCoPFuy/Mk5GviawXZhQpGGJI/b9CIaIN1TkLiorA34AIJ2LsbDA12eLv9+MyDROI903P6BZwtdMPUZm4dgZWbp1sMF4XMT3hAjBpiN/yiljrPKOHIXJ4cXqP4tayP/KZTHebE819QrzKMYQ+9NCOek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Pp73tUQtwXkOzuL3ZnaopKn0280D87OJ5D7AjNeQKlsiBNiYBukZThyQ/KVZOlDslfMH8k1+ejnL2nyoJAfEp9Ks7LyBQ42gPj2nhDfyRfAD2XtCjhqET7S5CxzapWCUGWYkpDoEQ2fzlx4AS3xSuXeSBwpI3cr/4ft/cqwkFCk= Received: by 10.100.12.1 with SMTP id 1mr1439850anl.35.1208905619801; Tue, 22 Apr 2008 16:06:59 -0700 (PDT) Received: by 10.100.202.10 with HTTP; Tue, 22 Apr 2008 16:06:59 -0700 (PDT) Message-ID: Date: Tue, 22 Apr 2008 16:06:59 -0700 From: "fan zhao" To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, smfaccin@marvell.com, adamle@marvell.com Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Pasi, I fully support this idea. IMHO, besides a few topics listed already, the new WG can also work on solving issues and supporting specific scenarios arising when IPSec/IKE is deployed, e.g. by other standard fora, as well as developing extensions for optimizing the use of IPSec/IKE. Such work items should be specific and expected to be completed in a reasonable time frame. One work item that IMHO can be picked up by the WG is to define an IKEv2 payload that can be used by an IPSec gateway to indicate to an IPSec remote access client the "right" IPSec gateway to be connected with, during the IPSec SA establishment procedure. This is useful in case that there are multiple IPsec gateways deployed for pursposes, such as load balancing. Best regards, fan On Tue, Apr 22, 2008 at 1:59 AM, wrote: > Hi, > > During the Philadelphia meeting, several folks expressed interest > in forming a working group for IPsec maintenance and extensions. > > Since IKEv2 is included in, for example, various US Government IPv6 > profiles, we'll probably see a number of new IKEv2 implementations > during the next couple of years. Having a working group would > provide a forum for discussing implementation questions, and > ensuring that results from, e.g., interoperability workshops are > actually written down in the specifications (which didn't happen > for IKEv1). > > While some maintenance work has already been done (RFC 4718, > draft-hoffman-ikev2bis), and the ipsec mailing list still exists, > finding those has been difficult for non-insiders. Also, the > maintenance work has so far focused largely on the "remote access > VPN" (client-to-gateway) use case, which exercises slightly > different parts of the specs than host-to-host and > gateway-to-gateway IPsec. > > At the same time, there has been interest in standardizing small > improvements and extensions that were not included in the IKEv2 > base specifications (just search for drafts containing "-ikev2-" > or "-ipsec-"). Some of those extensions could benefit from wider > participation that having a working group would bring. > > To actually form a WG, we would need to agree on the initial > charter scope, and have enough people to work on all the items > we decide to take on. > > My current thinking is that the WG charter should describe a small > number of specific work items and reasonable timelines for > completing them, as opposed to including everything related to > IPsec and planning to have the WG around forever. > > To get some discussion started, please send your opinions on > whether having a WG would be a good idea, your thoughts on what > the charter should look like, and what you'd consider to be the > most important work items. > > (If you've talked with me about this topic earlier, please > still post your opinions on the list for others to see.) > > Best regards, > Pasi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 22 23:53:20 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 334543A6B23; Tue, 22 Apr 2008 23:53:20 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289C63A6C77 for ; Tue, 22 Apr 2008 23:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.812 X-Spam-Level: X-Spam-Status: No, score=-0.812 tagged_above=-999 required=5 tests=[AWL=1.454, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PnMiKOdvtdb for ; Tue, 22 Apr 2008 23:53:14 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id C5C8A3A6C9F for ; Tue, 22 Apr 2008 23:53:14 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9133B10224084; Tue, 22 Apr 2008 23:53:20 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 22 Apr 2008 23:53:20 -0700 (PDT) Message-ID: <7e21c27f6eac79cc3bbe38ac47b9682e.squirrel@www.trepanning.net> In-Reply-To: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> Date: Tue, 22 Apr 2008 23:53:20 -0700 (PDT) From: "Dan Harkins" To: Pasi.Eronen@nokia.com User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Pasi, On Tue, April 22, 2008 1:59 am, Pasi.Eronen@nokia.com wrote: > Hi, > > During the Philadelphia meeting, several folks expressed interest > in forming a working group for IPsec maintenance and extensions. > > Since IKEv2 is included in, for example, various US Government IPv6 > profiles, we'll probably see a number of new IKEv2 implementations > during the next couple of years. Having a working group would > provide a forum for discussing implementation questions, and > ensuring that results from, e.g., interoperability workshops are > actually written down in the specifications (which didn't happen > for IKEv1). Well it wasn't for lack of trying! If you recall the draft that became IKEv1 was limited to only 7 revisions due to a desire to send all IPsec- related drafts out to the RFC editor en masse. Everyone knew it still needed work and the feedback from the bakeoffs was good but there was a time limit. (Contrast this with IKEv2 which went through 17 revisions, had another draft to "clarify" it that went through 9, and now we're on the 3rd rev of an IKEv2-bis draft). If there are feedback from IKEv2 bakeoffs it would seem worthwhile to have a forum to ensure that it gets into the -bis work. regards, Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 23 00:42:46 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9733A6C81; Wed, 23 Apr 2008 00:42:46 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D49D3A6975 for ; Wed, 23 Apr 2008 00:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4lAk2MNeyNy for ; Wed, 23 Apr 2008 00:42:44 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by core3.amsl.com (Postfix) with ESMTP id 4490E3A6C53 for ; Wed, 23 Apr 2008 00:42:44 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so3352620pyg.24 for ; Wed, 23 Apr 2008 00:42:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=CoUIUW63mdDRiBc9+HCCejOwAIrU8FdTsyP+NvRzZg4=; b=blRvzg8r/KbOWfFdtjFqwG8QAiJ2c0tQmxGc/8akLdIEh33R3OAE06JoVwRjLhIfkH6ZTplYEz1XUyQz1cdMMQJEeLX0DEaIqMf0IzddkyZ5SCA8qoqpCTzdHp2T1wtvQLMkbomYvQ7TMedB4jqCiglYqyblnUDiPCCVuVg+Es0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ndeL11elt81jG63QoQmXhrLfN2910Yw/pld80bCoCPefCpvFluLNrQrDTPpaDMkIQa17moxTmsaPyXgodxCGYo00qcSB8WGF5slev32SiY81GmsHn5fywnMcbu1EJaFSL+T8nqcmQNrE2679zYme1MLnrxh0WHof/w1nApLas+s= Received: by 10.35.96.11 with SMTP id y11mr2155345pyl.52.1208936569796; Wed, 23 Apr 2008 00:42:49 -0700 (PDT) Received: by 10.35.37.3 with HTTP; Wed, 23 Apr 2008 00:42:49 -0700 (PDT) Message-ID: <850df0c40804230042o2dfe5d9i45200f0b952fe496@mail.gmail.com> Date: Wed, 23 Apr 2008 09:42:49 +0200 From: "balaji raghavan" To: "Dan McDonald" In-Reply-To: <20080422201533.GG15188@kebe.east.sun.com> MIME-Version: 1.0 Content-Disposition: inline References: <200804221721.m3MHLMTp001727@faith.austin.ibm.com> <480E4282.1040403@certicom.com> <20080422201533.GG15188@kebe.east.sun.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balaji.raghavan.t@gmail.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org To flog the dead(?) horse once more ... :) The effects of ESP(v3) and AH updates( RFC 4302 and RFC 4303) , for example ESN and TFC enhancements on Pfkey have to be also considered .. Though RFC 4718 does clarify the effects of these enhancements on IKEv2 operation it does leave out pfkey related matters. Although i do agree that the pfkey API specification does fall out of the scope of IETF, for the sake of interop doesn't it atleast warrant mention in the WG forum ? -Regards Balaji On Tue, Apr 22, 2008 at 10:15 PM, Dan McDonald wrote: > On Tue, Apr 22, 2008 at 03:54:42PM -0400, Chinh Nguyen wrote: > > Joy Latten wrote: > > > > > This may be a moot topic, if so please ignore, but are there any > > > plans to improve/extend pfkey for ikev2? Just wondering. :-) > > There's been prodding by some to produce PF_KEYv3. I've had no cycles, but I > do have interest in helping produce a 430x-happy PF_KEYv3. > > > > There are certainly a number of pfkey issues. For example, linux & bsd > > have slightly different implementation of pfkey. Now, this is a impl. > > issue not a standards issue but it highlights the fact that people are > > wishing to extend pfkey. These extensions typically never made it past > > draft, and have since expired. > > Yes - and the BSD and Linux extensions (based on the KAME/WIDE work) are very > VERY different than, say, the ones produced in what is now OpenSolaris. When > we opened up OpenSolaris, I blogged about it here: > > http://blogs.sun.com/danmcd/entry/pf_key_in_solaris_or > > Part of that divergence is my fault - when I co-wrote 2367, I was fighting > internal IPsec battles at Sun (old-timers on this list know EXACTLY what I'm > talking about). I didn't consider the needs of an actual KMd writer, and I > was resistant to anything that to my mind would favor IKEv1 vs. another > future KM protocol. I'd like to think anyone could build JFK, IKEv2, or > anything else on top of PF_KEY, as that was the point of PF_KEY in the first > place. 2367 as published had several weaknesses, which various extension > efforts fixed in their own way. > > > > A second one is that if you were to attempt to convert an "IKEv2" child > > SA to pfkey format, you will find that there are no IANA numbers > > assigned to the ipsec side for ENCR_NULL_AUTH_AES_GMAC and > > AUTH_AES_[128|192|256]_GMAC > > (http://www.iana.org/assignments/ikev2-parameters). This assumes that > > pfkey is using the values from > > http://www.iana.org/assignments/isakmp-registry, which is true for linux. > > And what's worse --> IKEv2/430x uses slightly different values than > IKEv1/240x for algorithms like the SHA-2 family. Check this out: > > From http://www.iana.org/assignments/ikev2-parameters -- we have: > > For Transform Type 3 (Integrity Algorithm), > defined Transform IDs are: > Number Name Reference > ------ --------------------------------- --------- > 0 NONE [RFC4306] > 1 AUTH_HMAC_MD5_96 [RFC2403] > 2 AUTH_HMAC_SHA1_96 [RFC2404] > 3 AUTH_DES_MAC [RFC4306] > 4 AUTH_KPDK_MD5 [RFC1826] > 5 AUTH_AES_XCBC_96 [RFC3566] > 6 AUTH_HMAC_MD5_128 [RFC4595] > 7 AUTH_HMAC_SHA1_160 [RFC4595] > 8 AUTH_AES_CMAC_96 [RFC4494] > 9 AUTH_AES_128_GMAC [RFC4543] > 10 AUTH_AES_192_GMAC [RFC4543] > 11 AUTH_AES_256_GMAC [RFC4543] > 12 AUTH_HMAC_SHA2_256_128 [RFC4868] > 13 AUTH_HMAC_SHA2_384_192 [RFC4868] > 14 AUTH_HMAC_SHA2_512_256 [RFC4868] > > But from RFC 4868 we have: > > For IKE Phase 2 negotiations, IANA has assigned the following > authentication algorithm identifiers: > > HMAC-SHA2-256: 5 > > HMAC-SHA2-384: 6 > > HMAC-SHA2-512: 7 > > > So it's DIFFERENT between IKEv1 and IKEv2, and we really would like to keep > PF_KEY independent, yet optimized. This used to be simple, now it's quite > hard. OpenSolaris uses 5-7 for SHA2 in PF_KEY, but when we switch to a fully > 430x-happy IPsec, we need to consider what to do. > > There are two distinct PF_KEY lists too, the original one -- > pf_key@inner.net (Bcc:ing the keeper of that list), and one on vpnc.org. > > > I think PF_KEY falls outside this or any followup IETF group -- after all the > IETF isn't supposed to do APIs last time I checked. OTOH, there's plenty of > fertile ground for feedback into PF_KEYv3. As I'm learning the hard way how > much two implementations have diverged (I'm bringing up racoon2 on > OpenSolaris) - I believe there's an opportunity to get it right. I just hope > it doesn't get bloated beyond usability. > > Dan > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 23 02:41:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83C733A6C81; Wed, 23 Apr 2008 02:41:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6AE28C275 for ; Wed, 23 Apr 2008 02:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.587 X-Spam-Level: X-Spam-Status: No, score=-0.587 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNS-YI6p+P6Q for ; Wed, 23 Apr 2008 02:41:23 -0700 (PDT) Received: from arwen.velv.hr (arwen.velv.hr [193.198.63.3]) by core3.amsl.com (Postfix) with ESMTP id DE54C3A6C81 for ; Wed, 23 Apr 2008 02:40:49 -0700 (PDT) Received: from localhost (localhost.velv.hr [127.0.0.1]) by arwen.velv.hr (Postfix) with ESMTP id F0E3942BB; Wed, 23 Apr 2008 11:40:33 +0200 (CEST) Received: from arwen.velv.hr ([127.0.0.1]) by localhost (arwen [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27489-10; Wed, 23 Apr 2008 11:40:30 +0200 (CEST) Received: by arwen.velv.hr (Postfix, from userid 1790) id BD84C42BE; Wed, 23 Apr 2008 11:40:30 +0200 (CEST) Date: Wed, 23 Apr 2008 11:40:30 +0200 From: Ana Kukec To: Stephen Kent Message-ID: <20080423094030.GA28382@arwen.velv.hr> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at vels.hr Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org He Steve, Stephen Kent wrote: > > Can you describe how the proposed CGA approach is better than the > ongoing work in BTNS. My understanding of the CGA proposal is that it > would allow each peer to verify that the other was using a randomly > asserted IPv6 address, as asserted in IPv6 packet headers. This does > not strike me as useful for access control, beyond what BTNS could do. The main disadvantage of BTNS over CGA + IKEv2 is that BTNS lacks for a way to avoid a leap of faith. BTNS takes benefit from the lack of authentication, contrary to CGA + IKEv2. The idea of CGA + IKEv2 is to ensure secure initial authentication, eg. a way to avoid a leap of faith. Ana _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 23 03:03:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28ABC28C2DF; Wed, 23 Apr 2008 03:03:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D967728C2E9 for ; Wed, 23 Apr 2008 03:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0dLIOdIPx22 for ; Wed, 23 Apr 2008 03:03:21 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id AF35028C163 for ; Wed, 23 Apr 2008 03:03:20 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 93EDA1987F2; Wed, 23 Apr 2008 13:03:25 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 4705D198713; Wed, 23 Apr 2008 13:03:22 +0300 (EEST) Message-ID: <480F0968.7000803@piuha.net> Date: Wed, 23 Apr 2008 12:03:20 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I support the idea of a maintenance WG for IPsec and related specifications. There are issues that we need to clarify. In some of the recent specs in particular, and I think there's a window of opportunity to affect what implementations actually do. Lets act and keep our specs as up to date as possible. We could do this without a WG, too, but I think we could gather more eyes to look at the clarifications, more energy, and be more open by having a WG. Having said that, I think the charter needs to be rather tight and the chairs be chosen appropriately so that they can prevent this from becoming a fun discussion club that lasts forever or something that starts to develop many unnecessary extensions. Jari _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 23 03:33:19 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14FED3A6928; Wed, 23 Apr 2008 03:33:19 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF9C13A6928 for ; Wed, 23 Apr 2008 03:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXYUaVqBdir9 for ; Wed, 23 Apr 2008 03:33:16 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dyn32-54.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8CA953A6A9B for ; Wed, 23 Apr 2008 03:33:16 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 61840294009; Wed, 23 Apr 2008 13:33:21 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B02D6294001 for ; Wed, 23 Apr 2008 13:33:20 +0300 (IDT) Received: from MBP.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m3NAXKfU025897 for ; Wed, 23 Apr 2008 13:33:20 +0300 (IDT) Message-Id: From: Yoav Nir To: ipsec@ietf.org In-Reply-To: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 23 Apr 2008 13:33:19 +0300 References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> X-Mailer: Apple Mail (2.919.2) Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi I agree with the many responders who have supported the creation of an IPsec extension/maintenance WG. I do not agree though, that such a group would be limited in time and scope. Paul's comparison with the PKIX WG is apt, and an IPsec WG will probably have to stick around as long as anybody's using IPsec. There have been some responses along the lines of "tight charter" and not being a place to "develop many unnecessary extenstions". The fact is that many of the extensions that have been added since RFC 4306 and several others which haven't are entirely necessary for a successful deployment of IKEv2, especially for remote access. The great number of drafts published with extensions are proof of that. I don't advocate accepting any draft that anybody wrote as a WG item, but I think there are legitimate concerns that need to be addressed by new standards, and they need to be discussed within a real WG, not the ghost mailing list of a defunct WG. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 23 06:01:56 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B11863A6A59; Wed, 23 Apr 2008 06:01:56 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A79C23A6A59 for ; Wed, 23 Apr 2008 06:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOfh0mf4gNBi for ; Wed, 23 Apr 2008 06:01:50 -0700 (PDT) Received: from mail.ca.certicom.com (mail.ca.certicom.com [38.113.160.197]) by core3.amsl.com (Postfix) with SMTP id 705383A6868 for ; Wed, 23 Apr 2008 06:01:50 -0700 (PDT) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 1970A1002912E for ; Wed, 23 Apr 2008 09:01:56 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwdOPM3-2tuB for ; Wed, 23 Apr 2008 09:01:54 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP for ; Wed, 23 Apr 2008 09:01:54 -0400 (EDT) Received: from [10.0.8.48] ([10.0.8.48]) by domino1.certicom.com (Lotus Domino Release 7.0.2FP2 HF177) with ESMTP id 2008042309000794-31252 ; Wed, 23 Apr 2008 09:00:07 -0400 Message-ID: <480F33AF.1020304@certicom.com> Date: Wed, 23 Apr 2008 09:03:43 -0400 From: Chinh Nguyen User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ipsec@ietf.org References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> <480E4411.4070902@certicom.com> <20080422201704.GH15188@kebe.east.sun.com> In-Reply-To: <20080422201704.GH15188@kebe.east.sun.com> X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/23/2008 09:00:07 AM, Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/23/2008 09:00:09 AM, Serialize complete at 04/23/2008 09:00:09 AM Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I don't want to hijack this thread for detailed discussion about other issues either so let me be brief. (Check out my message dated March 12, 2008). NAT-OA isn't an issue since it's merely for efficient incremental checksum (re-computation). The double NAT from strongSwan is to allow two NAT-ed peers to do IKE (presumably because there's no static NAT mapping on the NAT device so one of the peer can be reached.) My problem is that I do not see how you can negotiate simple traffic selectors that will match the actual data packets to be encrypted. Consider 1 single NAT-ted peer: X -- N[at] -- Y X can negotiate TSi=(X), TSr=(Y). This is no good for Y since it will be sending data addressed to N. That is, the security policy (SP) generated from selectors (X,Y) by Y will not match Y's outgoing packets with addresses (Y,N). Alternatively, X can negotiate TSi=(N), TSr=(Y) if it somehow knows the address of NAT device or perhaps it can send TSi=(*), TSr=(Y) and Y can reply with TSi=(N), TSr=(Y). This is good for Y but now, the selectors (N,Y) that are used by X will not match packets coming out of X, which have addresses (X,Y). Perhaps I'm missing something completely obvious here? Chinh -- http://www.certicom.com Dan McDonald wrote: > On Tue, Apr 22, 2008 at 04:01:21PM -0400, Chinh Nguyen wrote: >> Hi, >> >> I would certainly like clarifications on IKEv2 Transport Mode >> negotiation when one or both peers are behind NAT. There are no >> discussions in the IKEv2 standard or clarification. I do not think it >> can be done using simple selectors (i.e., TSi = peerA, TSr = peerB) but >> am willing to be corrected. > > If one peer is behind NAT, the concept of NAT-OA should take care of that -- > at least that's how it works in IKEv1. (So long as the initiator is behind > the NAT.) > > As for both being behind NAT, there's a strongswan guy who may have a > solution there. > > Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 23 06:03:36 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7113A6D97; Wed, 23 Apr 2008 06:03:35 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9552A3A6E25 for ; Wed, 23 Apr 2008 06:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyxWocBiHXwW for ; Wed, 23 Apr 2008 06:03:33 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 775D63A6CE9 for ; Wed, 23 Apr 2008 06:03:33 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.84.131.248]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JoedN-0007Cc-6E; Wed, 23 Apr 2008 09:03:38 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20080423094030.GA28382@arwen.velv.hr> References: <20080423094030.GA28382@arwen.velv.hr> Date: Wed, 23 Apr 2008 09:03:05 -0400 To: Ana Kukec From: Stephen Kent Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 11:40 AM +0200 4/23/08, Ana Kukec wrote: >He Steve, > >Stephen Kent wrote: >> >> Can you describe how the proposed CGA approach is better than the >> ongoing work in BTNS. My understanding of the CGA proposal is that it >> would allow each peer to verify that the other was using a randomly >> asserted IPv6 address, as asserted in IPv6 packet headers. This does >> not strike me as useful for access control, beyond what BTNS could do. > >The main disadvantage of BTNS over CGA + IKEv2 is that BTNS lacks for a >way to avoid a leap of faith. BTNS takes benefit from the lack of >authentication, contrary to CGA + IKEv2. The idea of CGA + IKEv2 is to >ensure secure initial authentication, eg. a way to avoid a leap of faith. > >Ana Ana, Thanks for the quick response. I'm afraid I am puzzled by your answer; let me explain. My understanding of the procedure is that first time a host uses a CGA in an IKE SA, the peer would not have any basis for mapping that CGA to another form of ID. Thus this seems like LoF to me. (Moreover, an initial motivation for CGAs was to enable a host to use different addresses, either serially over time or in parallel, e.g., to hinder traffic analysis. If one adopts that use model, a CGA is not a persistent ID, and thus would be worse than a BTNS-based LoF model.) Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 23 06:21:59 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0628A28C1B3; Wed, 23 Apr 2008 06:21:59 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D70F3A67FA for ; Wed, 23 Apr 2008 06:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIq7-Rb--kNz for ; Wed, 23 Apr 2008 06:21:57 -0700 (PDT) Received: from mail.kivinen.iki.fi (unknown [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 390143A6A60 for ; Wed, 23 Apr 2008 06:21:09 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id m3NDL6dA019907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Apr 2008 16:21:06 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id m3NDL4bT020696; Wed, 23 Apr 2008 16:21:04 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18447.14272.302880.595247@fireball.kivinen.iki.fi> Date: Wed, 23 Apr 2008 16:21:04 +0300 From: Tero Kivinen To: Toshihiko Tamura In-Reply-To: <20080422172935.997D.TAMURA.TOSHIHIKO@lab.ntt.co.jp> References: <20080422155817.9967.TAMURA.TOSHIHIKO@lab.ntt.co.jp> <20080422172935.997D.TAMURA.TOSHIHIKO@lab.ntt.co.jp> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 12 min Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] IKEv2 TS payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Toshihiko Tamura writes: > > TSi specifies the source address of traffic forwarded from (or the > > destination address of traffic forwarded to) the initiator of the > > CHILD_SA pair. ^^^^^^^^^^^^^^ > > So you mean, > the word "the initiator" in above sentence means the initiator > which initiate rekeying. I also agree to that. > > But there is a possibility to interpret the meaning of "the initiator" > as the initiator which has established initial SAs. > (I can say "original initiator"?) The 1.3 section is quite clear about this: 1.3. The CREATE_CHILD_SA Exchange ... Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this section the term "initiator" refers to the endpoint initiating this exchange. ... In cases where original IKE initiator is meant the term "original IKE initiator" or "original initiator of IKE_SA" is used (like in section 2.2, 2.6, 2.14 etc). One thing you might also note, that the values of the Traffic selector payloads sent in the rekey does NOT need to match the values used in the current SA which is being rekeyed. Preferrably they should be from the decorrelated policy entry which caused the original SA to be created, i.e. before narrowing happened in the original exchange. Of course the responder should narrow them down to selection that includes the original SAs traffic. Different implementations do different things there, and regardless what they do both ends should interoperate (i.e. even if initiator of the rekey selects the same traffic selectors that is currently in the SA, that should work, and if initiator of the rekey uses wider traffic selectors specified in its policy (which include the old traffic selectors), the responder of the rekey can either use new wider set of traffic selectors, or narrow them down to original set. Note, that both ends can even narrow it down to more than the original set included, which will cause new SA(s) to be created for those traffic that was excluded from the old SA (this might happen when the policy of the one end has changed, for example some parts of the original traffic selectors are not allowed after the policy change). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 23 06:44:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD6753A6E66; Wed, 23 Apr 2008 06:44:50 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A16F3A6E4B for ; Wed, 23 Apr 2008 06:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZrxWMJb3gOZ for ; Wed, 23 Apr 2008 06:44:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (unknown [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id D22123A6E80 for ; Wed, 23 Apr 2008 06:44:47 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id m3NDipeT029000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Apr 2008 16:44:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id m3NDio7Y012126; Wed, 23 Apr 2008 16:44:50 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18447.15698.475059.776140@fireball.kivinen.iki.fi> Date: Wed, 23 Apr 2008 16:44:50 +0300 From: Tero Kivinen To: Pasi.Eronen@nokia.com, ipsec@ietf.org In-Reply-To: <480F0968.7000803@piuha.net> References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> <480F0968.7000803@piuha.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > Having said that, I think the charter needs to be rather tight and the > chairs be chosen appropriately so that they can prevent this from > becoming a fun discussion club that lasts forever or something that > starts to develop many unnecessary extensions. I do support creating the IPsec maintenance/extensions WG, and one of the reasons I want it created is to LIMIT the number of unnecessary extensions and modifications to the IPsec. Current it is very easy to publish extension to the IPsec, you just make some stealth draft somewhere, and then submit it for publication. It gets few reviews, and then it is through as long as there is no real security problem or similar in the document. If we have working group for IPsec maintenance/extensions then all those extensions will come to there, and it can act as filter to see which one of them are really needed, and also force much wider review of the document. I myself find very much problems following individual submissions, so I do not usually even try. That is the reason I have not reviewed those IPsec extensions documents. If there is working group which adopts the document as work item then I know it is something I should pay attention to, it has been filtered out to be useful for me to read and comment. If on the other hand someone makes draft which gets bounced out from the IPsec maintenance/extensions WG because it was not seen important enough or usuful enough that should give much more feedback for authors and ADs and such whether such document is useful or not. So one of the roles I see that this working group should have is to provide filtering out IPsec related documents, and send them to correct destionation (i.e. either this WG, some other WG, to the trashcan, to BOF to create new WG etc). Because of this I think it should most likely be long lived working group, but its charter could be empty after initial set of extensions have been prosessed. It could also be used by the other WGs to come ask help, i.e. they could come in and present "this is how we felt we should be using IPsec in our protocol XXX", and then this WG could give input back and tell if that is ok, or completely wrong way, or whether more work is needed (and also help other WGs to do the work if needed). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 23 07:03:52 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD93B3A6F60; Wed, 23 Apr 2008 07:03:52 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53B1828C25E for ; Wed, 23 Apr 2008 07:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.746 X-Spam-Level: X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHfXC2VUdb+f for ; Wed, 23 Apr 2008 07:03:49 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id A72AC3A6F60 for ; Wed, 23 Apr 2008 07:03:20 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m3NE3JA7027054 for ; Wed, 23 Apr 2008 14:03:26 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m3NE3Jhd003446 for ; Wed, 23 Apr 2008 10:03:19 -0400 (EDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m3NDiUkj014044; Wed, 23 Apr 2008 09:44:30 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m3NDiKFA014043; Wed, 23 Apr 2008 09:44:20 -0400 (EDT) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Wed, 23 Apr 2008 09:44:20 -0400 From: Dan McDonald To: Chinh Nguyen Message-ID: <20080423134420.GB12955@sun.com> References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> <480E4411.4070902@certicom.com> <20080422201704.GH15188@kebe.east.sun.com> <480F33AF.1020304@certicom.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <480F33AF.1020304@certicom.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Wed, Apr 23, 2008 at 09:03:43AM -0400, Chinh Nguyen wrote: > Consider 1 single NAT-ted peer: > > X -- N[at] -- Y > > X can negotiate TSi=(X), TSr=(Y). This is no good for Y since it will be > sending data addressed to N. That is, the security policy (SP) generated > from selectors (X,Y) by Y will not match Y's outgoing packets with > addresses (Y,N). Y doesn't know about X save for NAT-OA - and as you point out, that only helps the checksums. Y talking to X is governed by Y's rules for talking with N. That's just how it works, welcome to the world of NAT. :-P > Alternatively, X can negotiate TSi=(N), TSr=(Y) if it somehow knows the > address of NAT device or perhaps it can send TSi=(*), TSr=(Y) and Y can > reply with TSi=(N), TSr=(Y). This is good for Y but now, the selectors > (N,Y) that are used by X will not match packets coming out of X, which > have addresses (X,Y). Y will see TSi(X), but knows, because of NAT-D/NAT-OA, that there's a NAT in betweeen and it must treat (X) as (N) for purposes of its local IPsec policy. > Perhaps I'm missing something completely obvious here? You're merely seeing that NATs are f*cked-up constructs that should all be burned into the ground. ;) Seriously though, a NAT effectively limits the amount of end-to-end communication that can occur between nodes. Y can only see N and act upon N. If you have, for example, a policy on Y that states a port-only policy, it gets even trickier. If you also have A, B, and C behind N, TS(X,p) may collide with TS(A,p) because N will treat those as TS(N,p). Ephemeral port selection on the behind-the-NAT clients combined with "unique SA" derivation (what 4301 calls PFP) usuall sorts these issues out. Because a NAT can have arbitrary nodes behind it, you cannot possibly map out transport mode selectors in a manner that will guarantee things to work. In these cases, the best approach is to use per-port selectors, combined with PFP/unique-SA policies. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 23 08:22:25 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E22913A6D63; Wed, 23 Apr 2008 08:22:25 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0181728C105 for ; Wed, 23 Apr 2008 08:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5r-+x2Hv9VH for ; Wed, 23 Apr 2008 08:22:24 -0700 (PDT) Received: from mail.ca.certicom.com (mail.ca.certicom.com [38.113.160.197]) by core3.amsl.com (Postfix) with SMTP id F25CB3A6DE3 for ; Wed, 23 Apr 2008 08:22:23 -0700 (PDT) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 5541910027FAC; Wed, 23 Apr 2008 11:22:29 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OWRL9k3unQ6; Wed, 23 Apr 2008 11:22:23 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP; Wed, 23 Apr 2008 11:22:23 -0400 (EDT) Received: from [10.0.8.48] ([10.0.8.48]) by domino1.certicom.com (Lotus Domino Release 7.0.2FP2 HF177) with ESMTP id 2008042311203698-32109 ; Wed, 23 Apr 2008 11:20:36 -0400 Message-ID: <480F549C.1030309@certicom.com> Date: Wed, 23 Apr 2008 11:24:12 -0400 From: Chinh Nguyen User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dan McDonald X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/23/2008 11:20:36 AM, Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/23/2008 11:20:38 AM, Serialize complete at 04/23/2008 11:20:38 AM Cc: ipsec@ietf.org Subject: [IPsec] Transport Mode and NAT [Was: IPsec maintenance/extensions WG?] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dan McDonald wrote: >> Consider 1 single NAT-ted peer: >> >> X -- N[at] -- Y >> >> X can negotiate TSi=(X), TSr=(Y). This is no good for Y since it will be >> sending data addressed to N. That is, the security policy (SP) generated >> from selectors (X,Y) by Y will not match Y's outgoing packets with >> addresses (Y,N). > > Y doesn't know about X save for NAT-OA - and as you point out, that only > helps the checksums. Y talking to X is governed by Y's rules for talking > with N. That's just how it works, welcome to the world of NAT. :-P > >> Alternatively, X can negotiate TSi=(N), TSr=(Y) if it somehow knows the >> address of NAT device or perhaps it can send TSi=(*), TSr=(Y) and Y can >> reply with TSi=(N), TSr=(Y). This is good for Y but now, the selectors >> (N,Y) that are used by X will not match packets coming out of X, which >> have addresses (X,Y). > > Y will see TSi(X), but knows, because of NAT-D/NAT-OA, that there's a NAT in > betweeen and it must treat (X) as (N) for purposes of its local IPsec policy. > I see the disconnect now. We have simple policies (address, port, proto) so they are mapped directly to TS, then the final TS is mapped into "ipsec policies" for packet processing. As such, I could not see how an "ipsec driver" on Y can use TS(X,Y) for traffic destined for N. Thus, X should not propose (X,Y). (And similarly, Y does not propose (N,Y) for X). What you are saying is that there may be extra policy processing/book-keeping for a particular peer. That the agreed-upon TS are not the whole story. Is this because 4301 in some ways supercedes 4306? Because I'm sure 4306 is reasonably clear on how TS should be used. For completeness, I would like to point out (from my old e-mail), that given the more general situation: X -- N1 -- N2 -- Y If X sends TSi(X,*) TSr(N2,*) and Y responds TSi(X,N1) TSr(N2,Y), both sides will get selectors that match their respective packets: (X,N2), (X,Y), (N1,N2), (N1,Y). Not only that, both sides will know the NAT-OA, both i and r. This will also work when there is only 1 NAT device. And in the case of no NAT: X -> TSi(X,*) TSr(Y,*) Y -> TSi(X,X) TSr(Y,Y) which is the TS(X,Y) that you would expect. Chinh -- http://www.certicom.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 23 08:52:59 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E28B28C133; Wed, 23 Apr 2008 08:52:59 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0FE3A6F29 for ; Wed, 23 Apr 2008 08:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[AWL=-1.675, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=0.6, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HoGJcQbX+AVL for ; Wed, 23 Apr 2008 08:52:58 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id E79C73A6B84 for ; Wed, 23 Apr 2008 08:52:57 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m3NFr3s0002617 for ; Wed, 23 Apr 2008 15:53:03 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m3NFr3CQ006449 for ; Wed, 23 Apr 2008 11:53:03 -0400 (EDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m3NFfmDg014564 for ; Wed, 23 Apr 2008 11:41:48 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m3NFfmvx014563 for ipsec@ietf.org; Wed, 23 Apr 2008 11:41:48 -0400 (EDT) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Wed, 23 Apr 2008 11:41:48 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20080423154148.GD12955@sun.com> References: <480F549C.1030309@certicom.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <480F549C.1030309@certicom.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] Transport Mode and NAT [Was: IPsec maintenance/extensions WG?] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Wed, Apr 23, 2008 at 11:24:12AM -0400, Chinh Nguyen wrote: > Dan McDonald wrote: > > Y will see TSi(X), but knows, because of NAT-D/NAT-OA, that there's a > NAT in > > betweeen and it must treat (X) as (N) for purposes of its local IPsec > policy. > > > > I see the disconnect now. We have simple policies (address, port, proto) > so they are mapped directly to TS, then the final TS is mapped into > "ipsec policies" for packet processing. As such, I could not see how an > "ipsec driver" on Y can use TS(X,Y) for traffic destined for N. Thus, X > should not propose (X,Y). (And similarly, Y does not propose (N,Y) for X). But X doesn't know about N - all it can propose is X,Y. It's up to Y to understand there's a NAT in between. > What you are saying is that there may be extra policy > processing/book-keeping for a particular peer. Yes. > That the agreed-upon TS are not the whole story. Is this because 4301 in > some ways supercedes 4306? Because I'm sure 4306 is reasonably clear on how > TS should be used. Take IPsec out of the equation for a second -- there's no way to know what is behind the NAT, or which entity behind the NAT is talking. That holds true when you introduce IPsec into the mix. IKE's NAT-OA allows checksum adjustments to happen, but it doesn't help the non-NAT-ted Y's generic IP code how to figure out if it's X, or A, or B that's taking behind the NAT. > For completeness, I would like to point out (from my old e-mail), that > given the more general situation: > X -- N1 -- N2 -- Y > > If X sends TSi(X,*) TSr(N2,*) and Y responds TSi(X,N1) TSr(N2,Y), both > sides will get selectors that match their respective packets: (X,N2), > (X,Y), (N1,N2), (N1,Y). Not only that, both sides will know the NAT-OA, > both i and r. You make one small mistake --> there will NEVER be an (X,Y) packet on the wire. Put sniffers on each of the links you draw above, and you'll see (X,N2), (N1,N2), and (N1,Y). > This will also work when there is only 1 NAT device. And in the case of > no NAT: X -> TSi(X,*) TSr(Y,*) Y -> TSi(X,X) TSr(Y,Y) which is the > TS(X,Y) that you would expect. Yes. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Apr 23 14:23:05 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 090713A6830; Wed, 23 Apr 2008 14:23:05 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 032933A6830 for ; Wed, 23 Apr 2008 14:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.429 X-Spam-Level: X-Spam-Status: No, score=-0.429 tagged_above=-999 required=5 tests=[AWL=-1.930, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_32=0.6, MANGLED_NAIL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XKh4qc9AhOG for ; Wed, 23 Apr 2008 14:23:02 -0700 (PDT) Received: from mail.ca.certicom.com (mail.ca.certicom.com [38.113.160.197]) by core3.amsl.com (Postfix) with SMTP id A7E103A67B0 for ; Wed, 23 Apr 2008 14:23:02 -0700 (PDT) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id BA29610029131; Wed, 23 Apr 2008 17:23:07 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J7qg3nUnzRU; Wed, 23 Apr 2008 17:23:03 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP; Wed, 23 Apr 2008 17:23:03 -0400 (EDT) Received: from [10.0.8.48] ([10.0.8.48]) by domino1.certicom.com (Lotus Domino Release 7.0.2FP2 HF177) with ESMTP id 2008042317210236-34026 ; Wed, 23 Apr 2008 17:21:02 -0400 Message-ID: <480FA915.2060906@certicom.com> Date: Wed, 23 Apr 2008 17:24:37 -0400 From: Chinh Nguyen User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Dan McDonald References: <480F549C.1030309@certicom.com> <20080423154148.GD12955@sun.com> In-Reply-To: <20080423154148.GD12955@sun.com> X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/23/2008 05:21:02 PM, Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/23/2008 05:21:17 PM, Serialize complete at 04/23/2008 05:21:17 PM Cc: ipsec@ietf.org Subject: Re: [IPsec] Transport Mode and NAT [Was: IPsec maintenance/extensions WG?] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dan McDonald wrote: > On Wed, Apr 23, 2008 at 11:24:12AM -0400, Chinh Nguyen wrote: >> Dan McDonald wrote: > >> > Y will see TSi(X), but knows, because of NAT-D/NAT-OA, that there's a >> NAT in >> > betweeen and it must treat (X) as (N) for purposes of its local IPsec >> policy. >> > >> >> I see the disconnect now. We have simple policies (address, port, proto) >> so they are mapped directly to TS, then the final TS is mapped into >> "ipsec policies" for packet processing. As such, I could not see how an >> "ipsec driver" on Y can use TS(X,Y) for traffic destined for N. Thus, X >> should not propose (X,Y). (And similarly, Y does not propose (N,Y) for X). > > But X doesn't know about N - all it can propose is X,Y. It's up to Y to > understand there's a NAT in between. Yes, all X can propose is (X,Y) and all Y can respond is (X,Y). So if we were to map (X,Y) directly to some ipsec security policy rule, there's no way packets outbound from Y for N would get encrypted. As you pointed out, this requires extra logic. I'm not aware if this was stated in 4306. It may have been covered by one of the addendums or clarification drafts (e.g., draft-kukec-ikev2-tutorial-additions-02). Certainly, from my perspective, this is problematic as we rely on the TS. > Take IPsec out of the equation for a second -- there's no way to know what is > behind the NAT, or which entity behind the NAT is talking. That holds true > when you introduce IPsec into the mix. IKE's NAT-OA allows checksum > adjustments to happen, but it doesn't help the non-NAT-ted Y's generic IP > code how to figure out if it's X, or A, or B that's taking behind the NAT. Yes. A message from Y to N would be ambiguous. "Are you trying to use the security policy for X, A, or B?" You noted previously that there may be some ways to solve this. In theory, a reply from Y to X may not be. The encrypted packet from X, or A would both have source ip N but different source (NAT) ports. If you can "stamp" the decrypted packet with this info and track it, then the reply to that packet may also be similarly tracked. Anyway, now we're on to something else entirely. > >> For completeness, I would like to point out (from my old e-mail), that >> given the more general situation: >> X -- N1 -- N2 -- Y >> >> If X sends TSi(X,*) TSr(N2,*) and Y responds TSi(X,N1) TSr(N2,Y), both >> sides will get selectors that match their respective packets: (X,N2), >> (X,Y), (N1,N2), (N1,Y). Not only that, both sides will know the NAT-OA, >> both i and r. > > You make one small mistake --> there will NEVER be an (X,Y) packet on the > wire. Put sniffers on each of the links you draw above, and you'll see > (X,N2), (N1,N2), and (N1,Y). Yes. For both X and Y, there are 3 unused combination. X only needs (X, N2) and Y only needs (N1,Y). This is certainly wasteful. However, it seems to allow us to correctly negotiate when behind NAT using strictly the TS payloads and some fairly simple logic. Y: "If transport mode, then TSi = the source IP of peer (N1 if X behind NAT), and TSr=my own IP, and also whatever the peer sent". There's also the benefit of both sides knowing the NAT-OAi and NAT-OAr. But this is not crucial as full checksumming can be done. Chinh -- http://www.certicom.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 24 07:32:05 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14173A6CFF; Thu, 24 Apr 2008 07:32:04 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DB7F3A69C7 for ; Thu, 24 Apr 2008 07:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1ubrj+RgKj6 for ; Thu, 24 Apr 2008 07:31:49 -0700 (PDT) Received: from labs3.cc.fer.hr (labs3.cc.fer.hr [161.53.72.21]) by core3.amsl.com (Postfix) with ESMTP id 746E028C211 for ; Thu, 24 Apr 2008 07:31:12 -0700 (PDT) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs3.cc.fer.hr (8.13.8+Sun/8.12.10) with ESMTP id m3OEVCQ6029762 for ; Thu, 24 Apr 2008 16:31:15 +0200 (CEST) Content-class: urn:content-classes:message MIME-Version: 1.0 x-mimeole: Produced By Microsoft Exchange V6.5 Date: Thu, 24 Apr 2008 16:31:12 +0200 Message-ID: <6572A948732BCA4691C089730717118A07A0B7@sluga.fer.hr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IPsec maintenance/extensions WG? Thread-Index: AcimF9h+W4x+STUgQjmiFOFpT0QfCw== From: "Ana Kukec" To: Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0265610331==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0265610331== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8A617.D887B02C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8A617.D887B02C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Steve, Yes, CGA enabled IKEv2 ensures "only" LoF. What we need besides CGA + = IKEv2=20 is a PAD extension, something similar to SA constraints field. We could specify additional field for each PAD element, eg. a raw public key used in CGA generation or complete CGA, to identify with which peers=20 implementation is allowed to talk to. In such a way we would ensure = secure=20 initial authentication. And what is the most important, we wouldn't be less secure than pure IKEv2, while in the same time we will have IKEv2 implementation wihout centralized trust infrastructure. Ana =20 >Stephen Kent wrote: Thanks for the quick response. I'm afraid I am puzzled by your=20 answer; let me explain. My understanding of the procedure is that first time a host uses a=20 CGA in an IKE SA, the peer would not have any basis for mapping that=20 CGA to another form of ID. Thus this seems like LoF to me.=20 (Moreover, an initial motivation for CGAs was to enable a host to use=20 different addresses, either serially over time or in parallel, e.g.,=20 to hinder traffic analysis. If one adopts that use model, a CGA is=20 not a persistent ID, and thus would be worse than a BTNS-based LoF=20 model.) Steve ------_=_NextPart_001_01C8A617.D887B02C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [IPsec] IPsec maintenance/extensions WG?

Hi Steve,

Yes, CGA enabled IKEv2 ensures "only" LoF. What we need = besides CGA + IKEv2
is a PAD extension, something similar to SA constraints field. We = could
specify additional field for each PAD element, eg. a raw public key = used
in CGA generation or complete CGA, to identify with which peers
implementation is allowed to talk to. In such a way we would ensure = secure
initial authentication. And what is the most important, we wouldn't = be
less secure than pure IKEv2, while in the same time we will have = IKEv2
implementation wihout centralized trust infrastructure.

Ana   


>Stephen Kent wrote:

Thanks for the quick response.  I'm afraid I am puzzled by your
answer; let me explain.

My understanding of the procedure is that first time a host uses a
CGA in an IKE SA, the peer would not have any basis for mapping that
CGA to another form of ID. Thus this seems like LoF to me.
(Moreover, an initial motivation for CGAs was to enable a host to = use
different addresses, either serially over time or in parallel, e.g.,
to hinder traffic analysis. If one adopts that use model, a CGA is
not a persistent ID, and thus would be worse than a BTNS-based LoF
model.)

Steve

------_=_NextPart_001_01C8A617.D887B02C-- --===============0265610331== 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://www.ietf.org/mailman/listinfo/ipsec --===============0265610331==-- From ipsec-bounces@ietf.org Thu Apr 24 08:55:18 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 459BA28C20E; Thu, 24 Apr 2008 08:55:18 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8948A28C20E for ; Thu, 24 Apr 2008 08:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cn4Ha81gVjtb for ; Thu, 24 Apr 2008 08:55:16 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id A7BBA28C25E for ; Thu, 24 Apr 2008 08:55:16 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Jp3n7-0005ep-3m; Thu, 24 Apr 2008 11:55:21 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <6572A948732BCA4691C089730717118A07A0B7@sluga.fer.hr> References: <6572A948732BCA4691C089730717118A07A0B7@sluga.fer.hr> Date: Thu, 24 Apr 2008 11:55:18 -0400 To: "Ana Kukec" From: Stephen Kent Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 4:31 PM +0200 4/24/08, Ana Kukec wrote: >Hi Steve, > >Yes, CGA enabled IKEv2 ensures "only" LoF. What we need besides CGA + IKEv2 >is a PAD extension, something similar to SA constraints field. We could >specify additional field for each PAD element, eg. a raw public key used >in CGA generation or complete CGA, to identify with which peers >implementation is allowed to talk to. In such a way we would ensure secure >initial authentication. And what is the most important, we wouldn't be >less secure than pure IKEv2, while in the same time we will have IKEv2 >implementation wihout centralized trust infrastructure. > >Ana > OK, I'm happy to hear you agree that, by itself, CGA would also just be an LoF mechanism like BTNS. First, I want to observe that If one had the ability to store a public key in the PAD for authorization, then one can also store a cert. The cert can be a self-signed CA cert, under which the EE cert for the peer is issued. So the argument that one needs to use bare keys to avoid a centralized infrastructure is simply not true, even if it is often cited :-). RFC 4301 has a requirement that the PAD support X.509 certs and pre-shared secrets, but not for bare public keys. In part this is because mandating support for bare public keys would be redundant given the above analysis, and thus would only add to the complexity of the PAD. Second, once you have a PAD entry, you can use either an address or a name as the basis for SPD entry constraints. If you use name-based constraints, then no new mechanisms are needed when CGAs are employed, and the CGA can even change over time (as originally envisioned) without needing to change the PAD or SPD entries. If the CGA remains constant, then it becomes equivalent to a traditional IP (v6) address re access control, and the PAD could be configured with that address as a trivial address range for traffic selectors, and one can use the address in SPD entries. So I'm not sure why one needs new IKE payloads and new PAD entry values to accommodate CGAs. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Apr 24 11:11:32 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 924113A6C6E; Thu, 24 Apr 2008 11:11:32 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A3F13A67EF for ; Thu, 24 Apr 2008 11:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=0.6, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzN-xZxcjUao for ; Thu, 24 Apr 2008 11:11:26 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 64C7B3A6807 for ; Thu, 24 Apr 2008 11:11:07 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m3OIB3R2002822; Thu, 24 Apr 2008 14:11:03 -0400 (EDT) Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor); Thu, 24 Apr 2008 14:11:03 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m3OI8vAu001676; Thu, 24 Apr 2008 14:11:01 -0400 (EDT) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 24 Apr 2008 14:10:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 24 Apr 2008 14:10:46 -0400 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91016F6091@CORPUSMX20A.corp.emc.com> In-Reply-To: <480FA915.2060906@certicom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Transport Mode and NAT Thread-Index: AciliD/stgB8svDORT6DWrbfPDpn1QAqzxXA References: <480F549C.1030309@certicom.com> <20080423154148.GD12955@sun.com> <480FA915.2060906@certicom.com> To: X-OriginalArrivalTime: 24 Apr 2008 18:10:46.0729 (UTC) FILETIME=[84D89390:01C8A636] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.51425 X-PerlMx-Spam: Gauge=, SPAM=0%, Reason='EMC_BODY_1+ -3, EMC_FROM_0+ -3, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow Cc: ipsec@ietf.org Subject: Re: [IPsec] Transport Mode and NAT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > > > >> > Y will see TSi(X), but knows, because of NAT-D/NAT-OA, that there's a NAT in > >> > between and it must treat (X) as (N) for purposes of its local IPsec policy. > >> > >> I see the disconnect now. We have simple policies (address, port, proto) > >> so they are mapped directly to TS, then the final TS is mapped into > >> "ipsec policies" for packet processing. As such, I could not see how an > >> "ipsec driver" on Y can use TS(X,Y) for traffic destined for N. Thus, X > >> should not propose (X,Y). (And similarly, Y does not propose (N,Y) for X). > > > > But X doesn't know about N - all it can propose is X,Y. It's up to Y to > > understand there's a NAT in between. > > Yes, all X can propose is (X,Y) and all Y can respond is (X,Y). So if we > were to map (X,Y) directly to some ipsec security policy rule, there's > no way packets outbound from Y for N would get encrypted. > > As you pointed out, this requires extra logic. I'm not aware if this was > stated in 4306. It may have been covered by one of the addendums or > clarification drafts (e.g., draft-kukec-ikev2-tutorial-additions-02). The "extra logic" is implied by Section 2.23 of RFC 4306. In essence, the logic is that when the NAT detection source IP payload doesn't match, then the actual source address of the packet containing that payload (i.e., N) has to be used as the remote address for local IPsec traffic policy, because traffic for that SA will be sent to/received from that source address (N) and not the address in the traffic selector (X). If one thinks about it, this is reasonably obvious, because X is not a valid address that Y can communicate with, and hence using X for local traffic processing at Y is doomed to failure. The upshot is that the traffic selectors for the SA pair is (X, Y) and (as Dan wrote) Y "must treat (X) as (N) for purposes of its IPsec policy." In the reverse direction, if Y initiates, all it can propose is (Y,N). X sees the NAT Detection Destination IP payload fail to match and hence knows that it has to use X instead of N as the local address in its IPsec policy. [... snip ...] > >> For completeness, I would like to point out (from my old e-mail), that > >> given the more general situation: > >> X -- N1 -- N2 -- Y > >> > >> If X sends TSi(X,*) TSr(N2,*) and Y responds TSi(X,N1) TSr(N2,Y) Nooo - don't do that!!! That response by Y mixes addresses from different networks in both traffic selectors; that's a bad idea that is sure to cause confusion. X (private address) and N1 (X's public address as seen by N2 and Y) aren't addresses in the same network, and likewise for Y (private address) and N2 (public address of Y as seen by X and N1). The traffic selectors for this case (X is initiator) are (X,N2); Y will see both the source and destination NAT detection payloads fail to match and know that both addresses have been NAT-ed. NAT traversal mechanisms should to be used to communicate NAT translation information, rather than trying to abuse traffic selectors for that purpose. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Apr 25 00:44:49 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298B93A6D17; Fri, 25 Apr 2008 00:44:49 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BA2A3A6D5B for ; Fri, 25 Apr 2008 00:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Iv14GT8e1W8 for ; Fri, 25 Apr 2008 00:44:47 -0700 (PDT) Received: from givry.fdupont.fr (unknown [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by core3.amsl.com (Postfix) with ESMTP id 2DCED3A6D17 for ; Fri, 25 Apr 2008 00:44:47 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.13.8/8.13.8) with ESMTP id m3P7ineD003030; Fri, 25 Apr 2008 09:44:49 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <200804250744.m3P7ineD003030@givry.fdupont.fr> From: Francis Dupont To: Dan McDonald In-reply-to: Your message of Tue, 22 Apr 2008 17:29:32 EDT. <20080422212932.GA12955@sun.com> Date: Fri, 25 Apr 2008 09:44:49 +0200 Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In your previous mail you wrote: > Pasi, > > I agree that there could be benefit to a WG that exists to coordinate > responses to questions and to clarify the IPsec/IKE specs. I agree with Pasi, Steve, and others who've said the above. +1 Francis.Dupont@fdupont.fr _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Apr 25 07:24:39 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41FE03A6DB6; Fri, 25 Apr 2008 07:24:39 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D03328C143 for ; Fri, 25 Apr 2008 07:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[AWL=-0.458, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWicQ9dsA4ie for ; Fri, 25 Apr 2008 07:24:36 -0700 (PDT) Received: from mail.ca.certicom.com (mail.ca.certicom.com [38.113.160.197]) by core3.amsl.com (Postfix) with SMTP id 6E9B23A6DB6 for ; Fri, 25 Apr 2008 07:24:36 -0700 (PDT) Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 61A7C10029132 for ; Fri, 25 Apr 2008 10:24:40 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm.certicom.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73lDxCH9wRqr for ; Fri, 25 Apr 2008 10:24:37 -0400 (EDT) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP for ; Fri, 25 Apr 2008 10:24:37 -0400 (EDT) Received: from [10.0.8.48] ([10.0.8.48]) by domino1.certicom.com (Lotus Domino Release 7.0.2FP2 HF177) with ESMTP id 2008042510224991-4482 ; Fri, 25 Apr 2008 10:22:49 -0400 Message-ID: <4811EA11.1030009@certicom.com> Date: Fri, 25 Apr 2008 10:26:25 -0400 From: Chinh Nguyen User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: ipsec@ietf.org References: <480F549C.1030309@certicom.com> <20080423154148.GD12955@sun.com> <480FA915.2060906@certicom.com> <8CC6CEAB44F131478D3A7B429ECACD91016F6091@CORPUSMX20A.corp.emc.com> In-Reply-To: <8CC6CEAB44F131478D3A7B429ECACD91016F6091@CORPUSMX20A.corp.emc.com> X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/25/2008 10:22:49 AM, Serialize by Router on Certicom1/Certicom(Release 7.0.2FP2 HF177|August 10, 2007) at 04/25/2008 10:22:51 AM, Serialize complete at 04/25/2008 10:22:51 AM Subject: Re: [IPsec] Transport Mode and NAT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Black_David@emc.com wrote: > The "extra logic" is implied by Section 2.23 of RFC 4306. In essence, > the logic is that when the NAT detection source IP payload doesn't > match, > then the actual source address of the packet containing that payload > (i.e., N) has to be used as the remote address for local IPsec traffic > policy, because traffic for that SA will be sent to/received from that > source address (N) and not the address in the traffic selector (X). In section 2.23, there is mention that the original source/dest in the TS can be used for incremental checksum fixup (3rd to last paragraph of section). But that's about it. In section 2.9 on TS negotiation, not much is stated. Although it's implied that TS communicate only "some of the information from their SPD to their peers". In any case, it's clear from David and Dan's messages that extra book-keeping is required for Transport mode and NAT. Am I correct in thinking that NAT-OA (and incremental checksum) is only available to the responder? The initiator can detect there's NAT via the NAT-D payloads, but the TS it receives back will be the values it sends, no new information. In a nutshell, is this the correct logic for transport mode (possibly with NAT)? Initiator: 1. Sends TS(Si, Sr) where Si and Sr are single IPs: init's address and resp's address as seen by init. Expects to receive TS(Si, Sr) from resp. 2. Ipsec processing done with Si, Sr. 3. If nat is detected, do full checksum update. Responder: 1. Expects TS(Si, Sr) where Si and Sr are single IPs. Sends back TS(Si, Sr). 2. Ipsec processing done with IPi, IPr: init's IP address and IP resp's address as seen by resp (e.g., the source/dest in the IKE packet header). 3. If remote nat detected (init behind NAT), do incremental checksum where NAT=IPi, NAT-OAi=Si. If local nat detected (resp behind NAT), do incremental checksum where NAT=Sr, NAT-OAr=IPr. Chinh -- http://www.certicom.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Apr 26 17:44:28 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEE8728C15C; Sat, 26 Apr 2008 17:44:28 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B309B3A68CA for ; Sat, 26 Apr 2008 17:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5QrvRHQooRm for ; Sat, 26 Apr 2008 17:44:26 -0700 (PDT) Received: from ins2.sd.spawar.navy.mil (ins2.sd.spawar.navy.mil [128.49.4.3]) by core3.amsl.com (Postfix) with ESMTP id DB2CF3A6884 for ; Sat, 26 Apr 2008 17:44:25 -0700 (PDT) Received: from [128.49.163.29] (2872sun.spawar.navy.mil [128.49.163.29]) by ins2.sd.spawar.navy.mil (8.13.1/8.13.1) with ESMTP id m3ML5h7A021584; Tue, 22 Apr 2008 14:05:44 -0700 Message-ID: <480E5327.4090204@spawar.navy.mil> Date: Tue, 22 Apr 2008 14:05:43 -0700 From: Jeffrey Sun User-Agent: Thunderbird 1.5.0.12 (X11/20071019) MIME-Version: 1.0 To: Dan McDonald References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> <480E4411.4070902@certicom.com> <20080422201704.GH15188@kebe.east.sun.com> In-Reply-To: <20080422201704.GH15188@kebe.east.sun.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org All, If one peer is behind NAT, than the first Traffic Selector in TSi is effectively the NAT-OA Payload (for the Initiator) in IKEv1. This may require it's own dedicated thread, but I'm curious to why Chinh does not believe that simple selectors don't work for Transport Mode negotiation in a NAT'ed environment. Transport Mode is designed typically in the context of single IPsec host connection (not several hosts fronted by an IPsec gateway); in other words, you shouldn't need any additional selectors. Regarding double NATs, as mentioned by Andreas Steffen in this email thread, you may want to take a look at their draft (draft-brunner-ikev2-mediation). - Jeff Sun Dan McDonald wrote: > On Tue, Apr 22, 2008 at 04:01:21PM -0400, Chinh Nguyen wrote: > >> Hi, >> >> I would certainly like clarifications on IKEv2 Transport Mode >> negotiation when one or both peers are behind NAT. There are no >> discussions in the IKEv2 standard or clarification. I do not think it >> can be done using simple selectors (i.e., TSi = peerA, TSr = peerB) but >> am willing to be corrected. >> > > If one peer is behind NAT, the concept of NAT-OA should take care of that -- > at least that's how it works in IKEv1. (So long as the initiator is behind > the NAT.) > > As for both being behind NAT, there's a strongswan guy who may have a > solution there. > > Dan > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Apr 28 07:58:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC88F3A6B65; Mon, 28 Apr 2008 07:58:17 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 706F93A6D32 for ; Mon, 28 Apr 2008 07:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtwLL4uYxJbM for ; Mon, 28 Apr 2008 07:58:12 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 1436E3A6B65 for ; Mon, 28 Apr 2008 07:58:08 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id i7so1963479tid.25 for ; Mon, 28 Apr 2008 07:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=idnpastpPhxNTjDmObRBXnprucroCqjeFJS0P4I9L24=; b=Ntyu29xySJqrjssTZ5+epOCVvz2JZjOPqvKN8TkiJ0tgvVZtgz3FZIRk9xlgRTIcZBsMaZ5NjRuCi1fWc76DL90Zsw5J8Re3u2QdFAuwIJU9I0U79yhFPxIu2OPv2npQtyGOWFAng1f5hxUwXB0mByOSOLPn6twBL5ENYlABsvg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Yw1h5O1jtK1S7pizRcHrHx44+PqQ71n+AOj3OReFSzHy/zaYfEHmrEMM1JuxJ6RWXZCvWllKREmRDYTz5wDCNqKkqVikPcn5W0baz5Y/NpHgEDO1F7tNdFRd9Z+554S9skutIiQ2C3aHP0yPngbM6f7z20H8OmBO4j/f2XAErPs= Received: by 10.110.5.14 with SMTP id 14mr756703tie.10.1209394657936; Mon, 28 Apr 2008 07:57:37 -0700 (PDT) Received: by 10.110.93.4 with HTTP; Mon, 28 Apr 2008 07:57:37 -0700 (PDT) Message-ID: <1d38a3350804280757m265857fbv6906b8db2f9661b8@mail.gmail.com> Date: Mon, 28 Apr 2008 22:57:37 +0800 From: "Hui Deng" To: Pasi.Eronen@nokia.com, "denghui@chinamobile.com" In-Reply-To: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB726E051F@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org we also advocate the creation of an IPsec maintainance and extensions WG since currently we are working on extending IKE/IPsec to support GRE key exchanging and as traffic selector. This is aimed to solve the problem where there are multiple IPsec SAs to protect different GRE tunnels between the same pair of IPsec peers. These scenario does exist when operator has some security consideration for some ICPs. -Hui 2008/4/22 : > Hi, > > During the Philadelphia meeting, several folks expressed interest > in forming a working group for IPsec maintenance and extensions. > > Since IKEv2 is included in, for example, various US Government IPv6 > profiles, we'll probably see a number of new IKEv2 implementations > during the next couple of years. Having a working group would > provide a forum for discussing implementation questions, and > ensuring that results from, e.g., interoperability workshops are > actually written down in the specifications (which didn't happen > for IKEv1). > > While some maintenance work has already been done (RFC 4718, > draft-hoffman-ikev2bis), and the ipsec mailing list still exists, > finding those has been difficult for non-insiders. Also, the > maintenance work has so far focused largely on the "remote access > VPN" (client-to-gateway) use case, which exercises slightly > different parts of the specs than host-to-host and > gateway-to-gateway IPsec. > > At the same time, there has been interest in standardizing small > improvements and extensions that were not included in the IKEv2 > base specifications (just search for drafts containing "-ikev2-" > or "-ipsec-"). Some of those extensions could benefit from wider > participation that having a working group would bring. > > To actually form a WG, we would need to agree on the initial > charter scope, and have enough people to work on all the items > we decide to take on. > > My current thinking is that the WG charter should describe a small > number of specific work items and reasonable timelines for > completing them, as opposed to including everything related to > IPsec and planning to have the WG around forever. > > To get some discussion started, please send your opinions on > whether having a WG would be a good idea, your thoughts on what > the charter should look like, and what you'd consider to be the > most important work items. > > (If you've talked with me about this topic earlier, please > still post your opinions on the list for others to see.) > > Best regards, > Pasi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Apr 29 04:38:07 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63883A6C84; Tue, 29 Apr 2008 04:38:07 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5A93A69D9 for ; Tue, 29 Apr 2008 04:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8VtJRFVrLPZ for ; Tue, 29 Apr 2008 04:38:02 -0700 (PDT) Received: from mail.kivinen.iki.fi (unknown [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id BB9333A6BB7 for ; Tue, 29 Apr 2008 04:38:01 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id m3TBbrn4000813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Apr 2008 14:37:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id m3TBbpCl029102; Tue, 29 Apr 2008 14:37:51 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18455.2191.206070.947242@fireball.kivinen.iki.fi> Date: Tue, 29 Apr 2008 14:37:51 +0300 From: Tero Kivinen To: Chinh Nguyen In-Reply-To: <4811EA11.1030009@certicom.com> References: <480F549C.1030309@certicom.com> <20080423154148.GD12955@sun.com> <480FA915.2060906@certicom.com> <8CC6CEAB44F131478D3A7B429ECACD91016F6091@CORPUSMX20A.corp.emc.com> <4811EA11.1030009@certicom.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 26 min X-Total-Time: 165 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Transport Mode and NAT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Chinh Nguyen writes: > Black_David@emc.com wrote: > > The "extra logic" is implied by Section 2.23 of RFC 4306. In essence, > > the logic is that when the NAT detection source IP payload doesn't > > match, > > then the actual source address of the packet containing that payload > > (i.e., N) has to be used as the remote address for local IPsec traffic > > policy, because traffic for that SA will be sent to/received from that > > source address (N) and not the address in the traffic selector (X). > > In section 2.23, there is mention that the original source/dest in the > TS can be used for incremental checksum fixup (3rd to last paragraph of > section). But that's about it. Yes, that statement is incomplete, as it does not tell how it can be used, and I have not found a interoperable way to do it, thus as far as I know it cannot be done. This means there is no interoperable way to do incremental checksum fixup in the IKEv2 for transport mode NAT-T. The NAT-T rfc still offers other options which are usable (ignore, recompute), thus this does not cause problems, it just means on of the options is not available. > In section 2.9 on TS negotiation, not much is stated. Although it's > implied that TS communicate only "some of the information from their SPD > to their peers". The whole transport mode part is bit underspecified in the IKEv2, as IKEv2 do not really specify what the IP addresses in the traffic selectors really mean in the transport mode case. As transport mode must be used between hosts, so the IP addresses must be addresses from the host itself, but can there be multiple IP-addresses in the transport mode traffic selectors, in case there is multiple IP-addresses for the host (in general case, not in NAT-T case)? Also the transport mode NAT-T part saying there must "contain exactly one IP address", does not allow using any kind of wildcard selectors. There is also confusion can there be multiple traffic selectors payloads still, even when there is only one IP-address in those traffic selectors (i.e. MAY/SHOULD/MUST you send the first traffic selector matching the exact fields in the data packet?). Again if there can be only one IP address in the NAT-T case in the traffic selectors, that means it must be the real end node addresses (i.e. before NAT), so they are usable for the incremental checksum calculation, but that will mean that when the responder who is not behind the NAT starts receiving packets the IP-addresses it receives do not match the traffic selectors negotiated etc. > In any case, it's clear from David and Dan's messages that extra > book-keeping is required for Transport mode and NAT. Am I correct in > thinking that NAT-OA (and incremental checksum) is only available to the > responder? The initiator can detect there's NAT via the NAT-D payloads, > but the TS it receives back will be the values it sends, no new information. I think it is clear that more specification is needed to make transport mode NAT-T usable, and currently you have only option to recompute or ignore the checksum, there is no option to incrementally fixup the checksum, as there is no NAT-OA available for you. > In a nutshell, is this the correct logic for transport mode (possibly > with NAT)? > > Initiator: > 1. Sends TS(Si, Sr) where Si and Sr are single IPs: init's address and > resp's address as seen by init. Expects to receive TS(Si, Sr) from resp. > 2. Ipsec processing done with Si, Sr. > 3. If nat is detected, do full checksum update. That looks ok. > Responder: > 1. Expects TS(Si, Sr) where Si and Sr are single IPs. Sends back TS(Si, Sr). > 2. Ipsec processing done with IPi, IPr: init's IP address and IP resp's > address as seen by resp (e.g., the source/dest in the IKE packet header). In most of the cases you simply need to ignore the source address of the packet, and assume it is always Si. The problem is that the address nat uses (IPi) might change when the NAT is rebooted, and also when you do the SAD checks (RFC 4301, section 5.2, step 4) you need to use the NAT's address not the negotiated traffic selectors. (I actually remembered that the step 4 would not have been there for the transport mode SAs, but the RFC 4301 does not seem to make any difference between transport mode and tunnel mode SAs there). One of the solutions could be to use the built in reverse NAT inside the IPsec device to NAT the IPi to Si before transport mode IPsec processing. This way the traffic selectors match (SAD has Si and Sr) and this should also survive even the address changes caused by NAT reboots, provided the reverse NAT is also updated. > 3. If remote nat detected (init behind NAT), do incremental checksum > where NAT=IPi, NAT-OAi=Si. If local nat detected (resp behind NAT), do > incremental checksum where NAT=Sr, NAT-OAr=IPr. Anyways, I do not think there is really a way to do anything interoperably, so more specification is needed. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec