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: