From ipsec-bounces@ietf.org Tue Sep 2 09:11:13 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB22A3A6AD8; Tue, 2 Sep 2008 09:11: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 653033A6B3B for ; Tue, 2 Sep 2008 09:11:12 -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=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpN0H9YU4AmH for ; Tue, 2 Sep 2008 09:11:11 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 915AC3A6807 for ; Tue, 2 Sep 2008 09:11:00 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KaYSn-0000GQ-D5; Tue, 02 Sep 2008 12:10:41 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <88C3EF0B-1094-4F62-B407-D55736F8C324@checkpoint.com> Date: Tue, 2 Sep 2008 12:08:55 -0400 To: Yoav Nir From: Stephen Kent Cc: ipsec@ietf.org Subject: Re: [IPsec] Marking ESP-NULL packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 7:18 AM +0300 8/31/08, Yoav Nir wrote: >... > >I agree, but in today's Internet, end-to-end paths will have some >middleboxes along the path that actually do examine the content to >some extent: firewalls, IPS devices, and NAT devices. It depends on where you are :-), and the policy of the boxes in question. An IDS might LIKE to examine content, but if if does not have a tight link to a firewall, it may just be disappointed by an inability to examine content. > >...this, > >See discussion in the archives from 6-Aug and 7-Aug entitled >"Motivation for ESP-null marking", particularly two responses from Ken >Grewal. I'll go back and check; thank's for the pointer. >... > >As you've said, it's only the middlebox that inspects the packets, and >they already do it at the same data rate. It's not really necessary to >measure entropy. They only need to run their usual inspection, and get >random data instead of the protocol they were expecting. maybe, maybe not. And >... > > > AH is inefficient, compared to ESP-NULL. That's why 4301 downgraded >> support for it to a MAY vs. a MUST. > >Why is AH inefficient? The integrity protection is similar to ESP >except that you sign some extra fields (or set them to zero). I was >under the impression that AH was downgraded because NAT boxes break it. AH is inefficient because one has to "hopscotch" through the IP header to compute the ICV. ESP is more efficient because the encapsulation is "clean." AH was mildly deprecated in large part because of this distinction. >... > > >> Before we consider a variant of AH that provides even less integrity >> protection, I think we need to have a lot of discussion of the >> implications of this approach. Also If we create a variant of AH, >> why is it less intrusive than a new protocol like XESP? We don't >> carry version numbers in AH and ESP. We rely on IKE to negotiate >> them, so a middlebox cannot know what version of AH is in use, >> unless we assign a new protocol number, as has been sggested for XESP. > >What I'm suggesting is to change the buffer that is integrity >protected. The AH packet on the wire would look like regular AH, so >the middlebox would not need to be aware of the changes. Only the >endpoints need to be aware. Your response does not address the first part of my concern, i.e., the reduced security offered by a less stringent version of AH, but I understand your point that middleboxes need not know the difference, IF the format is the same. I'm guessing, by your comments above re NATs and AH, why you were thinking about a new version of AH that would be NAT friendly and allow middlebox examination of payloads. However, even if we develop such a version, it is likely to suffer from the same performance problems as the current version of AH. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 2 14:17:54 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 253DF3A6B0B; Tue, 2 Sep 2008 14:17: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 56BC13A6AB2 for ; Tue, 2 Sep 2008 14:17:52 -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 jKVZdotr8MGz for ; Tue, 2 Sep 2008 14:17:51 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 98ED13A6AF4 for ; Tue, 2 Sep 2008 14:17:07 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 02 Sep 2008 14:13:59 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.32,319,1217833200"; d="scan'208";a="375932176" Received: from unknown (HELO azsmsx001.amr.corp.intel.com) ([10.2.167.98]) by fmsmga002.fm.intel.com with ESMTP; 02 Sep 2008 14:13:16 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.152) by azsmsx001.amr.corp.intel.com (10.2.167.98) with Microsoft SMTP Server (TLS) id 8.1.240.5; Tue, 2 Sep 2008 14:15:55 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Tue, 2 Sep 2008 15:13:18 -0600 From: "Grewal, Ken" To: Stephen Kent , Yoav Nir Date: Tue, 2 Sep 2008 15:13:15 -0600 Thread-Topic: [IPsec] Marking ESP-NULL packets Thread-Index: AckNFsu8JzsrSXnBQkOhlA3npW8vSQAIZF5Q Message-ID: References: <88C3EF0B-1094-4F62-B407-D55736F8C324@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Marking ESP-NULL packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 agree with Steve's comments from below that AH is probably not the way forward to resolve this. The two reasons cited are... - Inability to operate under NAT environments, which would require additional changes to the protocol, so why not use ESP as a base for the changes instead of AH? NATs will be around for the foreseeable future; even as we migrate to IPv6 where in addition to tunneling techniques, we will encounter translation techniques (see renewed interest in specifying a standards-based replacement for NAT-PT). - Performance costs (especially in HW) due to mutable fields in the headers that need to be removed from the ICV calculation. There have been extensive debates on deprecating AH based on these and other reasons and proposing to extend AH now will require revisiting those topics again. Separately, the policy applied by intermediate devices can be dependent on the functionality required and the capabilities of that device and hence vary case by case. An IDS/IPS is one example of such a device. I cited some simple examples of these policies and will let others provide more extensive use cases. Currently, IT departments often choose to forego IPsec in favor of having network management tools perform routine network functions. The ability to use IPsec AND preserve the existing (and future) network monitoring/diagnostics tools using a simple ESP wrapper further enables the application of IPsec beyond the VPN/remote access environments of today. Thanks, - Ken >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Stephen Kent >Sent: Tuesday, September 02, 2008 9:09 AM >To: Yoav Nir >Cc: ipsec@ietf.org >Subject: Re: [IPsec] Marking ESP-NULL packets > >At 7:18 AM +0300 8/31/08, Yoav Nir wrote: >>... >> >>I agree, but in today's Internet, end-to-end paths will have some >>middleboxes along the path that actually do examine the content to >>some extent: firewalls, IPS devices, and NAT devices. > >It depends on where you are :-), and the policy of the boxes in >question. An IDS might LIKE to examine content, but if if does not >have a tight link to a firewall, it may just be disappointed by an >inability to examine content. > >> >>...this, >> >>See discussion in the archives from 6-Aug and 7-Aug entitled >>"Motivation for ESP-null marking", particularly two responses from Ken >>Grewal. > >I'll go back and check; thank's for the pointer. > >>... >> >>As you've said, it's only the middlebox that inspects the packets, and >>they already do it at the same data rate. It's not really necessary to >>measure entropy. They only need to run their usual inspection, and get >>random data instead of the protocol they were expecting. > >maybe, maybe not. And > >>... >> >> > AH is inefficient, compared to ESP-NULL. That's why 4301 downgraded >>> support for it to a MAY vs. a MUST. >> >>Why is AH inefficient? The integrity protection is similar to ESP >>except that you sign some extra fields (or set them to zero). I was >>under the impression that AH was downgraded because NAT boxes break it. > >AH is inefficient because one has to "hopscotch" through the IP >header to compute the ICV. ESP is more efficient because the >encapsulation is "clean." AH was mildly deprecated in large part >because of this distinction. > >>... >> > >>> Before we consider a variant of AH that provides even less integrity >>> protection, I think we need to have a lot of discussion of the >>> implications of this approach. Also If we create a variant of AH, >>> why is it less intrusive than a new protocol like XESP? We don't >>> carry version numbers in AH and ESP. We rely on IKE to negotiate >>> them, so a middlebox cannot know what version of AH is in use, >>> unless we assign a new protocol number, as has been sggested for XESP. >> >>What I'm suggesting is to change the buffer that is integrity >>protected. The AH packet on the wire would look like regular AH, so >>the middlebox would not need to be aware of the changes. Only the >>endpoints need to be aware. > >Your response does not address the first part of my concern, i.e., >the reduced security offered by a less stringent version of AH, but I >understand your point that middleboxes need not know the difference, >IF the format is the same. > >I'm guessing, by your comments above re NATs and AH, why you were >thinking about a new version of AH that would be NAT friendly and >allow middlebox examination of payloads. However, even if we develop >such a version, it is likely to suffer from the same performance >problems as the current version of AH. > >Steve >_______________________________________________ >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 Sep 2 14:21:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F55E3A69F3; Tue, 2 Sep 2008 14:21: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 092F63A685C for ; Tue, 2 Sep 2008 14:21:49 -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 vVmNBKSYpP4A for ; Tue, 2 Sep 2008 14:21:47 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 3D9DC3A6A97 for ; Tue, 2 Sep 2008 14:21:42 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 02 Sep 2008 14:17:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.32,319,1217833200"; d="scan'208";a="331793089" Received: from azsmsx602.amr.corp.intel.com ([10.2.121.201]) by orsmga002.jf.intel.com with ESMTP; 02 Sep 2008 14:21:15 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.152) by azsmsx602.amr.corp.intel.com (10.2.121.201) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 2 Sep 2008 14:21:09 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Tue, 2 Sep 2008 15:19:22 -0600 From: "Grewal, Ken" To: Tero Kivinen Date: Tue, 2 Sep 2008 15:19:20 -0600 Thread-Topic: [IPsec] Motivation for ESP-null marking Thread-Index: Acj8cgPINMaPAPs7TN25Au7gFXXdVQQyCTrw Message-ID: References: <4899A8A1.7040808@checkpoint.com> <18593.31131.888367.946778@fireball.kivinen.iki.fi> In-Reply-To: <18593.31131.888367.946778@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Motivation for ESP-null marking X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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, Apologies for the delayed response, but looks like this slipped under the Radar. A large part of your message is promoting a heuristics based approach, which was also suggested in hallway conversations in Dublin. In order to evaluate this further, including performance / cost / extensibility, I would encourage someone to submit a specification on the heuristics algorithms to employ and perhaps also the associated probability of false positives (where the same conclusion may be reached by running these heuristics on encrypted data). This way it can be evaluated on merit against the current proposal. Other comments inline... Thanks, - Ken >-----Original Message----- >From: Tero Kivinen [mailto:kivinen@iki.fi] >Sent: Tuesday, August 12, 2008 4:53 AM >To: Grewal, Ken >Cc: Yaron Sheffer; ipsec@ietf.org >Subject: Re: [IPsec] Motivation for ESP-null marking > >Grewal, Ken writes: >> >Let us ignore the details of the solution proposals for a while (1 >> >protocol number vs. 2, ESP wrapper vs. keeping the existing ESP >> header), >> >and consider whether there is a need to have any solution at all for >> >this problem: >> [Ken] I am surprised that there are questions being raised about this >> goal, given that its presence in the charter indicates that it's a >> worthy one. Are there any strong arguments for reversing that consensus? > >Standard track mechanism does not need to be protocol change, it can >be also documentation of how to do the thing with heuristic checks. > >I think there is no point of doing this on the protocol level as to >deploy it requires changes to ALL IPsec endpoints. [Ken] It will only require changes to nodes that choose to utilize this functionality, which is probably the same statement for any other work item in IETF today. If it is not needed (e.g. remote access / VPN), then those nodes can operate as they do today. >If we document and >implement heuristic checks those can be done directly on the >middleboxes, thus requiring only upgrading those small amount of >boxes, not all the network endnodes. This means that the heuristic >methods are deployable within one year from now or even faster >(especially as they do not require interoperability testing or actual >protocol specifications, thus vendors can start implementing them >NOW). > >If we now define extension for IKEv2 to allow this (and I hope nobody >is even going to suggest implementing anything to the now already >obsoleted IKEv1 protocol), it will most likely take about year to >finish the protocol document, and then vendors will start implementing >it thus first implementations would most likely be end of 2009 or >beginning of 2010, and then you need to wait for couple of more years >before most of the operating systems support that new extension (i.e. >around 2012-2014). After most of the operating systems start >supporting it, then you still need to wait 3-5 years to make sure all >of the old devices in the network has been updated to support that >latest operating system, before you can make sure that all network >endnodes support this. So in best you could be able to use it in 2012 >or so and in reality you would have to wait until 2015-2018... > >In the mean time you most likely still want to have solution that will >work NOW, not in 10 years time, thus middle box vendors will implement >the heuristic methods anyways regardless whether we define protocol >for it or not. [Ken] This argument is applicable to any charted work item and the deployment timelines will be dependent on many factors, including the perceived usefulness of the feature, as well as alternatives available. A heuristics based solution may be less desirable, as anytime a new protocol/extension is encapsulated in IPsec, the heuristics need to be updated to comprehend it. Having said that, perhaps it is possible to devise a solution that will work for all protocols/payloads of today and tomorrow? If so, we'd very much like to see it fully specified in a draft submission. That will make it much easier to evaluate the relative feasibility and practicality of the heuristic approach, compared to our proposal. > >This protocol change is again something that will disrupt deployment >of IPsec, i.e. there will always be implementations which do not >support it, and which then cannot be used in some environments. It can >also cause delays in deployment, when enterprices decide that they >wait until they have this protocol ready for all platforms before even >starting to use IPsec. [Ken] Again, please see above. This is applicable to any change / new feature, so not unique to ESP extensions. > >I would much more like to see IPsec to spread out as fast as possible, >and not waste time for something that can be done in the middle boxes >quite easily with just heuristic checks. > >> > * What is the security/threat environment that we are dealing with? >> > In other words, what is the security policy for which we want an >> > efficient enforcement? >> [Ken] This solution is targeting an environment where intermediary >> devices would like to inspect the packet on route and optionally make >> access control decisions based on local policy and the results of the >> packet inspection. Some examples of policies are: Dropping packets with >> certain characteristics (based on protocol / port or deeper inspection). >> E.g. Do not allow any encrypted data; Allow encrypted data to only these >> systems; Do not allow FTP/TFTP traffic between these endpoints, but >> allow for others. The list goes on...basically any 5-tuple firewall >> rules + additional enforcement based on payload examination and >> intrusion prevention. >> In order to make these decisions, the packets needs to be inspected and >> the current IPsec ESP spec does not allow you to infer if the packet is >> encrypted or in the clear (ESP-NULL). > >I do not see any reason why both ESP-NULL and encrypted ESP shuld be >allowed between 2 end nodes, i.e. I see only reason where there is >either only ESP-NULL allowed or only any type of ESP allowed (i.e. >encrypted or not, but not inspected at all). [Ken] This is a matter of policy and we should not offer a pure black-or-white choice. Why don't we just remove NAT and use AH in these environments? Why did we propose a NAT-T solution at all? We cannot mandate how an organization will structure the network (hence the NAT-T solution) and similarly we cannot predict or dictate what protocols/encapsulations/algorithms it should run over that network. > >If both ESP-NULL and encrypted ESP is allowed between pair of end >nodes, then anybody who wants to bybass middlebox checks will simply >use encrypted ESP. If someone disagrees with this, I would like him to >explain me why this is needed, and what kind of policy is used for >that. [Ken] This is negotiated via policy, which is under the admin's control. E.g. If the policy states that my company CEO (based on his credentials used during IKE) is able to connect to a particular server using encrypted ESP, whereas Joe Bloggs must use ESP-NULL to allow traffic scanning, why could this not be allowed? > >Using that premisis, that means that for every single ESP packet >coming in to the device, we know immediately after matching the >IP-addresses in the header to the policy whether ESP-NULL is mandated, >or not. If it is not mandated, then packet is passed forward, as there >is no point of inspecting encrypted packets. > >If ESP-NULL is mandated, then you simply assume packet is ESP-NULL and >inspect the packet, and if it looks like encrypted ESP (or garbage) >then you do the normal thing firewalls do, i.e drop it. > >> This has been a deployment barrier to using IPsec in Enterprise >> environments as IT departments would like to employ E2E security, but >> not at the cost of circumventing existing network monitoring / >> diagnostics tools. This charter item is looking at removing this barrier >> and allowing IPsec to be employed in these environments. > >It will be really, really expensive and time consuming to update all >end nodes in the network to allow them to use this new protocol >extension. It is much faster and cheaper to update those network >monitoring / diagnostic tools with ones that support heuristic checks. > >Also if IT department has full control of the end node >configurations (which they must have if they assume they can update >all end node implementations at will) they can simply mandate them to >use one specific ESP-NULL algorithim, i.e. simply say that no other >ESP-NULL algoritm is allowed except AUTH_HMAC_SHA1_96, and that will >remove all heuristic checks needed. This kind of solution is >implementatable in extremely fast timeframe. [Ken] This may be viable in small organizations, but is not practical in a large organization, unless a 'forklift upgrade' is used. Also, we need to consider legacy devices (e.g. secure printing using an older algorithm - Do I really want to upgrade all my printers because I choose to use GMAC for other secure comms and my printer is using HMAC-SHA-1-96?). This is just a simple example for illustration purposes. The remainder of your comments below pertains to heuristics, so please see my comment at the end. > >> > * Are there alternative ways to detect unencrypted traffic in the >> > existing ESP, e.g. heuristics? Are they easy to implement in >> > software or in hardware? How significant is the problem of false >> > positives? >> [Ken] Heuristics will never be free of false positives, all we can do is >> play the probability game and reduce false positives to a very small >> value. > >Depends what you mean with false positives. > >If you mean that encrypted ESP packet will pass the ESP-NULL >heuristics and pass the firewall, then the probability of that will go >very quickly way below the 96 bits offered by the AUTH_HMAC_SHA1_96 if >you do any kind of deep inspection. Also as there should not be any >encrypted ESP packets between the nodes who by policy should use >ESP-NULL, if they happen to negotiate encrypted ESP for some reason, >they might get 15 packets through for every million packets they try >to send, even when if you only check TCP checksum (16 bits). If yo do >TCP flow checking (source and destination ports, sequence number, >acknowledgement number) you do check close to the 96 bits worth of >data already. For that to match from the random encrypted packet to >some ESP-NULL flow is about the same probability that the randomly >generated packet will pass your AUTH_HMAC_SHA1_96 check. > >> False positives have a high cost as they can lead to incorrectly >> applying policies (e.g. because we falsely determine that an ESP >> encrypted packet is ESP-NULL) and can cause almost >> impossible-to-diagnose network glitches (e.g. which packet(s) out of the >> millions being processed actually generated the false positives). > >No. For the end nodes point of view the encrypted ESP connection >between the nodes is broken regardless whether there is one packet >every 2^16 or 2^96 going through it. They will see that as broken link >and user who misconfigured boths ends (note, that it is not enough for >one user to misconfigure his node, but both ends must be misconfigured >to allow enctypted ESP) to allow encrypted ESP will notice this and >fix his configuration. > >For attacker doing the same thing, he can continue using encrypted >packets but as 99.99999999999999999999999999% of his packets will get >dropped by simple tcp flow checking his attacks will be detected very >quickly. > >Note, that there cannot be valid encrypted ESP packet dropped because >of these heuristic checks, as encrypted ESP packets are not inspected, >but they are passed by (when allowed by policy). > >> Heuristics can also become very complex with numerous rules to cater for >> different protocols / payloads (including catering for the protocols of >> tomorrow). As for employing heuristics in SW Vs. HW, this is really >> implementation dependent. Having said that, in the multi-core >> environment of today, numerous vendors employ IO acceleration techniques >> in HW for fast data movement between the HW (e.g. NIC) and SW >> components. These techniques are needed to ensure that data is moved >> directly to the correct CPU/NPU core, which is the consumer of that >> data. These decisions are typically based on stream identifiers (e.g. >> 5-tuples in the packet) to ensure full load-balancing capabilities >> between the multiple cores. In order to make these decisions, the HW >> needs to extract this data and hence any heuristics would need to run in >> the HW. Implementing heuristics in HW is very costly, compared with our >> proposed approach of an ESP wrapper. > >No. None of those heuristics needs to really run on the HW. Only the >SPI checking needs to run on the HW. I.e. the hardware must understand >that it is matching six tuple if IP header protocol is ESP, i.e. >source ip/destination ip/spi/protocol number inside ESP-NULL/source >port inside ESP-NULL/destination port inside ESP-NULL. Immediately >when it sees the SPI it will know where the protocol number and actual >header information is. If the SPI is uknown, then HW throws the packet >to slowpath, which will do the heuristics, calculate the offsets for >the actual protocol information and for the protocol number, and store >that information along with the 6-tuple to the packet matching >hardware and resume the packet. > >In almost all the hardware I have seen (our own SafeXcel-5160, Octeon) >the flow creation is always done on the softpath anyways. For Intel >Tolapai chips can do it both ways (i.e. either from the microcode >controlled fastpath, or from the softpath). > >Doing flow creation on the fastpath is so complicated, that I expect >all chips doing so are running some kind of microcode inside the chip >doing the actual flow creation, thus chip vendors can most likely add >support for IPsec SPI flow creation there in firmware updates when it >is widely requested. > >Note, that if we change the ESP any way (i.e. define new protocol >number, or add new bytes or whatever), all the existing hardware will >need at minimum firmare updates anyways. In some cases like in Octeon >it would be just writing new code, in some cases like in SafeXcel-5160 >or Tolapai chips it would require the chip vendor to update the >microcode. > >So from hardware point of view it does not really matter what we do >(i.e. heuristics or ESP-NULL marker) the firmware needs to be updated. > >In some chip architectures firmware require smaller updates for the >heuristics method, as heuristics can be done on the softpath, as the >full ESP-NULL marker processing needs to be done on the firmware (none >of that processing can be pushed to the showpath). [Ken] The remainder of your comments above relate to Heuristics and where these are implemented. This could be in HW or firmware or SW and not all implementations are equally amenable to upgrade options or tolerant of performance requirements. Also, the practically of heuristics based approaches at high speed line rates (10Gbps today, 40/100Gbps tomorrow) can be costly and dependent on the hardware architecture, whereas a new ESP encapsulation would work fine regardless. Furthermore, any changes to any ESP encapsulated protocols will require changes / additions to the heuristics approach, making this approach a continuous, moving target. A heuristics based approach was mentioned as an alternative during some hallway conversations in Dublin, so, perhaps it would nice to have a submission on the details. This way, the heuristics approach can be evaluated from the point of view of different hardware implementations and architectures. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 2 14:34:45 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7028328C15F; Tue, 2 Sep 2008 14:34:45 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B44228C1F1 for ; Tue, 2 Sep 2008 14:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cTjE5FYlZfHm for ; Tue, 2 Sep 2008 14:34:43 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 09A773A6B0B for ; Tue, 2 Sep 2008 14:34:42 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m82LR24l015050 for ; Tue, 2 Sep 2008 17:27:02 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m82LYHuF162404 for ; Tue, 2 Sep 2008 15:34:17 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m82LYHYr011750 for ; Tue, 2 Sep 2008 15:34:17 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m82LYHG6011746 for ; Tue, 2 Sep 2008 15:34:17 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 09/02/2008 02:34:12 PM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 09/02/2008 02:34:12 PM, Serialize complete at 09/02/2008 02:34:12 PM, S/MIME Sign failed at 09/02/2008 02:34:12 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_07222008NPHF42 | August 5, 2008) at 09/02/2008 15:34:17, Serialize complete at 09/02/2008 15:34:17 Message-ID: Date: Tue, 2 Sep 2008 14:34:16 -0700 Subject: [IPsec] Question about deleting a half-open child SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0274400936==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0274400936== Content-Type: multipart/alternative; boundary="=_alternative 00767CF5882574B8_=" This is a multipart message in MIME format. --=_alternative 00767CF5882574B8_= Content-Type: text/plain; charset="US-ASCII" Suppose the initiator sends an SA payload that contains both an AH and ESP proposal. Before receiving the response, the initiator decides to close the half-open child SA. I assume that the informational request should include two delete payloads, one for AH and one for ESP. Is that correct? Related to that question, I don't see a requirement that all proposals in an SA payload have the same SPI. So, in this example, it would be permissible for the AH and ESP proposals to have different SPIs. Is that correct? Keith Welter IBM Enterprise Networking Solutions 1-415-545-2694 (T/L: 473-2694) --=_alternative 00767CF5882574B8_= Content-Type: text/html; charset="US-ASCII"
Suppose the initiator sends an SA payload that contains both an AH and ESP proposal.  Before receiving the response, the initiator decides to close the half-open child SA.  I assume that the informational request should include two delete payloads, one for AH and one for ESP.  Is that correct?

Related to that question, I don't see a requirement that all proposals in an SA payload have the same SPI.  So, in this example, it would be permissible for the AH and ESP proposals to have different SPIs.  Is that correct?

Keith Welter
IBM Enterprise Networking Solutions
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 00767CF5882574B8_=-- --===============0274400936== 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 --===============0274400936==-- From ipsec-bounces@ietf.org Tue Sep 2 23:02:35 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17483A6BE9; Tue, 2 Sep 2008 23:02:35 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C683A6864 for ; Tue, 2 Sep 2008 23:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.627, 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 te25IT6a2qAd for ; Tue, 2 Sep 2008 23:02:32 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id AA0513A6935 for ; Tue, 2 Sep 2008 23:02:08 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m8361Ajl020045 for ; Wed, 3 Sep 2008 01:02:13 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 09:01:52 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Sep 2008 09:01:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Sep 2008 09:01:44 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201860ECA@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: My notes about IKEv2bis Thread-Index: AckNiorFvIbRVEb2R3C9J6GZAOMJow== From: To: X-OriginalArrivalTime: 03 Sep 2008 06:01:48.0010 (UTC) FILETIME=[8D10B4A0:01C90D8A] X-Nokia-AV: Clean Subject: [IPsec] My notes about IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 A while ago, I promised to send my list of "things that need to be looked at" about IKEv2bis to the mailing list. These are a mix of things that IMHO might be wrong, might benefit from some editorial changes/clarifications, things that just need some thinking to check if they're actually correct, and other random notes. -------- Abstract: needs rephrasing, include at least "IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs)" from RFC 4306 abstract. 1.5: Needs rephrasing, maybe merge with 2.21. 2.4: "receiving parties need to deal with it in other requests" Is this right, and how it's dealt with? And only requests, not responses? 2.5: Needs to clarify what exactly the message containing the INVALID_MAJOR_VERSION notification looks like (Fukumoto Atsushi's email 2007-06-12) 2.6 (near Clarif-2.1) and 2.6.1: needs rephrasing/more explanation (especially "MUST NOT fail" is unclear). 2.7 and 3.3.6, possible contradiction about INVALID_KE_PAYLOAD ("MUST again propose its full set of." vs. "SHOULD, however, continue to propose its full supported set") 2.7 and 3.3.6: text about INVALID_KE_PAYLOAD might need clarification: if none of the proposed groups is acceptable, NO_PROPOSA_CHOSEN is the correct notification (thread "Is this a good use of the INVALID_KE_PAYLOAD notification", May 2007) 2.8: might be wrong place for Clarif-5.9. 2.8: maybe clarify that when rekeying, the new SA might have different traffic selectors and algorithms than the old one? 2.8: probably should clarify what you do when you receive NO_PROPOSAL_CHOSEN during IKE_SA rekeying 2.9.1: might not fully consistent with RFC 4301 regarding decorrelated policy etc. (emails 2008-11-28 and 2008-11-30). 2.19: text about FAILED_CP_REQUIRED needs editing, and it's in wrong place (breaks flow of other text) 2.19 and 2.19.1: needs editing/rephrasing, perhaps merging these two sections to improve flow. 2.19 and 3.15: text about configuration payloads is still in two places; either merge or more clearly separate what goes where. 2.23: lots of bullets here, could be formatted in more readable way? 5: "implementation using EAP MUST also use strong authentication", change from RFC 4306, and "strong" is ambiguous (e.g. is "group secret" strong?) 8.2: RFCs 2251, 2486, and 3513, and FIPS 180-1, have been obsoleted by newer documents. Text doesn't cover all the exchange collisions from RFC 4718 Section 5.11 yet (but I doubt implementors will get many of those right anyway...). The document probably should talk about PAD in the context of IKE_SA authentication, and traffic selector authorization. INVALID_IKE_SPI needs some clarification (emails from 2007-10-17 to 2007-10-19) There should be text about how a protected INVALID_SPI notification is processed. Mapping of incoming IKE packets to IKE_SA needs clarification (maybe in 2.1, 2.6 or 3.1): it's done using the recipient SPI only, not e.g. using the source IP address. The text about transport mode NAT-T isn't right: it really needs to discuss how the SPD and TS payloads work, and it seems incremental checksum fixup can't work as described (I have longer notes about this topic based on discussions with Tero in December 2007). ADDITIONAL_TS_POSSIBLE probably needs clarification: it seems the recipient can't really use this for anything else than logging/debugging, if even that (thread August 2008) Do traffic selectors containing port numbers make sense if the protocol is 0? (thread August 2008) Would it be useful to have a separate section describing "CHILD_SA attributes" like ESN, ESP_TFC_PADDING_NOT_SUPPORTED, IPCOMP_SUPPORTED, NON_FIRST_FRAGMENTS_ALSO, etc.? Do we need text about simultaneous reauthentication and/or simultaneous initiation of IKE_SAs? (email 2007-08-21, thread June 2008) Should we support OPAQUE protocol selectors for IPv6 (thread May/June 2007) Should we move features with no known implementations from the main text to an appendix? The document will eventually need a "changes to RFC 4306" (or at least "changes that implementors of RFC 4306 should look at") section. Tero's email on 2008-07-29 had bunch of things. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 2 23:52:45 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF32F3A6BF9; Tue, 2 Sep 2008 23:52:45 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8CFD3A6A90 for ; Tue, 2 Sep 2008 23:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIPavejIa50N for ; Tue, 2 Sep 2008 23:52:43 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 5455F3A6A61 for ; Tue, 2 Sep 2008 23:52:43 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7D144294004; Wed, 3 Sep 2008 09:52:36 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3B37A294001; Wed, 3 Sep 2008 09:52:35 +0300 (IDT) Received: from [172.31.21.182] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m836qYOx007092; Wed, 3 Sep 2008 09:52:34 +0300 (IDT) Message-Id: <08A45D15-DB00-4642-BA6F-EECE7E549A27@checkpoint.com> From: Yoav Nir To: Keith Welter In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 3 Sep 2008 09:52:34 +0300 References: X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org Subject: Re: [IPsec] Question about deleting a half-open child SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1142980998==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1142980998== Content-Type: multipart/alternative; boundary=Apple-Mail-2--548098082 --Apple-Mail-2--548098082 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Keith On Sep 3, 2008, at 12:34 AM, Keith Welter wrote: > Suppose the initiator sends an SA payload that contains both an AH > and ESP proposal. Before receiving the response, the initiator > decides to close the half-open child SA. I assume that the > informational request should include two delete payloads, one for AH > and one for ESP. Is that correct? There's no such thing as a half-open Child SA. What you describe is a proposal that the initiator still hasn't received a reply for. There is no SA yet, at least on the initiator side. In fact the initiator cannot know at this point whether or not an SA is even going to be established, because the peer may reject the proposal, or else may have rebooted. For this reason, it is not appropriate at this point to begin constructing the Informational message with the DELETE payloads, as this message will be nonsensical if the CCSA request is rejected. Instead, the initiator must wait until a response is received. Then it can either (1) do nothing, if the request was rejected or (2) delete the one SA that actually got created. Doing it as you propose, would definitely result in a DELETE message for a non-existing SA, which is bad, although I don't see any text in RFC 4306 or 4306bis about what action the responder should take when it receives such a request. It's probably not delete-the-ike-sa bad, but still something you shouldn't do. > Related to that question, I don't see a requirement that all > proposals in an SA payload have the same SPI. So, in this example, > it would be permissible for the AH and ESP proposals to have > different SPIs. Is that correct? Yes, that's correct. The SA payload is ready to offer protocols of variable SPI size, so while both AH and ESP use a 4-byte SPI, maybe someday we'll have superESP with an 8-byte SPI. In that case, an SA payload with two proposals, one for AH and the other for superESP would have to have different SPIs. As it is, it's still possible to use different values, but it's not a requirement. --Apple-Mail-2--548098082 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Keith

On = Sep 3, 2008, at 12:34 AM, Keith Welter = wrote:

Suppose the initiator sends an SA payload that = contains both an AH and ESP proposal.  Before receiving the = response, the initiator decides to close the half-open child SA.  I = assume that the informational request should include two delete = payloads, one for AH and one for ESP.  Is that correct? =

There's no such thing as a half-open Child = SA. What you describe is a proposal that the initiator still hasn't = received a reply for. There is no SA yet, at least on the initiator = side. In fact the initiator cannot know at this point whether or not an = SA is even going to be established, because the peer may reject the = proposal, or else may have rebooted.

For this = reason, it is not appropriate at this point to begin constructing the = Informational message with the DELETE payloads, as this message will be = nonsensical if the CCSA request is rejected. Instead, the initiator must = wait until a response is received. Then it can either (1) do nothing, if = the request was rejected or (2) delete the one SA that actually got = created.

Doing it as you propose, would = definitely result in a DELETE message for a non-existing SA, which is = bad, although I don't see any text in RFC 4306 or 4306bis about what = action the responder should take when it receives such a request. It's = probably not delete-the-ike-sa bad, but still something you shouldn't = do.

Related to that question, I don't see a requirement = that all proposals in an SA payload have the same SPI.  So, in this = example, it would be permissible for the AH and ESP proposals to have = different SPIs.  Is that correct? =

Yes, that's correct. The SA payload is = ready to offer protocols of variable SPI size, so while both AH and ESP = use a 4-byte SPI, maybe someday we'll have superESP with an 8-byte SPI. = In that case, an SA payload with two proposals, one for AH and the other = for superESP would have to have different SPIs. As it is, it's still = possible to use different values, but it's not a = requirement.


= --Apple-Mail-2--548098082-- --===============1142980998== 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 --===============1142980998==-- From ipsec-bounces@ietf.org Wed Sep 3 04:14:31 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D65333A6CAC; Wed, 3 Sep 2008 04:14:31 -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 673DD3A6CAC for ; Wed, 3 Sep 2008 04:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 lyEeBfJ9DtHY for ; Wed, 3 Sep 2008 04:14:30 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 260843A6AAC for ; Wed, 3 Sep 2008 04:14:29 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m83BEWYd016413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2008 14:14:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m83BETqR024330; Wed, 3 Sep 2008 14:14:29 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18622.29077.836239.85063@fireball.kivinen.iki.fi> Date: Wed, 3 Sep 2008 14:14:29 +0300 From: Tero Kivinen To: Keith Welter In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: ipsec@ietf.org Subject: [IPsec] Question about deleting a half-open child SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Keith Welter writes: > Suppose the initiator sends an SA payload that contains both an AH and ESP > proposal. Before receiving the response, the initiator decides to close > the half-open child SA. I assume that the informational request should > include two delete payloads, one for AH and one for ESP. Is that correct? There is no really working method to delete the SA until it is created, i.e. you cannot delete half open SAs. Even if you send delete notifications, it might be possible that the responder has not yet seen the SA creation packet, thus delete SA would refer to unknown SPIs, and responder would reply with error to both of them. The best is simply wait for the SA negotiation to finish and delete it after that. This is anyways required if the other end only supports window size of 1, as you cannot send delete notifacation before you get reply back to your create child SA exchange. > Related to that question, I don't see a requirement that all proposals in > an SA payload have the same SPI. So, in this example, it would be > permissible for the AH and ESP proposals to have different SPIs. Is that > correct? Yes. The SPIs does not need to be same. There might be for example some implementation which could even allocate the SPIs for different protocols on different ranges. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 4 10:23:10 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 739643A6A8F; Thu, 4 Sep 2008 10:23: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 8E7B83A6A14 for ; Thu, 4 Sep 2008 10:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 sBn5ghlOTLah for ; Thu, 4 Sep 2008 10:23:08 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 196793A68C8 for ; Thu, 4 Sep 2008 10:23:08 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m84HNEIn017566 for ; Thu, 4 Sep 2008 13:23:14 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id m84HNEDq145996 for ; Thu, 4 Sep 2008 11:23:14 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m84HNEvS000329 for ; Thu, 4 Sep 2008 11:23:14 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m84HNET6000326 for ; Thu, 4 Sep 2008 11:23:14 -0600 In-Reply-To: To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 09/04/2008 10:23:10 AM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 09/04/2008 10:23:10 AM, Serialize complete at 09/04/2008 10:23:10 AM, S/MIME Sign failed at 09/04/2008 10:23:10 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_07222008NPHF42 | August 5, 2008) at 09/04/2008 11:23:14, Serialize complete at 09/04/2008 11:23:14 Message-ID: Date: Thu, 4 Sep 2008 10:23:13 -0700 Subject: Re: [IPsec] IPsec Digest, Vol 53, Issue 3 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1701435515==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1701435515== Content-Type: multipart/alternative; boundary="=_alternative 005F8172882574BA_=" This is a multipart message in MIME format. --=_alternative 005F8172882574BA_= Content-Type: text/plain; charset="US-ASCII" Thanks Yoav. I have a couple more questions inline below. > Hi Keith > > On Sep 3, 2008, at 12:34 AM, Keith Welter wrote: > > > Suppose the initiator sends an SA payload that contains both an AH > > and ESP proposal. Before receiving the response, the initiator > > decides to close the half-open child SA. I assume that the > > informational request should include two delete payloads, one for AH > > and one for ESP. Is that correct? > > There's no such thing as a half-open Child SA. What you describe is a > proposal that the initiator still hasn't received a reply for. There > is no SA yet, at least on the initiator side. In fact the initiator > cannot know at this point whether or not an SA is even going to be > established, because the peer may reject the proposal, or else may > have rebooted. I'm curious why you say there's no such thing as a half-open child SA. If an implementation creates the child SA state in the process of sending the CCSA request then it seems like that it would be reasonable to call this child SA half-open until the CCSA response is received. RFC 4306 section 2.6 uses the term "half-open" to describe IKE SAs so I'm confused why the same term couldn't be applied to a child SA. Are you implying that an implementation should not create any child SA state until the CCSA response is received? > > For this reason, it is not appropriate at this point to begin > constructing the Informational message with the DELETE payloads, as > this message will be nonsensical if the CCSA request is rejected. > Instead, the initiator must wait until a response is received. Then it > can either (1) do nothing, if the request was rejected or (2) delete > the one SA that actually got created. > > Doing it as you propose, would definitely result in a DELETE message > for a non-existing SA, which is bad, although I don't see any text in > RFC 4306 or 4306bis about what action the responder should take when > it receives such a request. It's probably not delete-the-ike-sa bad, > but still something you shouldn't do. Ok, thanks for the clafication. > > > Related to that question, I don't see a requirement that all > > proposals in an SA payload have the same SPI. So, in this example, > > it would be permissible for the AH and ESP proposals to have > > different SPIs. Is that correct? > > Yes, that's correct. The SA payload is ready to offer protocols of > variable SPI size, so while both AH and ESP use a 4-byte SPI, maybe > someday we'll have superESP with an 8-byte SPI. In that case, an SA > payload with two proposals, one for AH and the other for superESP > would have to have different SPIs. As it is, it's still possible to > use different values, but it's not a requirement. Ok, I want to probe a little deeper here. RFC 4301 section 4.1 says: "For an SA used to carry unicast traffic, the Security Parameters Index (SPI) by itself suffices to specify an SA. (For information on the SPI, see Appendix A and the AH and ESP specifications [Ken05b, Ken05a].) However, as a local matter, an implementation may choose to use the SPI in conjunction with the IPsec protocol type (AH or ESP) for SA identification." Suppose an implementation choses to use the SPI in conjunction with the IPsec protocol for IPsec SA identification. Such an implementation could have multiple IPsec SAs with the same SPI but different protocols. It seems like this could cause interoperability problems if these SAs are negotiated with a peer that uses only the SPI for SA identification. If that assumption is correct, it seems like an implementation should avoid using the same SPI, differentiated only by protocol, with a given peer. In other words, if an implementation uses SPI x for an ESP SA it should not attempt to use SPI x for an AH SA with the same peer simultaneously. Would you agree? --=_alternative 005F8172882574BA_= Content-Type: text/html; charset="US-ASCII"
Thanks Yoav.  I have a couple more questions inline below.

> Hi Keith
>
> On Sep 3, 2008, at 12:34 AM, Keith Welter wrote:
>
> > Suppose the initiator sends an SA payload that contains both an AH  
> > and ESP proposal.  Before receiving the response, the initiator  
> > decides to close the half-open child SA.  I assume that the  
> > informational request should include two delete payloads, one for AH  
> > and one for ESP.  Is that correct?
>
> There's no such thing as a half-open Child SA. What you describe is a  
> proposal that the initiator still hasn't received a reply for. There  
> is no SA yet, at least on the initiator side. In fact the initiator  
> cannot know at this point whether or not an SA is even going to be  
> established, because the peer may reject the proposal, or else may  
> have rebooted.
I'm curious why you say there's no such thing as a half-open child SA.
If an implementation creates the child SA state in the process of
sending the CCSA request then it seems like that it would be reasonable
to call this child SA half-open until the CCSA response is received.
RFC 4306 section 2.6 uses the term "half-open" to describe IKE SAs so
I'm confused why the same term couldn't be applied to a child SA.
Are you implying that an implementation should not create any child SA
state until the CCSA response is received?

>
> For this reason, it is not appropriate at this point to begin  
> constructing the Informational message with the DELETE payloads, as  
> this message will be nonsensical if the CCSA request is rejected.  
> Instead, the initiator must wait until a response is received. Then it  
> can either (1) do nothing, if the request was rejected or (2) delete  
> the one SA that actually got created.
>
> Doing it as you propose, would definitely result in a DELETE message  
> for a non-existing SA, which is bad, although I don't see any text in  
> RFC 4306 or 4306bis about what action the responder should take when  
> it receives such a request. It's probably not delete-the-ike-sa bad,  
> but still something you shouldn't do.
Ok, thanks for the clafication.

>
> > Related to that question, I don't see a requirement that all  
> > proposals in an SA payload have the same SPI.  So, in this example,  
> > it would be permissible for the AH and ESP proposals to have  
> > different SPIs.  Is that correct?
>
> Yes, that's correct. The SA payload is ready to offer protocols of  
> variable SPI size, so while both AH and ESP use a 4-byte SPI, maybe  
> someday we'll have superESP with an 8-byte SPI. In that case, an SA  
> payload with two proposals, one for AH and the other for superESP  
> would have to have different SPIs. As it is, it's still possible to  
> use different values, but it's not a requirement.
Ok, I want to probe a little deeper here.  RFC 4301 section 4.1 says:
   "For an SA used to carry unicast traffic, the Security Parameters
  Index (SPI) by itself suffices to specify an SA.  (For information on
  the SPI, see Appendix A and the AH and ESP specifications [Ken05b,
  Ken05a].)  However, as a local matter, an implementation may choose
  to use the SPI in conjunction with the IPsec protocol type (AH or
  ESP) for SA identification."
Suppose an implementation choses to use the SPI in conjunction with
the IPsec protocol for IPsec SA identification.  Such an implementation
could have multiple IPsec SAs with the same SPI but different protocols.
It seems like this could cause interoperability problems if these SAs
are negotiated with a peer that uses only the SPI for SA
identification.  If that assumption is correct, it seems like an
implementation should avoid using the same SPI, differentiated only by
protocol, with a given peer.  In other words, if an implementation
uses SPI x for an ESP SA it should not attempt to use SPI x for an AH
SA with the same peer simultaneously.  Would you agree?
--=_alternative 005F8172882574BA_=-- --===============1701435515== 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 --===============1701435515==-- From ipsec-bounces@ietf.org Mon Sep 8 02:18:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCE4F28C14E; Mon, 8 Sep 2008 02:18:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40AB928C14E for ; Mon, 8 Sep 2008 02:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blEO0LCLhaaC for ; Mon, 8 Sep 2008 02:18:21 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id DB38128C0F8 for ; Mon, 8 Sep 2008 02:18:20 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9EB25294003; Mon, 8 Sep 2008 12:18:22 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B43D2294001; Mon, 8 Sep 2008 12:18:21 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m889ILOx017824; Mon, 8 Sep 2008 12:18:21 +0300 (IDT) Message-Id: <5129ACE5-A8DA-416A-AF0D-AACDAC44F5BE@checkpoint.com> From: Yoav Nir To: Keith Welter In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 8 Sep 2008 12:18:21 +0300 References: X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec Digest, Vol 53, Issue 3 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1227206983==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1227206983== Content-Type: multipart/alternative; boundary=Apple-Mail-3--107350812 --Apple-Mail-3--107350812 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sep 4, 2008, at 8:23 PM, Keith Welter wrote: > > Thanks Yoav. I have a couple more questions inline below. > > > Hi Keith > > > > On Sep 3, 2008, at 12:34 AM, Keith Welter wrote: > > > > > Suppose the initiator sends an SA payload that contains both an AH > > > and ESP proposal. Before receiving the response, the initiator > > > decides to close the half-open child SA. I assume that the > > > informational request should include two delete payloads, one > for AH > > > and one for ESP. Is that correct? > > > > There's no such thing as a half-open Child SA. What you describe > is a > > proposal that the initiator still hasn't received a reply for. There > > is no SA yet, at least on the initiator side. In fact the initiator > > cannot know at this point whether or not an SA is even going to be > > established, because the peer may reject the proposal, or else may > > have rebooted. > I'm curious why you say there's no such thing as a half-open child SA. > If an implementation creates the child SA state in the process of > sending the CCSA request then it seems like that it would be > reasonable > to call this child SA half-open until the CCSA response is received. > RFC 4306 section 2.6 uses the term "half-open" to describe IKE SAs so > I'm confused why the same term couldn't be applied to a child SA. > Are you implying that an implementation should not create any child SA > state until the CCSA response is received? The half-open SA in RFC 4306 is an IKE SA, and it is on the responder, not the initiator. The meaning of the term is that the IKE SA already has keys, but is not yet authenticated. A child SA is just about exchanging keys, so there's no middle state. But this is just terminology. > > > For this reason, it is not appropriate at this point to begin > > constructing the Informational message with the DELETE payloads, as > > this message will be nonsensical if the CCSA request is rejected. > > Instead, the initiator must wait until a response is received. > Then it > > can either (1) do nothing, if the request was rejected or (2) delete > > the one SA that actually got created. > > > > Doing it as you propose, would definitely result in a DELETE message > > for a non-existing SA, which is bad, although I don't see any text > in > > RFC 4306 or 4306bis about what action the responder should take when > > it receives such a request. It's probably not delete-the-ike-sa bad, > > but still something you shouldn't do. > Ok, thanks for the clafication. > > > > > > Related to that question, I don't see a requirement that all > > > proposals in an SA payload have the same SPI. So, in this > example, > > > it would be permissible for the AH and ESP proposals to have > > > different SPIs. Is that correct? > > > > Yes, that's correct. The SA payload is ready to offer protocols of > > variable SPI size, so while both AH and ESP use a 4-byte SPI, maybe > > someday we'll have superESP with an 8-byte SPI. In that case, an SA > > payload with two proposals, one for AH and the other for superESP > > would have to have different SPIs. As it is, it's still possible to > > use different values, but it's not a requirement. > Ok, I want to probe a little deeper here. RFC 4301 section 4.1 says: > "For an SA used to carry unicast traffic, the Security Parameters > Index (SPI) by itself suffices to specify an SA. (For information > on > the SPI, see Appendix A and the AH and ESP specifications [Ken05b, > Ken05a].) However, as a local matter, an implementation may choose > to use the SPI in conjunction with the IPsec protocol type (AH or > ESP) for SA identification." > Suppose an implementation choses to use the SPI in conjunction with > the IPsec protocol for IPsec SA identification. Such an > implementation > could have multiple IPsec SAs with the same SPI but different > protocols. > It seems like this could cause interoperability problems if these SAs > are negotiated with a peer that uses only the SPI for SA > identification. If that assumption is correct, it seems like an > implementation should avoid using the same SPI, differentiated only by > protocol, with a given peer. In other words, if an implementation > uses SPI x for an ESP SA it should not attempt to use SPI x for an AH > SA with the same peer simultaneously. Would you agree? That is not necessary, as each IKE peer chooses the SPI for the INBOUND SA. It does not choose the SPI for the outbound SA, so it can't make any assumptions about the outbound SPI being unique per- host, unique per-protocol, or unique in any sense of the word. The policy leads to the selection of the outbound SA, and the SPI is just a property of that SA. For inbound SAs, an implementation should choose a unique SPI (at least per protocol) so that it can distinguish which SA is associated with that SPI. It should be globally unique rather than per-peer, so that we can allow mobility. In other words, in inbound processing, the SPI (or SPI + protocol) is the key to the table. In outbound processing, it's just a value. --Apple-Mail-3--107350812 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Sep 4, 2008, at 8:23 PM, = Keith Welter wrote:


> Hi Keith
>
> On Sep 3, 2008, at 12:34 AM, Keith = Welter wrote:
>
> > Suppose the initiator sends an SA payload = that contains both an AH  
> > and ESP proposal.  Before = receiving the response, the initiator  
> > decides to close = the half-open child SA.  I assume that the  
> > = informational request should include two delete payloads, one for AH =  
> > and one for ESP.  Is that correct?
>
> = There's no such thing as a half-open Child SA. What you describe is a =  
> proposal that the initiator still hasn't received a reply = for. There  
> is no SA yet, at least on the initiator side. In = fact the initiator  
> cannot know at this point whether or not = an SA is even going to be  
> established, because the peer may = reject the proposal, or else may  
> have rebooted. =
I'm curious why you = say there's no such thing as a half-open child SA. =
If an = implementation creates the child SA state in the process of =
sending the CCSA = request then it seems like that it would be reasonable =
to call this child = SA half-open until the CCSA response is received. =
RFC 4306 section = 2.6 uses the term "half-open" to describe IKE SAs so =
I'm confused why = the same term couldn't be applied to a child SA. =
Are you implying = that an implementation should not create any child SA =
state until the = CCSA response is received?

The half-open SA in RFC 4306 is an = IKE SA, and it is on the responder, not the initiator. The meaning of = the term is that the IKE SA already has keys, but is not yet = authenticated. A child SA is just about exchanging keys, so there's no = middle state. But this is just terminology.
 
> For this reason, it is not = appropriate at this point to begin  
> constructing the = Informational message with the DELETE payloads, as  
> this = message will be nonsensical if the CCSA request is rejected.  
= > Instead, the initiator must wait until a response is received. Then it =  
> can either (1) do nothing, if the request was rejected or = (2) delete  
> the one SA that actually got created.
>
= > Doing it as you propose, would definitely result in a DELETE message =  
> for a non-existing SA, which is bad, although I don't see = any text in  
> RFC 4306 or 4306bis about what action the = responder should take when  
> it receives such a request. It's = probably not delete-the-ike-sa bad,  
> but still something you = shouldn't do.
Ok, thanks for the clafication.

>
> > Related to that = question, I don't see a requirement that all  
> > proposals in = an SA payload have the same SPI.  So, in this example,  
> = > it would be permissible for the AH and ESP proposals to have =  
> > different SPIs.  Is that correct?
>
> Yes, = that's correct. The SA payload is ready to offer protocols of  
= > variable SPI size, so while both AH and ESP use a 4-byte SPI, maybe =  
> someday we'll have superESP with an 8-byte SPI. In that = case, an SA  
> payload with two proposals, one for AH and the = other for superESP  
> would have to have different SPIs. As it = is, it's still possible to  
> use different values, but it's = not a requirement.
Ok, I want to probe a little deeper here. =  RFC 4301 section 4.1 says:
   "For an SA used to carry unicast traffic, = the Security Parameters
  Index (SPI) by itself suffices to = specify an SA.  (For information on
  the SPI, see = Appendix = A = and the AH and ESP specifications [Ken05b,
  Ken05a].) =  However, as a local matter, an implementation may choose
=   to use the SPI in conjunction with the IPsec protocol type (AH = or
  ESP) for SA identification."
Suppose an implementation choses to use the = SPI in conjunction with
the IPsec protocol for IPsec SA = identification.  Such an implementation
could have multiple IPsec SAs = with the same SPI but different protocols.
It seems like this could cause = interoperability problems if these SAs
are negotiated with a peer that = uses only the SPI for SA
identification.  If that assumption is = correct, it seems like an
implementation should avoid using the same = SPI, differentiated only by
protocol, with a given peer.  In other = words, if an implementation
uses SPI x for an ESP SA it should not = attempt to use SPI x for an AH
SA with the same peer simultaneously. =  Would you agree?

That is not necessary, as each IKE peer chooses the SPI for the = INBOUND SA. It does not choose the SPI for the outbound SA, so it can't = make any assumptions about the outbound SPI being unique per-host, = unique per-protocol, or unique in any sense of the word. The policy = leads to the selection of the outbound SA, and the SPI is just a = property of that SA.  For inbound SAs, an implementation should = choose a unique SPI (at least per protocol) so that it can distinguish = which SA is associated with that SPI. It should be globally unique = rather than per-peer, so that we can allow = mobility.
In other words, in inbound processing, the SPI (or SPI + = protocol) is the key to the table. In outbound processing, it's just a = value.

= --Apple-Mail-3--107350812-- --===============1227206983== 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 --===============1227206983==-- From ipsec-bounces@ietf.org Mon Sep 8 06:35:15 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D0228C0E6; Mon, 8 Sep 2008 06:35:15 -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 067183A6A46; Mon, 8 Sep 2008 06:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-it-zSKjAQu; Mon, 8 Sep 2008 06:35:08 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7C3023A695C; Mon, 8 Sep 2008 06:35:07 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 61A6B294004; Mon, 8 Sep 2008 16:35:09 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 42834294001; Mon, 8 Sep 2008 16:35:08 +0300 (IDT) Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id m88DZ7P4018340; Mon, 8 Sep 2008 16:35:07 +0300 (IDT) Message-Id: <674C0769-E278-4A59-A490-7634F2B0FF83@checkpoint.com> From: Yoav Nir To: pezeshki_jonah@bah.com, ertekin_emre@bah.com, jasani_rohan@bah.com, christou_chris@bah.com, cabo@tzi.org Mime-Version: 1.0 (Apple Message framework v928.1) Date: Mon, 8 Sep 2008 16:35:00 +0300 X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org, rohc@ietf.org Subject: [IPsec] Review of the RoHC over IPsec drafts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0054972141==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0054972141== Content-Type: multipart/alternative; boundary=Apple-Mail-5--91951414 --Apple-Mail-5--91951414 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi all At Yaron's request I've gone over the three drafts related to RoHC over IPsec tunnels. The three drafts are: draft-ietf-rohc-hcoipsec - integration of RoHC over IPsec SAs draft-ietf-rohc-ikev2-extensions-hcoipsec - IKEv2 extensions to negotiate RoHC over IPsec draft-ietf-rohc-ipsec-extensions-hcoipsec - IPsec extenstions Overall the drafts drafts seem good, and in my opinion could offer a substantial benefit for IPsec tunnels, especially where the bandwidth to one or both endpoints is constrained. Here's my comments. The IKE & IPsec drafts talk about the use of integrity algorithms to verify that decompression was successful. According to section 2.1 of the IKEv2 draft, these algorithms are the same algorithms (with associated keys) as those used in IPsec. I can't figure out why you would want this. The entire packet, compressed header and data included, is already integrity protected by IPsec. An attacker can't flip any bits because of the ESP ICV, so the RoHC ICV is simply there to detect decompression errors. I don't see why we need to exceed the recommendation in RFC 4995 to use CRC. Even if you have decided that you want to upgrade error-detection ICV to a cryptographically strong one, HMAC doesn't offer any benefit that I can see - you could use straight MD5 or SHA-1 without any key, but I still don't see why CRC is not good enough. The introduction to draft-ietf-rohc-hcoipsec-08 says that "However, since current specifications for RoHC detail its operation on a hop-by- hop basis, it may require extensions to enable its operation over IPsec SAs.". This is not explained later. An IPsec tunnel is very much like a single hop (for the tunneled traffic), so I don't see why special extensions would be needed. Section 4 of draft-ietf-rohc-hcoipsec-08 needs some rewording. Is the second sentence about the TFC feature of IPsec? About the padding feature of RoHC? About the problem in general? You might want to add discussion about whether it is recommended to use RoHC padding or IPsec TFC to avoid the problem. Section 5.2 of draft-ietf-rohc-hcoipsec (last paragraph) has some strange text about ESP-NULL, which I don't understand. Why should ESP- NULL be any different than any other ESP method? There is, however, something to consider about ESP-NULL. Some middleboxes may want to inspect traffic that is encrypted with ESP- NULL (see draft-grewal-ipsec-traffic-visibility-00). It's possible that RoHC will cause those middleboxes to drop all traffic that is compressed, because they won't be able to parse the compressed headers. Section 6.1.2 says "f the RoHC protocol requires bi-directional communications, two SAs must be instantiated between the IPsec implementations." This is a non-issue, since IKE creates SAs in pairs anyways. So I don't see the point in the recommendation to use only non-feedback profiles. You may want to mention that the decompressor needs to relay feedback to the appropriate compressor Regarding the IKEv2 draft, I only have several comments about section 2.1: It's common for IKEv2 drafts to have at the beginning a figure of the entire payload and then explain the various fields. The explanation of the "Critical" bit is incorrect. It does not refer to the content of the payload, only to the type of the payload, in this case "Notify". The bit MUST be off for Notify payloads, because all IKEv2 implementations must support it. Similarly, there's not reason to define the content of the reserved bits, because they're the same as for any payload. Protocol ID field: According to the first paragraph of 2.1, the notification is only in CCSA and IKE_AUTH. So there's no case where this notification is used outside of the creation of the child SA, and there's no need to ever set the protocol ID. --Apple-Mail-5--91951414 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi all

At Yaron's request I've gone over the three drafts related to = RoHC over IPsec tunnels.

The three drafts = are:
  • draft-ietf-rohc-hcoipsec - integration of = RoHC over IPsec SAs
  • draft-ietf-rohc-ikev2-extensions-hcoipsec - IKEv2 extensions to = negotiate RoHC over IPsec
  • draft-ietf-rohc-ipsec-extensions-hcoipsec - = IPsec extenstions

Overall the drafts drafts seem good, and = in my opinion could offer a substantial benefit for IPsec tunnels, = especially where the bandwidth to one or both endpoints is constrained. = Here's my comments.

  • The IKE & IPsec drafts talk about the use of integrity = algorithms to verify that decompression was successful. According to = section 2.1 of the IKEv2 draft, these algorithms are the same algorithms = (with associated keys) as those used in IPsec. I can't figure out why = you would want this. The entire packet, compressed header and data = included, is already integrity protected by IPsec. An attacker can't = flip any bits because of the ESP ICV, so the RoHC ICV is simply there to = detect decompression errors. I don't see why we need to exceed the = recommendation in RFC 4995 to use CRC. Even if you have decided that you = want to upgrade error-detection ICV to a cryptographically strong one, = HMAC doesn't offer any benefit that I can see - you could use straight = MD5 or SHA-1 without any key, but I still don't see why CRC is not good = enough.
  • The introduction to draft-ietf-rohc-hcoipsec-08 says that = "However, since current specifications for RoHC detail its operation on = a hop-by-hop basis, it may require extensions to enable = its operation over IPsec SAs.". This is not explained later. An IPsec = tunnel is very much like a single hop (for the tunneled traffic), so I = don't see why special extensions would be needed. =
  • Section 4 of draft-ietf-rohc-hcoipsec-08 needs some rewording. Is = the second sentence about the TFC feature of IPsec? About the padding = feature of RoHC? About the problem in general? You might want to add = discussion about whether it is recommended to use RoHC padding or IPsec = TFC to avoid the problem.
  • Section 5.2 of draft-ietf-rohc-hcoipsec (last = paragraph) has some strange text about ESP-NULL, which I don't = understand. Why should ESP-NULL be any different than any other ESP = method?
  • There is, however, something to consider about ESP-NULL. Some = middleboxes may want to inspect traffic that is encrypted with ESP-NULL = (see draft-grewal-ipsec-traffic-visibility-00). It's possible that RoHC = will cause those middleboxes to drop all traffic that is compressed, = because they won't be able to parse the compressed = headers.
  • Section 6.1.2 says "f the RoHC protocol requires bi-directional = communications, two SAs must be instantiated between the IPsec implementations." This is = a non-issue, since IKE creates SAs in pairs anyways. So I don't see the = point in the recommendation to use only non-feedback profiles. You may = want to mention that the decompressor needs to relay feedback to the = appropriate compressor

Regarding the IKEv2 draft, I only have = several comments about section 2.1:
  • It's common for IKEv2 drafts to have at the beginning a figure of = the entire payload and then explain the various fields. =
  • The explanation of = the "Critical" bit is incorrect. It does not refer to the content of the = payload, only to the type of the payload, in this case "Notify". The bit = MUST be off for Notify payloads, because all IKEv2 implementations must = support it. Similarly, there's not reason to define the content of the = reserved bits, because they're the same as for any = payload.
  • Protocol ID field: According to the first paragraph of 2.1, the = notification is only in CCSA and IKE_AUTH. So there's no case where this = notification is used outside of the creation of the child SA, and = there's no need to ever set the protocol = ID.

 
= --Apple-Mail-5--91951414-- --===============0054972141== 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 --===============0054972141==-- From ipsec-bounces@ietf.org Tue Sep 9 02:43:07 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552CF3A6C94; Tue, 9 Sep 2008 02:43: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 8071B3A6C94 for ; Tue, 9 Sep 2008 02:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=0.534, 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 uWGRu4AjTSnJ for ; Tue, 9 Sep 2008 02:43:04 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 94FCB3A6C15 for ; Tue, 9 Sep 2008 02:43:04 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m899gUWu021293 for ; Tue, 9 Sep 2008 04:43:07 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Sep 2008 12:42:52 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Sep 2008 12:42:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Sep 2008 12:42:52 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720191E36E@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] CDRs for ROHCoIPSec Thread-Index: AckRwPxxnYHZ3+gYTCKouQT916qqWAAny7EA From: To: X-OriginalArrivalTime: 09 Sep 2008 09:42:52.0424 (UTC) FILETIME=[6DC02880:01C91260] X-Nokia-AV: Clean Subject: [IPsec] FW: [rohc] CDRs for ROHCoIPSec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 FYI -- the IPsec work in ROHC WG is nearing completion, and before starting WGLC, they're looking for people who commit to review the drafts. Some folks in IPSECME WG might be interested... Best regards, Pasi > -----Original Message----- > From: rohc-bounces@ietf.org [mailto:rohc-bounces@ietf.org] On > Behalf Of ext Carl Knutsson > Sent: 08 September, 2008 17:41 > To: rohc@ietf.org > Subject: [rohc] CDRs for ROHCoIPSec > > rohcers, all, > > The ROHCoIPSec drafts are soon up for a WG Last-Call. In the ROHC WG, > we usually appoint committed document reviewers (CDRs) for most of our > documents. We already have one (or two) candidates, but I am > now asking > for volunteers from the rohc WG (with ROHC knowledge) to serve as CDRs > for this document. Candidates with prior ROHC expirienc is > prefered, but it > could also be a good oppertunity for newer members contribute. > > The CDRs commit to send a review to of document to the authors and the > rohc-list before the dead-line of the WG Last-Call (in return for > being cited as an official CDR in in the acknowledgment section of > the RFC. If you are interested please send me an email. > > > Best Regards, > Carl Knutsson, ROHC WG Chair > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www.ietf.org/mailman/listinfo/rohc > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 05:35:40 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0422D3A6BAD; Tue, 9 Sep 2008 05:35: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 A4C8D3A6BAD; Tue, 9 Sep 2008 05:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 sDRSbdiiZQ2Y; Tue, 9 Sep 2008 05:35:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 1AD233A699A; Tue, 9 Sep 2008 05:35:36 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m89CYvk2011625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 15:34:57 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m89CYtoJ014056; Tue, 9 Sep 2008 15:34:55 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18630.28015.487667.355981@fireball.kivinen.iki.fi> Date: Tue, 9 Sep 2008 15:34:55 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <674C0769-E278-4A59-A490-7634F2B0FF83@checkpoint.com> References: <674C0769-E278-4A59-A490-7634F2B0FF83@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 4 min X-Total-Time: 8 min Cc: rohc@ietf.org, ertekin_emre@bah.com, pezeshki_jonah@bah.com, jasani_rohan@bah.com, ipsec@ietf.org, christou_chris@bah.com, cabo@tzi.org Subject: [IPsec] Review of the RoHC over IPsec drafts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > The IKE & IPsec drafts talk about the use of integrity algorithms to > verify that decompression was successful. According to section 2.1 of > the IKEv2 draft, these algorithms are the same algorithms (with > associated keys) as those used in IPsec. I can't figure out why you > would want this. The entire packet, compressed header and data > included, is already integrity protected by IPsec. An attacker can't > flip any bits because of the ESP ICV, so the RoHC ICV is simply there > to detect decompression errors. I don't see why we need to exceed the > recommendation in RFC 4995 to use CRC. Even if you have decided that > you want to upgrade error-detection ICV to a cryptographically strong > one, HMAC doesn't offer any benefit that I can see - you could use > straight MD5 or SHA-1 without any key, but I still don't see why CRC > is not good enough. Attacker cannot flip bits, but it can remove entire packets. As the rohc is statefull compression, removing packets will affect the state of the decompressor, thus by removing selected packets from the stream attacker can cause some future packets to be authenticated and decrypted correctly, but decompressed after that by using wrong state, thus causing the end packets to be different from the original packet. As the IPsec is there to protect that there cannot be any modifications to the packets, this implies that we also want to detect this kind of attacks. Because of this we do need some kind of message authentication code after the decompression to make sure the packet matches the packet that was sent. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 05:41:47 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B42E528C18E; Tue, 9 Sep 2008 05:41: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 7569F28C18E for ; Tue, 9 Sep 2008 05:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 0O8eI2CZSI+k for ; Tue, 9 Sep 2008 05:41:45 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 16F6128C183 for ; Tue, 9 Sep 2008 05:41:44 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m89CfkGB028911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Sep 2008 15:41:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m89Cfkgj008795 for ipsec@ietf.org; Tue, 9 Sep 2008 15:41:46 +0300 (EEST) Resent-From: kivinen@iki.fi X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Resent-Message-ID: <18630.28422.372138.284056@fireball.kivinen.iki.fi> Resent-Date: Tue, 9 Sep 2008 15:41:42 +0300 Resent-To: ipsec@ietf.org Message-ID: <18624.64373.830908.802178@fireball.kivinen.iki.fi> In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.1.1 From: Tero Kivinen To: Keith Welter Date: Fri, 5 Sep 2008 12:27:17 +0300 MIME-Version: 1.0 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec Digest, Vol 53, Issue 3 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Keith Welter writes: > I'm curious why you say there's no such thing as a half-open child SA. > If an implementation creates the child SA state in the process of > sending the CCSA request then it seems like that it would be reasonable > to call this child SA half-open until the CCSA response is received. > RFC 4306 section 2.6 uses the term "half-open" to describe IKE SAs so > I'm confused why the same term couldn't be applied to a child SA. You can call them half-open SA, but there is not really that much you can do with them. > Are you implying that an implementation should not create any child SA > state until the CCSA response is received? Of course you need to create some state, but in general you cannot for example start receiving on them, as you do not know what algorithms the responder selected, and you cannot generate keying material as you do not know the Nonce required for that. So in a sense it is not really half-open SA, but only a create child SA exchange that is in progress. > Ok, I want to probe a little deeper here. RFC 4301 section 4.1 says: > "For an SA used to carry unicast traffic, the Security Parameters > Index (SPI) by itself suffices to specify an SA. (For information on > the SPI, see Appendix A and the AH and ESP specifications [Ken05b, > Ken05a].) However, as a local matter, an implementation may choose > to use the SPI in conjunction with the IPsec protocol type (AH or > ESP) for SA identification." > Suppose an implementation choses to use the SPI in conjunction with > the IPsec protocol for IPsec SA identification. Such an implementation > could have multiple IPsec SAs with the same SPI but different protocols. > It seems like this could cause interoperability problems if these SAs > are negotiated with a peer that uses only the SPI for SA > identification. If that assumption is correct, it seems like an > implementation should avoid using the same SPI, differentiated only by > protocol, with a given peer. In other words, if an implementation > uses SPI x for an ESP SA it should not attempt to use SPI x for an AH > SA with the same peer simultaneously. Would you agree? That should not matter, as SPI selection is local matter, the other end should not assume the SPIs allocated by the other end are unique, it should just use the SPIs the other end allocated without any extra checks. As for his point of view those SPIs are only used when he is sending packets, he will just take the SPI from SA and fill it in to the ESP packet, only the incoming SPI (i.e. the one he allocated himself) is used to demultiplex data. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 05:42:28 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6901228C197; Tue, 9 Sep 2008 05:42:28 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCA328C188 for ; Tue, 9 Sep 2008 05:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 4BkQRuMt7C0t for ; Tue, 9 Sep 2008 05:42:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 2C27D28C183 for ; Tue, 9 Sep 2008 05:42:24 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m89CgQP7021175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Sep 2008 15:42:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m89CgQQx002427 for ipsec@ietf.org; Tue, 9 Sep 2008 15:42:26 +0300 (EEST) Resent-From: kivinen@iki.fi X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Resent-Message-ID: <18630.28463.896380.824828@fireball.kivinen.iki.fi> Resent-Date: Tue, 9 Sep 2008 15:42:23 +0300 Resent-To: ipsec@ietf.org Message-ID: <18625.3355.123854.729870@fireball.kivinen.iki.fi> In-Reply-To: <1696498986EFEC4D9153717DA325CB7201860ECA@vaebe104.NOE.Nokia.com> References: <1696498986EFEC4D9153717DA325CB7201860ECA@vaebe104.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 22.1.1 From: Tero Kivinen To: Date: Fri, 5 Sep 2008 13:42:35 +0300 MIME-Version: 1.0 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: ipsec@ietf.org Subject: [IPsec] My notes about IKEv2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > 2.7 and 3.3.6, possible contradiction about INVALID_KE_PAYLOAD ("MUST > again propose its full set of." vs. "SHOULD, however, continue > to propose its full supported set") The 2.7 talks about the IKE_SA_INIT, and there it is MUST to propose the full set. The 3.3.6 talks about the attribute negotiation in general, and for example in the CREATE CHILD SA case the exchange is already authenticated, thus there cannot be man in the middle even if the initiator decides to retry CREATE CHILD SA with only the select Diffie-Hellman group, i.e. does not include full supported set. >From the responders point of view this does not matter, thus there is no interoperability problem here, even if initiator only uses smaller set. I think should in the 3.3.6 is still ok for the general case and the 2.7 needs to keep the MUST as that is required for the security in the IKE_SA_INIT case. > Text doesn't cover all the exchange collisions from RFC 4718 Section > 5.11 yet (but I doubt implementors will get many of those right anyway...). Most of those does not really matter as long as the implementations do not crash on such cases. For example in 5.11.1 even if other end sends duplicate delete for some SPI, that most likely will not cause any problems. In 5.11.2 if either end fails to close SA properly, they will close it after the DPD fails in the future. In the 5.11.3 the failure might cause some extra IPsec SAs to be created, but that should not cause problems. The only really important case is the 5.11.4, as if during the IKE SA rekeying the wrong IKE SA inherits the child SAs of the original IKE SA that will cause the state to be messed up between the hosts, and only way to recover will be to delete IKE SAs and start over. > Should we move features with no known implementations from the main > text to an appendix? What are such features? -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 05:42:54 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C03928C1A1; Tue, 9 Sep 2008 05:42: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 9464028C1A1 for ; Tue, 9 Sep 2008 05:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 ki2KV8NI8x4v for ; Tue, 9 Sep 2008 05:42:52 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 50C1B28C19F for ; Tue, 9 Sep 2008 05:42:51 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m89Cgq03020791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Sep 2008 15:42:52 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m89CgqRB002682 for ipsec@ietf.org; Tue, 9 Sep 2008 15:42:52 +0300 (EEST) Resent-From: kivinen@iki.fi X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Resent-Message-ID: <18630.28490.240784.144531@fireball.kivinen.iki.fi> Resent-Date: Tue, 9 Sep 2008 15:42:50 +0300 Resent-To: ipsec@ietf.org Message-ID: <18625.8720.416693.379276@fireball.kivinen.iki.fi> In-Reply-To: References: <4899A8A1.7040808@checkpoint.com> <18593.31131.888367.946778@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 22.1.1 From: Tero Kivinen To: "Grewal, Ken" Date: Fri, 5 Sep 2008 15:12:00 +0300 MIME-Version: 1.0 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Motivation for ESP-null marking X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Grewal, Ken writes: > >I think there is no point of doing this on the protocol level as to > >deploy it requires changes to ALL IPsec endpoints. > > [Ken] It will only require changes to nodes that choose to utilize > this functionality, which is probably the same statement for any > other work item in IETF today. If it is not needed (e.g. remote > access / VPN), then those nodes can operate as they do today. If we are talking about the enterprice checking traffic in their internal network, that most likely means that everything using ipsec will needs to be updated, i.e. both ends of the IPsec connections. Heuristics only require updating the middleboxes. This is bit similar than IPv6 vs NAT. IPv6 require updating of all end nodes (and infrastructure), as NAT only required middle boxes to be added, and no changes at all to the end nodes. As you can see in the deployment timeline of IPv6 vs NAT, you can see how much faster we can update middle boxes... > [Ken] This argument is applicable to any charted work item and the > deployment timelines will be dependent on many factors, including > the perceived usefulness of the feature, as well as alternatives > available. A heuristics based solution may be less desirable, as > anytime a new protocol/extension is encapsulated in IPsec, the > heuristics need to be updated to comprehend it. Anytime a new protocol goes through any box doing deep inspection, the box needs to be updated anyways, as otherwise the new protocol will not get passed through that box (deep inspection boxes quite commonly drop everything they will not understand). On the other hand heuristics only needs to be updated if no known protocols will go through the deep inspection box at all. I.e. if there is NO TCP or UDP traffic going inside the ESP-NULL flow at all, then the deep inspection box needs to understand the new protocol, so it can run heuristics on that too. In normal case there is still TCP and UDP traffic going, so it can simply run the heuristics on those packets and find out the parameters of the ESP-NULL flow from there. After that they are cached to the box, and no heuristics is needed until the SA is rekeyed. > Having said that, perhaps it is possible to devise a solution that > will work for all protocols/payloads of today and tomorrow? If so, > we'd very much like to see it fully specified in a draft submission. > That will make it much easier to evaluate the relative feasibility > and practicality of the heuristic approach, compared to our > proposal. Even when you are only checking the ESP padding, that already gives you quite good probability for running the heuristics with even a single packet with completely unknown protocol inside the ESP-NULL packet. The worst case is when there is no padding, thus there is only Pad-length field having value of 0, so every 1/256 packets goes through this check. If there is for example 2 bytes of padding (it needs to be padded to 4-byte boundary), then there is 2 bytes of padding and 1 padding length byte, which all needs to have specific values (i.e. 01 02 02). That makes it so that 1 packet out of 16777216 will pass that first check. I am writing the pseudocode for the heuristics, but it might take some more time before I get that one ready. > >I do not see any reason why both ESP-NULL and encrypted ESP shuld be > >allowed between 2 end nodes, i.e. I see only reason where there is > >either only ESP-NULL allowed or only any type of ESP allowed (i.e. > >encrypted or not, but not inspected at all). > > [Ken] This is a matter of policy and we should not offer a pure > black-or-white choice. Why don't we just remove NAT and use AH in > these environments? Why did we propose a NAT-T solution at all? We > cannot mandate how an organization will structure the network (hence > the NAT-T solution) and similarly we cannot predict or dictate what > protocols/encapsulations/algorithms it should run over that network. But if the idea is that the deep inspection boxes check the packets going through them, then they cannot inspect those packets which are encrypted, and if specific end node pairs are allowed to have both encrypted and un-encrypted packets, why would the "attacker" use the un-encrypted packets that will be inspected. He would of course use the encrypted packets so they will bypass the inspection if he is trying to do something that is not allowed. > >If both ESP-NULL and encrypted ESP is allowed between pair of end > >nodes, then anybody who wants to bybass middlebox checks will simply > >use encrypted ESP. If someone disagrees with this, I would like him to > >explain me why this is needed, and what kind of policy is used for > >that. > > [Ken] This is negotiated via policy, which is under the admin's > control. E.g. If the policy states that my company CEO (based on his > credentials used during IKE) is able to connect to a particular > server using encrypted ESP, whereas Joe Bloggs must use ESP-NULL to > allow traffic scanning, why could this not be allowed? So in this setup you are not doing security checking anymore in the middlebox, but you are trusting your end SGW to enforce security policy. If you are doing that, you might as well trust for the end SGW to do full security policy checking. Heuristics would work in that kind of situations too, but then the default what happens when the heuristics fail to check that packet is ESP-NULL is different (i.e. pass, instead of drop). Of course there is no way to check that the Joe Bloggs is not using ESP encrypted traffic in this setup, as you allow encrypteed ESP to go through. The SGW on the other end might have policy which only allows ESP null for Joe Bloggs, but if it is misconfigured for some reason, then Joe might be able to bypass security checks. If the middlebox was put there to enforce the security checks, then it cannot do that anymore. > >Also if IT department has full control of the end node > >configurations (which they must have if they assume they can update > >all end node implementations at will) they can simply mandate them to > >use one specific ESP-NULL algorithim, i.e. simply say that no other > >ESP-NULL algoritm is allowed except AUTH_HMAC_SHA1_96, and that will > >remove all heuristic checks needed. This kind of solution is > >implementatable in extremely fast timeframe. > > [Ken] This may be viable in small organizations, but is not > practical in a large organization, unless a 'forklift upgrade' is > used. Also, we need to consider legacy devices (e.g. secure printing > using an older algorithm - Do I really want to upgrade all my > printers because I choose to use GMAC for other secure comms and my > printer is using HMAC-SHA-1-96?). This is just a simple example for > illustration purposes. If you decide that GMAC is the only one offering enough security for you, then you do want to upgrade your printers too. If you consider HMAC-SHA-1-96 to be enough then you can use that for all of your traffic. If you want to allow your printers to use the new ESP-NULL protocol then you need to upgrade them anyways. > [Ken] The remainder of your comments above relate to Heuristics and > where these are implemented. This could be in HW or firmware or SW > and not all implementations are equally amenable to upgrade options > or tolerant of performance requirements. Also, the practically of > heuristics based approaches at high speed line rates (10Gbps today, > 40/100Gbps tomorrow) can be costly and dependent on the hardware > architecture, whereas a new ESP encapsulation would work fine > regardless. I do not really see any real performance differences between the new ESP encapsulation vs heuristics in the hardware, especially anything that does any kind of deep inspection. For boxes that do deep inspection there is already flow tables for TCP flows and such, so adding SPI flows for mappng SPI numbers to parameters is quite fast thing to do. All of the complicated heuristics are usually run on the slowpath anyways. > Furthermore, any changes to any ESP encapsulated > protocols will require changes / additions to the heuristics > approach, making this approach a continuous, moving target. We can very easily make the heuristics extremely effective and fast by saying that IPsec implementations should but extra 4 bytes of padding to each ESP-NULL packet. This offers very fast and very easy way to check whether packet is ESP-NULL or ESP encrypted packet without doing actual protocol change. But deep inspection is always moving target regardless what we dowith the ESP, thus the middle boxes needs to be updated every time any protocols or additions are going to be made. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 05:58:49 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 295C93A6876; Tue, 9 Sep 2008 05:58:49 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00493A6876; Tue, 9 Sep 2008 05:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAz8ynXKCw3Q; Tue, 9 Sep 2008 05:58:47 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8122A3A680C; Tue, 9 Sep 2008 05:58:46 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 19B9E294005; Tue, 9 Sep 2008 15:58:50 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0F98C294001; Tue, 9 Sep 2008 15:58:49 +0300 (IDT) Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id m89CwmP0004257; Tue, 9 Sep 2008 15:58:48 +0300 (IDT) Message-ID: <48C6730D.9030603@checkpoint.com> Date: Tue, 09 Sep 2008 15:58:53 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Tero Kivinen References: <674C0769-E278-4A59-A490-7634F2B0FF83@checkpoint.com> <18630.28015.487667.355981@fireball.kivinen.iki.fi> In-Reply-To: <18630.28015.487667.355981@fireball.kivinen.iki.fi> Cc: rohc@ietf.org, Yoav Nir , ertekin_emre@bah.com, pezeshki_jonah@bah.com, jasani_rohan@bah.com, ipsec@ietf.org, christou_chris@bah.com, cabo@tzi.org Subject: Re: [IPsec] Review of the RoHC over IPsec drafts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0776776754==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0776776754== Content-Type: multipart/alternative; boundary="------------080403000506050507090607" This is a multi-part message in MIME format. --------------080403000506050507090607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All true. But CRC should be enough (I know it's not completely kosher for crypto purists, but it's so much faster...) Yaron Tero Kivinen wrote: > Yoav Nir writes: > >> The IKE & IPsec drafts talk about the use of integrity algorithms to >> verify that decompression was successful. According to section 2.1 of >> the IKEv2 draft, these algorithms are the same algorithms (with >> associated keys) as those used in IPsec. I can't figure out why you >> would want this. The entire packet, compressed header and data >> included, is already integrity protected by IPsec. An attacker can't >> flip any bits because of the ESP ICV, so the RoHC ICV is simply there >> to detect decompression errors. I don't see why we need to exceed the >> recommendation in RFC 4995 to use CRC. Even if you have decided that >> you want to upgrade error-detection ICV to a cryptographically strong >> one, HMAC doesn't offer any benefit that I can see - you could use >> straight MD5 or SHA-1 without any key, but I still don't see why CRC >> is not good enough. >> > > Attacker cannot flip bits, but it can remove entire packets. As the > rohc is statefull compression, removing packets will affect the state > of the decompressor, thus by removing selected packets from the stream > attacker can cause some future packets to be authenticated and > decrypted correctly, but decompressed after that by using wrong state, > thus causing the end packets to be different from the original packet. > As the IPsec is there to protect that there cannot be any > modifications to the packets, this implies that we also want to detect > this kind of attacks. Because of this we do need some kind of message > authentication code after the decompression to make sure the packet > matches the packet that was sent. > --------------080403000506050507090607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

All true. But CRC should be enough (I know it's not completely kosher for crypto purists, but it's so much faster...)


    Yaron


Tero Kivinen wrote:

Yoav Nir writes:
  
The IKE & IPsec drafts talk about the use of integrity algorithms to  
verify that decompression was successful. According to section 2.1 of  
the IKEv2 draft, these algorithms are the same algorithms (with  
associated keys) as those used in IPsec. I can't figure out why you  
would want this. The entire packet, compressed header and data  
included, is already integrity protected by IPsec. An attacker can't  
flip any bits because of the ESP ICV, so the RoHC ICV is simply there  
to detect decompression errors. I don't see why we need to exceed the  
recommendation in RFC 4995 to use CRC. Even if you have decided that  
you want to upgrade error-detection ICV to a cryptographically strong  
one, HMAC doesn't offer any benefit that I can see - you could use  
straight MD5 or SHA-1 without any key, but I still don't see why CRC  
is not good enough.
    

Attacker cannot flip bits, but it can remove entire packets. As the
rohc is statefull compression, removing packets will affect the state
of the decompressor, thus by removing selected packets from the stream
attacker can cause some future packets to be authenticated and
decrypted correctly, but decompressed after that by using wrong state,
thus causing the end packets to be different from the original packet.
As the IPsec is there to protect that there cannot be any
modifications to the packets, this implies that we also want to detect
this kind of attacks. Because of this we do need some kind of message
authentication code after the decompression to make sure the packet
matches the packet that was sent.
--------------080403000506050507090607-- --===============0776776754== 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 --===============0776776754==-- From ipsec-bounces@ietf.org Tue Sep 9 06:02:10 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF5A43A6908; Tue, 9 Sep 2008 06:02: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 1B8993A6864; Tue, 9 Sep 2008 06:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 sJrAZ8gazROv; Tue, 9 Sep 2008 06:02:07 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 26A253A6846; Tue, 9 Sep 2008 06:02:07 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 87EF7294002; Tue, 9 Sep 2008 16:02:02 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 933A0294001; Tue, 9 Sep 2008 16:02:01 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m89D20Ox005805; Tue, 9 Sep 2008 16:02:00 +0300 (IDT) Message-Id: <685E570F-1A99-4434-A473-557392AB27EB@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18630.28015.487667.355981@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 9 Sep 2008 16:02:00 +0300 References: <674C0769-E278-4A59-A490-7634F2B0FF83@checkpoint.com> <18630.28015.487667.355981@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.928.1) Cc: rohc@ietf.org, ertekin_emre@bah.com, pezeshki_jonah@bah.com, jasani_rohan@bah.com, ipsec@ietf.org, christou_chris@bah.com, cabo@tzi.org Subject: Re: [IPsec] Review of the RoHC over IPsec drafts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Sep 9, 2008, at 3:34 PM, Tero Kivinen wrote: > Yoav Nir writes: >> The IKE & IPsec drafts talk about the use of integrity algorithms to >> verify that decompression was successful. According to section 2.1 of >> the IKEv2 draft, these algorithms are the same algorithms (with >> associated keys) as those used in IPsec. I can't figure out why you >> would want this. The entire packet, compressed header and data >> included, is already integrity protected by IPsec. An attacker can't >> flip any bits because of the ESP ICV, so the RoHC ICV is simply there >> to detect decompression errors. I don't see why we need to exceed the >> recommendation in RFC 4995 to use CRC. Even if you have decided that >> you want to upgrade error-detection ICV to a cryptographically strong >> one, HMAC doesn't offer any benefit that I can see - you could use >> straight MD5 or SHA-1 without any key, but I still don't see why CRC >> is not good enough. > > Attacker cannot flip bits, but it can remove entire packets. As the > rohc is statefull compression, removing packets will affect the state > of the decompressor, thus by removing selected packets from the stream > attacker can cause some future packets to be authenticated and > decrypted correctly, but decompressed after that by using wrong state, > thus causing the end packets to be different from the original packet. > As the IPsec is there to protect that there cannot be any > modifications to the packets, this implies that we also want to detect > this kind of attacks. Because of this we do need some kind of message > authentication code after the decompression to make sure the packet > matches the packet that was sent. I agree, but I'm not saying that we don't need an ICV for the decompression, just that we don't need HMAC-SHA1. CRC is good enough to detect a mismatched decompressor state. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 06:17:59 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 889CE28C139; Tue, 9 Sep 2008 06:17: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 C14C03A6C54 for ; Tue, 9 Sep 2008 06:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 Cfc+oeOF1KCx for ; Tue, 9 Sep 2008 06:17:54 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C125F3A6AC4 for ; Tue, 9 Sep 2008 06:17:53 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id DE180294002; Tue, 9 Sep 2008 16:17:56 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 14273294001 for ; Tue, 9 Sep 2008 16:17:56 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m89DHtOx012368 for ; Tue, 9 Sep 2008 16:17:55 +0300 (IDT) Message-Id: <723A5136-6CBC-4DE9-8D08-AA2CAA943580@checkpoint.com> From: Yoav Nir To: ipsec@ietf.org In-Reply-To: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 9 Sep 2008 16:17:54 +0300 References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> X-Mailer: Apple Mail (2.928.1) Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 sent out this email about a month ago, and the response was, well, underwhelming. We had three responses: one for QCD, one just asking a question, and one questioning the need and suggesting that we revive the birth certificate idea instead of the two proposed solutions. Despite this, we still believe this is important for IKE implementations, and would like to proceed. A "nightmare scenario" for us is to have two competing non-interoperable standards. We had hoped, that even though this is not a charter item, and we can't call on the group to force a consensus, that we'd hear from enough people to get a feel for the opinion of the WG. So we're asking the participants of this WG again for their opinion about the two (well, three if you include birth certificates) options for solving the de-synchronization problem. Thanks in advance Frederic, Pratima and Yoav On Aug 6, 2008, at 5:22 PM, Yoav Nir wrote: > This is a followup to my mini-presentation in Dublin. > > The problem we're trying to solve is that of a state de- > synchronization between two IKE peers. This could take several > minutes to discover and resolve, and no IPsec traffic can flow in > that time. > > The following Wiki page describes the problem, and two proposed > solutions. > > http://wiki.tools.ietf.org/wg/ipsecme/trac/wiki/SecureCrashDiscovery > > We would like to solicit input from the WG about these two > solutions, so that we can either combine them or choose between > them, and proceed with a unified draft. > > Thanks in advance > > Frederic, Pratima and Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 06:56:41 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E71C28C152; Tue, 9 Sep 2008 06:56: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 94C8428C169 for ; Tue, 9 Sep 2008 06:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 f24h2+ohGNZg for ; Tue, 9 Sep 2008 06:56:39 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 5C5AE3A6C77 for ; Tue, 9 Sep 2008 06:56:38 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m89DuYSj022496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 16:56:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m89DuW8E017674; Tue, 9 Sep 2008 16:56:32 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18630.32912.752863.589164@fireball.kivinen.iki.fi> Date: Tue, 9 Sep 2008 16:56:32 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <723A5136-6CBC-4DE9-8D08-AA2CAA943580@checkpoint.com> References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <723A5136-6CBC-4DE9-8D08-AA2CAA943580@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > Despite this, we still believe this is important for IKE > implementations, and would like to proceed. A "nightmare scenario" for > us is to have two competing non-interoperable standards. We had hoped, > that even though this is not a charter item, and we can't call on the > group to force a consensus, that we'd hear from enough people to get a > feel for the opinion of the WG. So are we planning to run all NON-WG items also through the WG, or would it be better to first discuss here whether there is problem that needs to be solved in the WG and if there is problem, then put solving that problem to charter AFTER we have finshed first items in the current charter. > So we're asking the participants of this WG again for their opinion > about the two (well, three if you include birth certificates) options > for solving the de-synchronization problem. I myself think birth certificates would be the best option, but as I have been to busy with other working group items I have not been able to start thinking this issue yet. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 07:16:14 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15723A6901; Tue, 9 Sep 2008 07:16: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 74F653A6D14 for ; Tue, 9 Sep 2008 07:16:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 fnVtuRIfiS0Q for ; Tue, 9 Sep 2008 07:16:12 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7770E3A6901 for ; Tue, 9 Sep 2008 07:16:12 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 087E0294005; Tue, 9 Sep 2008 17:16:11 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D9133294002; Tue, 9 Sep 2008 17:16:10 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m89EGAOx004916; Tue, 9 Sep 2008 17:16:10 +0300 (IDT) Message-Id: <311F6EB1-0E39-45E7-A996-11297D10B99A@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18630.32912.752863.589164@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Tue, 9 Sep 2008 17:16:10 +0300 References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <723A5136-6CBC-4DE9-8D08-AA2CAA943580@checkpoint.com> <18630.32912.752863.589164@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Sep 9, 2008, at 4:56 PM, Tero Kivinen wrote: > Yoav Nir writes: >> Despite this, we still believe this is important for IKE >> implementations, and would like to proceed. A "nightmare scenario" >> for >> us is to have two competing non-interoperable standards. We had >> hoped, >> that even though this is not a charter item, and we can't call on the >> group to force a consensus, that we'd hear from enough people to >> get a >> feel for the opinion of the WG. > > So are we planning to run all NON-WG items also through the WG, or > would it be better to first discuss here whether there is problem that > needs to be solved in the WG and if there is problem, then put solving > that problem to charter AFTER we have finshed first items in the > current charter. Sure. Just like the RoHC-over-IPsec, also not an IPSECME WG item, is also discussed here. Paul even said it was OK to discuss the non-WG items that are related to IPsec as long as we don't hog all the bandwidth. Of course, opinions that there's not really a problem are also welcome. >> So we're asking the participants of this WG again for their opinion >> about the two (well, three if you include birth certificates) options >> for solving the de-synchronization problem. > > I myself think birth certificates would be the best option, but as I > have been to busy with other working group items I have not been able > to start thinking this issue yet. So birth certificates are the solution to this non-existing problem? _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 07:39:49 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03ABE28C1BE; Tue, 9 Sep 2008 07:39:49 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3C3F28C142 for ; Tue, 9 Sep 2008 07:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 W0BkSSBXVb+s for ; Tue, 9 Sep 2008 07:39:44 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 7254C28C1BE for ; Tue, 9 Sep 2008 07:39:43 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m89Edee0005459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 17:39:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m89EdefR000126; Tue, 9 Sep 2008 17:39:40 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18630.35500.246667.437866@fireball.kivinen.iki.fi> Date: Tue, 9 Sep 2008 17:39:40 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <311F6EB1-0E39-45E7-A996-11297D10B99A@checkpoint.com> References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <723A5136-6CBC-4DE9-8D08-AA2CAA943580@checkpoint.com> <18630.32912.752863.589164@fireball.kivinen.iki.fi> <311F6EB1-0E39-45E7-A996-11297D10B99A@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 11 min X-Total-Time: 15 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > Sure. Just like the RoHC-over-IPsec, also not an IPSECME WG item, is > also discussed here. The RoHC-over-IPsec is ROHC WG item and is closing to its WG LG, so I think now is the good time for the IPsec people to check out those. The discussion was on both rohc and ipsec lists. The rohc items do have higher priority than the secure crash discovery in my personal todo list. > Paul even said it was OK to discuss the non-WG > items that are related to IPsec as long as we don't hog all the > bandwidth. Sure, but I just replied why I have not used time to think about the problem yet. I have not yet even tought whether the problem really exists, and what kind of solution is needed for it. Usually the solution depends what is the real problem we are tring to solve. > Of course, opinions that there's not really a problem are > also welcome. I have expressed that opinion too. See my email http://www.ietf.org/mail-archive/web/ipsec/current/msg03009.html. > So birth certificates are the solution to this non-existing problem? Birth certificates might be solution to some problem, but as I am not sure what problem we are solving, and I do not have time to start really thinking this now, I cannot comment whether the problem exists or whether birth certificates are solution to that problem. Others are free to use time for this, I just expressed my opinion that it might be better to first get some of the real wg items out and then think the real problem we are trying to solve, i.e are we trying to recover in less than 1, 10, 30 or 60 seconds (for 60 seconds we do not need any changes to the protocol, just more clever implementations), are we really trying to recover back to same gw (which means anything faster than 60 seconds is wasted as the gateway most likely takes about 60 seconds to get up) or different gw and so on? -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 08:53:40 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B5928C1D9; Tue, 9 Sep 2008 08:53: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 D4B1B28C1CD for ; Tue, 9 Sep 2008 08:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 5RXoTm2Ibs+y for ; Tue, 9 Sep 2008 08:53:35 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id A88D828C1D9 for ; Tue, 9 Sep 2008 08:53:34 -0700 (PDT) Received: from [10.20.30.152] (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 m89FraDd087072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 Sep 2008 08:53:37 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18630.32912.752863.589164@fireball.kivinen.iki.fi> References: <54B6B88E-C321-452D-9FAE-D9A48D6F3371@checkpoint.com> <723A5136-6CBC-4DE9-8D08-AA2CAA943580@checkpoint.com> <18630.32912.752863.589164@fireball.kivinen.iki.fi> Date: Tue, 9 Sep 2008 08:53:34 -0700 To: ipsec@ietf.org From: Paul Hoffman Subject: [IPsec] Topics allowed on the mailing list X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 4:56 PM +0300 9/9/08, Tero Kivinen wrote: >So are we planning to run all NON-WG items also through the WG, or >would it be better to first discuss here whether there is problem that >needs to be solved in the WG and if there is problem, then put solving >that problem to charter AFTER we have finshed first items in the >current charter. We are *allowing* IPsec-related topics that are not in our charter to be discussed on the list as long as such discussion does not get in the way of topics in our charter. The hope here is that if there is a topic or individual draft that has a lot of contention, a separate mailing list could be set up for that topic and summaries of the discussion sent to the WG mailing list. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 13:31:44 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84C528C209; Tue, 9 Sep 2008 13:31:44 -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 6324028C209 for ; Tue, 9 Sep 2008 13:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 EKs1LMoptzTD for ; Tue, 9 Sep 2008 13:31:42 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 7BBA828C1F8 for ; Tue, 9 Sep 2008 13:31:42 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m89KVisU024961 for ; Tue, 9 Sep 2008 20:31:44 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 m89KVhUR019857 for ; Tue, 9 Sep 2008 16:31:43 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m89KOBZE025215; Tue, 9 Sep 2008 16:24:12 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m89KOAah025214; Tue, 9 Sep 2008 16:24:10 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Tue, 9 Sep 2008 16:24:10 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20080909202410.GI24768@kebe.east.sun.com> MIME-Version: 1.0 Content-Disposition: inline Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [IPsec] IPsec tunnels *can* be fully-featured "interfaces" (sec 3.15.3) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Let me quote from section 3.15.3 of IKEv2bis: IPsec tunnels configured using IKEv2 are not fully-featured "interfaces" in the IPv6 addressing architecture sense [IPV6ADDR]. In particular, they do not necessarily have link-local addresses, and this may complicate the use of protocols that assume them, such as [MLDV2]. My issue lies with the assertion that tunnels configured using IKEv2 (and its CFG_* payloads) are not fully-featured interfaces. What is to prevent an implementation from creating a fully-formed network interface fro the result of an IKEv2 Configuration exchange? I grant that both sides (IRAC/IRAS) need to cooperate in this regard, BUT I do not see any reason to exclude the possibility. Consider the fully private network with access points attached to the Internet. An IRAC and conspiring IRAS can have an agreement on how an IRAC derives its link-local address. E.g. we have a non-IKE-payload, but IKE/IPsec-protected remote-access deployment that uses the assigned-inner-IPv4 to derive the link-local IPv6, and then we run neighbor discovery as if it were a PPP link. Even if we didn't assign the client an inner IPv4, we could have IKEv2's CFG_REPLY (or our equivalent thereof) assign a link-local, and then let IPv6 neigbor discovery and addrconf take over from there. My point is, there may not be limitations in configuring IPv6 addresses -- at least not from the POV of a spec. Now implementations may have issues, but that's not the concern of a spec, right? Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 19:07:32 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E0A73A68D0; Tue, 9 Sep 2008 19:07: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 C337A3A68D0 for ; Tue, 9 Sep 2008 19:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 XIXDQLv0-okz for ; Tue, 9 Sep 2008 19:07:30 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 194603A6862 for ; Tue, 9 Sep 2008 19:07:30 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8A27VnR009086 for ; Wed, 10 Sep 2008 02:07:35 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m8A27UCT017125 for ; Tue, 9 Sep 2008 22:07:30 -0400 (EDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8A201DX002970 for ; Tue, 9 Sep 2008 22:00:01 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m8A200eR002969 for ipsec@ietf.org; Tue, 9 Sep 2008 22:00:00 -0400 (EDT) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Tue, 9 Sep 2008 22:00:00 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20080910020000.GA2854@sun.com> MIME-Version: 1.0 Content-Disposition: inline Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [IPsec] One answer to sec 2.5 question about payloads in order X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 In section 2.5, there is this: NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the order shown in the figures in Section 2? Can we eliminate the requirement in the following paragraph? If not, we will probably have to add a new appendix with the order, but there is no reason to do that if no one actually cares. {{ Remove this paragraph before the document is finalized, of course. }} I don't think having the payloads in a specific order is going to present a problem. Just as long as we have a clear direction on what to do in the presence of malformed payloads (e.g. Two instances of an IDi payload in one packet is an error, right?), and what payloads MUST/SHOULD/MAY be there, I think we're in okay shape. I didn't see any previous e-mails on this, but I may have missed someone else chiming in. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 19:35:19 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6EDB3A683C; Tue, 9 Sep 2008 19:35: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 1EE803A683C for ; Tue, 9 Sep 2008 19:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 zYc9tb2Rd4MZ for ; Tue, 9 Sep 2008 19:35:17 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id EE2F53A65A6 for ; Tue, 9 Sep 2008 19:35:16 -0700 (PDT) Received: from [10.20.30.152] (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 m8A2ZHWj032051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Sep 2008 19:35:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20080910020000.GA2854@sun.com> References: <20080910020000.GA2854@sun.com> Date: Tue, 9 Sep 2008 19:35:15 -0700 To: Dan McDonald , ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] One answer to sec 2.5 question about payloads in order X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 10:00 PM -0400 9/9/08, Dan McDonald wrote: >In section 2.5, there is this: > > NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the > order shown in the figures in Section 2? Can we eliminate the > requirement in the following paragraph? If not, we will probably > have to add a new appendix with the order, but there is no reason to > do that if no one actually cares. {{ Remove this paragraph before the > document is finalized, of course. }} > >I don't think having the payloads in a specific order is going to present a >problem. Just as long as we have a clear direction on what to do in the >presence of malformed payloads (e.g. Two instances of an IDi payload in one >packet is an error, right?), and what payloads MUST/SHOULD/MAY be there, I >think we're in okay shape. > >I didn't see any previous e-mails on this, but I may have missed someone else >chiming in. You did not. Other chiming is appreciated. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 21:53:54 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 789AB3A65A6; Tue, 9 Sep 2008 21:53: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 BF6A23A6452 for ; Tue, 9 Sep 2008 21:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, 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 wPnXqI3YXf+H for ; Tue, 9 Sep 2008 21:53:51 -0700 (PDT) Received: from deprox.docomolab-euro.com (deprox.docomolab-euro.com [212.119.9.186]) by core3.amsl.com (Postfix) with ESMTP id 6D3DD3A68BA for ; Tue, 9 Sep 2008 21:53:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by deprox.docomolab-euro.com (Postfix) with ESMTP id 47C4A1702A; Wed, 10 Sep 2008 06:53:55 +0200 (CEST) Received: from deprox.docomolab-euro.com ([127.0.0.1]) by localhost (deprox.docomolab-euro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQdHp-JhCagG; Wed, 10 Sep 2008 06:53:43 +0200 (CEST) Received: from DEMAIL.docomolab-euro.com (demail.docomolab-euro.com [172.27.20.3]) by deprox.docomolab-euro.com (Postfix) with ESMTP; Wed, 10 Sep 2008 06:53:43 +0200 (CEST) Received: from [192.168.99.8] ([192.168.99.8]) by DEMAIL.docomolab-euro.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 06:53:41 +0200 Message-ID: <48C752D7.20401@googlemail.com> Date: Wed, 10 Sep 2008 13:53:43 +0900 From: Julien Laganier User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Dan McDonald References: <20080909202410.GI24768@kebe.east.sun.com> In-Reply-To: <20080909202410.GI24768@kebe.east.sun.com> X-OriginalArrivalTime: 10 Sep 2008 04:53:42.0086 (UTC) FILETIME=[328E6E60:01C91301] Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec tunnels *can* be fully-featured "interfaces" (sec 3.15.3) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Dan, I'd like to clarify what you have in mind -- is it something like below: client->gatweway: CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS() TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) gateway->client: CP(CFG_REPLY) = INTERNAL_IP6_ADDRESS(FE80::54A9:E436:2B82:DB81/64) TSi = (0, 0-65535, FE80::54A9:E436:2B82:DB81 - FE80::54A9:E436:2B82:DB81) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) followed by configuration of a global address based on an existing mechanism, e.g. router discovery over the IPsec tunnel to acquire an IPv6 prefix valid over that tunnel, and then SLAAC or DHCPv6. Something more or less similar was present in earlier versions of draft-eronen-ipsec-ikev2-ipv6-config-04, now summarized in its Annex A.1. One problem of such approaches is that it requires interfaces between address configuration function (as a result of e.g. SLAAC/NDP or DHCPv6) and IKEv2 because following configuration of an address or prefix, IKEv2 has to exchange traffic selectors that covers the IPv6 prefix or address that the client will use. And then do I interpret correctly your statement that "there may not be limitations in configuring IPv6 addresses -- at least not from the POV of a spec. Now implementations may have issues, but that's not the concern of a spec, right?" as the fact that the requirement for the interfaces above is out-of-scope for an IKEv2 spec, i.e. it's up to the implementation to manage? --julien Dan McDonald wrote: > Let me quote from section 3.15.3 of IKEv2bis: > > IPsec tunnels configured using IKEv2 are not fully-featured > "interfaces" in the IPv6 addressing architecture sense [IPV6ADDR]. > In particular, they do not necessarily have link-local addresses, and > this may complicate the use of protocols that assume them, such as > [MLDV2]. > > My issue lies with the assertion that tunnels configured using IKEv2 (and its > CFG_* payloads) are not fully-featured interfaces. What is to prevent an > implementation from creating a fully-formed network interface fro the result > of an IKEv2 Configuration exchange? I grant that both sides (IRAC/IRAS) need > to cooperate in this regard, BUT I do not see any reason to exclude the > possibility. > > Consider the fully private network with access points attached to the > Internet. An IRAC and conspiring IRAS can have an agreement on how an IRAC > derives its link-local address. E.g. we have a non-IKE-payload, but > IKE/IPsec-protected remote-access deployment that uses the > assigned-inner-IPv4 to derive the link-local IPv6, and then we run neighbor > discovery as if it were a PPP link. Even if we didn't assign the client an > inner IPv4, we could have IKEv2's CFG_REPLY (or our equivalent thereof) > assign a link-local, and then let IPv6 neigbor discovery and addrconf take > over from there. > > My point is, there may not be limitations in configuring IPv6 addresses -- at > least not from the POV of a spec. Now implementations may have issues, but > that's not the concern of a spec, right? > > Dan > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 9 23:52:15 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DA3F3A698B; Tue, 9 Sep 2008 23:52:15 -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 E6CFD3A698B for ; Tue, 9 Sep 2008 23:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 JJe8UmsPwVjZ for ; Tue, 9 Sep 2008 23:52:13 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id F15263A697B for ; Tue, 9 Sep 2008 23:52:12 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 59B9A294003; Wed, 10 Sep 2008 09:52:17 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 17DF9294002; Wed, 10 Sep 2008 09:52:16 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8A6qFOx027480; Wed, 10 Sep 2008 09:52:15 +0300 (IDT) Message-Id: From: Yoav Nir To: Paul Hoffman In-Reply-To: Mime-Version: 1.0 (Apple Message framework v928.1) Date: Wed, 10 Sep 2008 09:52:15 +0300 References: <20080910020000.GA2854@sun.com> X-Mailer: Apple Mail (2.928.1) Cc: ipsec@ietf.org, Dan McDonald Subject: Re: [IPsec] One answer to sec 2.5 question about payloads in order X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Sep 10, 2008, at 5:35 AM, Paul Hoffman wrote: > At 10:00 PM -0400 9/9/08, Dan McDonald wrote: >> In section 2.5, there is this: >> >> NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in >> the >> order shown in the figures in Section 2? Can we eliminate the >> requirement in the following paragraph? If not, we will probably >> have to add a new appendix with the order, but there is no reason >> to >> do that if no one actually cares. {{ Remove this paragraph before >> the >> document is finalized, of course. }} >> >> I don't think having the payloads in a specific order is going to >> present a >> problem. Just as long as we have a clear direction on what to do >> in the >> presence of malformed payloads (e.g. Two instances of an IDi >> payload in one >> packet is an error, right?), and what payloads MUST/SHOULD/MAY be >> there, I >> think we're in okay shape. >> >> I didn't see any previous e-mails on this, but I may have missed >> someone else >> chiming in. > > You did not. Other chiming is appreciated. I thought I did, and no, I don't care about the order of the payloads. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 10 01:13:33 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42EC03A6D4A; Wed, 10 Sep 2008 01:13: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 041443A6809; Wed, 10 Sep 2008 01:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.106 X-Spam-Level: X-Spam-Status: No, score=-6.106 tagged_above=-999 required=5 tests=[AWL=0.493, 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 ls1toJ45oYIs; Wed, 10 Sep 2008 01:13:28 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id C2A9C3A68E6; Wed, 10 Sep 2008 01:13:27 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m8A8D9sM029973; Wed, 10 Sep 2008 11:13:16 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 11:13:15 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 11:13:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Sep 2008 11:13:13 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720195BFF6@vaebe104.NOE.Nokia.com> In-Reply-To: <685E570F-1A99-4434-A473-557392AB27EB@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Review of the RoHC over IPsec drafts Thread-Index: AckSfFkBTdBCHfxqQ+24kIK4V5L1IAAnnDNg References: <674C0769-E278-4A59-A490-7634F2B0FF83@checkpoint.com><18630.28015.487667.355981@fireball.kivinen.iki.fi> <685E570F-1A99-4434-A473-557392AB27EB@checkpoint.com> From: To: , X-OriginalArrivalTime: 10 Sep 2008 08:13:15.0119 (UTC) FILETIME=[130A47F0:01C9131D] X-Nokia-AV: Clean Cc: rohc@ietf.org, ertekin_emre@bah.com, pezeshki_jonah@bah.com, jasani_rohan@bah.com, ipsec@ietf.org, christou_chris@bah.com, cabo@tzi.org Subject: Re: [IPsec] Review of the RoHC over IPsec drafts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir wrote: > > Tero Kivinen wrote: > > > Attacker cannot flip bits, but it can remove entire packets. As > > the rohc is statefull compression, removing packets will affect > > the state of the decompressor, thus by removing selected packets > > from the stream attacker can cause some future packets to be > > authenticated and decrypted correctly, but decompressed after that > > by using wrong state, thus causing the end packets to be different > > from the original packet. As the IPsec is there to protect that > > there cannot be any modifications to the packets, this implies > > that we also want to detect this kind of attacks. Because of this > > we do need some kind of message authentication code after the > > decompression to make sure the packet matches the packet that was sent. > > I agree, but I'm not saying that we don't need an ICV for the > decompression, just that we don't need HMAC-SHA1. CRC is good enough > to detect a mismatched decompressor state. As noted in RFC 4995, ROHC already uses CRC is detect mismatched decompressor state. Depending on the situation, either 3-bit CRC or 7-bit CRC... so even assuming CRC worked perfectly in this context, it's clearly too short to give us the kinds of probabilities we'd expect when doing cryptographic per-packet authentication. Would a longer CRC work? That's a tough question. It might work, or it might not -- it's very difficult to analyze the situation and be sure. CRCs were designed to catch random bit errors, but the "errors" here are intentional -- and even a long CRC (say, 64 bits) doesn't behave the same way a cryptographic hash (say, SHA-256 truncated to 64 bits) does. Since this second value (calculated over the uncompressed packet) is covered by the MAC in ESP (calculated over the compressed packet), it's possible that a non-keyed cryptographic hash would be enough. But since we can easily get a key, using a MAC seems safer (typically, MAC tags are also truncated to shorter lengths, like 96 bits, than is used for non-keyed hashes), and gives us better algorithm agility (e.g., you can use AES-based algorithms for everything, without needing the SHA-* family at all). (BTW, Tero and I have discussed this topic extensively with the authors earlier :-) Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 10 02:24:11 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0373A6B82; Wed, 10 Sep 2008 02:24:11 -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 F18023A6B82 for ; Wed, 10 Sep 2008 02:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=0.482, 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 FFeXN9-Hgd-J for ; Wed, 10 Sep 2008 02:24:09 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id CB08C3A68B9 for ; Wed, 10 Sep 2008 02:24:08 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m8A9OAjW008121; Wed, 10 Sep 2008 12:24:10 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 12:23:39 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 12:23:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Sep 2008 12:23:36 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB720195C0F8@vaebe104.NOE.Nokia.com> In-Reply-To: <20080909202410.GI24768@kebe.east.sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IPsec tunnels *can* be fully-featured "interfaces" (sec3.15.3) Thread-Index: AckSuy1guqBDqfBTQ5qk22QRpc5cIAAaxsNg References: <20080909202410.GI24768@kebe.east.sun.com> From: To: , X-OriginalArrivalTime: 10 Sep 2008 09:23:37.0950 (UTC) FILETIME=[E80B27E0:01C91326] X-Nokia-AV: Clean Subject: Re: [IPsec] IPsec tunnels *can* be fully-featured "interfaces" (sec3.15.3) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Well, certainly an IRAC and IRAS can conspire out-of-band to implement functionality not described in RFC 4306, but that won't result in any kind of interoperability. The goal of the IPv6 work item is to write down the necessary details (which the conspirators need to agree on) in an RFC, so different vendors can interoperate. Best regards, Pasi > -----Original Message----- > From: Dan McDonald > Sent: 09 September, 2008 23:24 > To: ipsec@ietf.org > Subject: [IPsec] IPsec tunnels *can* be fully-featured "interfaces" (sec3.15.3) > > Let me quote from section 3.15.3 of IKEv2bis: > > IPsec tunnels configured using IKEv2 are not fully-featured > "interfaces" in the IPv6 addressing architecture sense > [IPV6ADDR]. In particular, they do not necessarily have > link-local addresses, and this may complicate the use of > protocols that assume them, such as [MLDV2]. > > My issue lies with the assertion that tunnels configured using IKEv2 > (and its CFG_* payloads) are not fully-featured interfaces. What is > to prevent an implementation from creating a fully-formed network > interface fro the result of an IKEv2 Configuration exchange? I > grant that both sides (IRAC/IRAS) need to cooperate in this regard, > BUT I do not see any reason to exclude the possibility. > > Consider the fully private network with access points attached to > the Internet. An IRAC and conspiring IRAS can have an agreement on > how an IRAC derives its link-local address. E.g. we have a > non-IKE-payload, but IKE/IPsec-protected remote-access deployment > that uses the assigned-inner-IPv4 to derive the link-local IPv6, and > then we run neighbor discovery as if it were a PPP link. Even if we > didn't assign the client an inner IPv4, we could have IKEv2's > CFG_REPLY (or our equivalent thereof) assign a link-local, and then > let IPv6 neigbor discovery and addrconf take over from there. > > My point is, there may not be limitations in configuring IPv6 > addresses -- at least not from the POV of a spec. Now > implementations may have issues, but that's not the concern of a > spec, right? > > Dan > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 10 02:32:58 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D40E28C1F1; Wed, 10 Sep 2008 02:32: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 1CD853A6A43 for ; Wed, 10 Sep 2008 02:32: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 ihJug8hy7xe0 for ; Wed, 10 Sep 2008 02:32:56 -0700 (PDT) Received: from tietoe03.tietoenator.com (mail1.tieto.com [194.110.47.24]) by core3.amsl.com (Postfix) with ESMTP id EF5E23A68CD for ; Wed, 10 Sep 2008 02:32:54 -0700 (PDT) X-AuditID: c26e2f18-000021dc00001d68-7a-48c7946d19b5 Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Sep 2008 12:33:33 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Sep 2008 11:33:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 10 Sep 2008 11:33:07 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] One answer to sec 2.5 question about payloads in order thread-index: AckS7e0bCpqa1DVJRPiejcN5nBYoSAAOZzjw References: <20080910020000.GA2854@sun.com> From: To: X-OriginalArrivalTime: 10 Sep 2008 09:33:08.0191 (UTC) FILETIME=[3BEF06F0:01C91328] X-Brightmail-Tracker: AAAAAA== Subject: Re: [IPsec] One answer to sec 2.5 question about payloads in order X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 During implementation it was not a help with a fixed order. It has been a help to work out (a) the count on the number of occurrences (the cardinality) of a payload in a packet and (b) any relations between payloads (for example if KE payload present, then also SA payload must be present), and (c) any other constraints (for example CP(CFG_REQUEST) may appear only in an IKE request message). (quote from IPsec-maillist-mail on Jun 22, 2007) Christian > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Paul Hoffman > Sent: 10. september 2008 04:35 > To: Dan McDonald; ipsec@ietf.org > Subject: Re: [IPsec] One answer to sec 2.5 question about > payloads in order > > At 10:00 PM -0400 9/9/08, Dan McDonald wrote: > >In section 2.5, there is this: > > > > NOTE TO IMPLEMENTERS: Does anyone require that the > payloads be in the > > order shown in the figures in Section 2? Can we eliminate the > > requirement in the following paragraph? If not, we will probably > > have to add a new appendix with the order, but there is > no reason to > > do that if no one actually cares. {{ Remove this > paragraph before the > > document is finalized, of course. }} > > > >I don't think having the payloads in a specific order is going to > >present a problem. Just as long as we have a clear > direction on what > >to do in the presence of malformed payloads (e.g. Two > instances of an > >IDi payload in one packet is an error, right?), and what payloads > >MUST/SHOULD/MAY be there, I think we're in okay shape. > > > >I didn't see any previous e-mails on this, but I may have missed > >someone else chiming in. > > You did not. Other chiming is appreciated. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 10 05:23:01 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D14D828C205; Wed, 10 Sep 2008 05:23: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 0C03028C205 for ; Wed, 10 Sep 2008 05:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 14CHm868TU2B for ; Wed, 10 Sep 2008 05:22:59 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id B8C4B3A693D for ; Wed, 10 Sep 2008 05:22:58 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8ACMw8S013440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Sep 2008 15:22:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8ACMupO002543; Wed, 10 Sep 2008 15:22:56 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18631.48160.786664.696629@fireball.kivinen.iki.fi> Date: Wed, 10 Sep 2008 15:22:56 +0300 From: Tero Kivinen To: Julien Laganier In-Reply-To: <48C752D7.20401@googlemail.com> References: <20080909202410.GI24768@kebe.east.sun.com> <48C752D7.20401@googlemail.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 11 min X-Total-Time: 13 min Cc: ipsec@ietf.org, Dan McDonald Subject: Re: [IPsec] IPsec tunnels *can* be fully-featured "interfaces" (sec 3.15.3) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Julien Laganier writes: > followed by configuration of a global address based on an existing > mechanism, e.g. router discovery over the IPsec tunnel to acquire an > IPv6 prefix valid over that tunnel, and then SLAAC or DHCPv6. This is essentially what RFC3456 did for IPv4 for IKEv1. Most of the IKEv1 implementations never implemented that rfc, and used non standardized configuration mode instead, as it was much easier to implement. When IKEv2 configuration protocol was designed both DHCP over IPsec, DHCP over IKE and configuration payloads were being discussed and configuration payloads was selected as best option. > Something more or less similar was present in earlier versions of > draft-eronen-ipsec-ikev2-ipv6-config-04, now summarized in its Annex A.1. > > One problem of such approaches is that it requires interfaces between > address configuration function (as a result of e.g. SLAAC/NDP or > DHCPv6) and IKEv2 because following configuration of an address or > prefix, IKEv2 has to exchange traffic selectors that covers the IPv6 > prefix or address that the client will use. Actually it usually requires reimplementing IPv6 mechanisms (router disovery etc) inside the IKE, as there usually is no way to use the existing mechanisms in the system to do any work unless you are talking about the native IPsec implementation built into the operating system. For example our implementation of the RFC3456 did reimplement DHCP client and server as there was not really general portable way where we could cause the system's DHCP client to start its work when we wanted (i.e. when the tunnel was up). Also as you said the IKE still needed that information too, which meant it need to see all those packets anyways to get the address information and so on, thus it was easier not to use the system code at all. I currently think that for basic IP-address configuration (i.e. information that needs to be shared with IPsec and system) it is much easier to make IKE code to do it, especially as there usually IS standard mechanisms to install the received IP-addresses etc to the system (ioctl/ifconfig etc). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 10 05:30:46 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3882B3A6D74; Wed, 10 Sep 2008 05:30: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 50F153A6D6E for ; Wed, 10 Sep 2008 05:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 6HOpQKur+5Ed for ; Wed, 10 Sep 2008 05:30:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 022F13A6D74 for ; Wed, 10 Sep 2008 05:30:39 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8ACUbxf029922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Sep 2008 15:30:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8ACUb3R012277; Wed, 10 Sep 2008 15:30:37 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18631.48621.273728.457294@fireball.kivinen.iki.fi> Date: Wed, 10 Sep 2008 15:30:37 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <20080910020000.GA2854@sun.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 3 min X-Total-Time: 7 min Cc: ipsec@ietf.org, Paul Hoffman , Dan McDonald Subject: Re: [IPsec] One answer to sec 2.5 question about payloads in order X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > On Sep 10, 2008, at 5:35 AM, Paul Hoffman wrote: > > At 10:00 PM -0400 9/9/08, Dan McDonald wrote: > >> In section 2.5, there is this: > >> > >> NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in > >> the > >> order shown in the figures in Section 2? Can we eliminate the > >> requirement in the following paragraph? If not, we will probably > >> have to add a new appendix with the order, but there is no reason > >> to > >> do that if no one actually cares. {{ Remove this paragraph before > >> the > >> document is finalized, of course. }} > >> > >> I don't think having the payloads in a specific order is going to > >> present a > >> problem. Just as long as we have a clear direction on what to do > >> in the > >> presence of malformed payloads (e.g. Two instances of an IDi > >> payload in one > >> packet is an error, right?), and what payloads MUST/SHOULD/MAY be > >> there, I > >> think we're in okay shape. > > You did not. Other chiming is appreciated. > I thought I did, and no, I don't care about the order of the payloads. I also commented this in my long email earlier: ---------------------------------------------------------------------- Our implemnentation do not care about the order of the payloads except in some specific places (CERT payloads and so on). ---------------------------------------------------------------------- In general when sending packets it is sometimes easier if the payloads can be in any order, as it allows reusing more of the code. When parsing the incoming payloads, we do parse all of them first and then we already has pointers to all specific payloads, so it does not matter what was the order of the payloads in the packet (we do know and preserve the order of same type of payloads, i.e. CERT payloads and so on). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 10 07:37:18 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F19FF3A6D86; Wed, 10 Sep 2008 07:37: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 059B03A6D86 for ; Wed, 10 Sep 2008 07:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 M5aqfYuu+4Lr for ; Wed, 10 Sep 2008 07:37:16 -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 3A7373A6D7B for ; Wed, 10 Sep 2008 07:37:16 -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 m8AEbLm0017478 for ; Wed, 10 Sep 2008 14:37:21 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 m8AEbKrv045127 for ; Wed, 10 Sep 2008 10:37:20 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8AETod6026070; Wed, 10 Sep 2008 10:29:50 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m8AETnmT026069; Wed, 10 Sep 2008 10:29:49 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Wed, 10 Sep 2008 10:29:48 -0400 From: Dan McDonald To: Pasi.Eronen@nokia.com Message-ID: <20080910142948.GB25843@kebe.east.sun.com> References: <20080909202410.GI24768@kebe.east.sun.com> <1696498986EFEC4D9153717DA325CB720195C0F8@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1696498986EFEC4D9153717DA325CB720195C0F8@vaebe104.NOE.Nokia.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 tunnels *can* be fully-featured "interfaces" (sec3.15.3) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Wed, Sep 10, 2008 at 12:23:36PM +0300, Pasi.Eronen@nokia.com wrote: > Well, certainly an IRAC and IRAS can conspire out-of-band to implement > functionality not described in RFC 4306, but that won't result in any > kind of interoperability. Sorry for illustrating that poorly. (We have a deployment of an IPsec-protected user-auth/addrconf protocol that we hope would be obsoleted by a full IKEv2 implementation.) What Julien said earlier was what I was trying to indicate. Sorry for the confusion, Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 10 07:46:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 322503A6D8A; Wed, 10 Sep 2008 07:46:23 -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 B9DD03A6D8A for ; Wed, 10 Sep 2008 07:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 grO7nFTiU5+w for ; Wed, 10 Sep 2008 07:46:16 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 55C613A6D89 for ; Wed, 10 Sep 2008 07:46:16 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8AEkA6V018547 for ; Wed, 10 Sep 2008 14:46:11 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 m8AEkAg2047713 for ; Wed, 10 Sep 2008 10:46:10 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8AENapo025855; Wed, 10 Sep 2008 10:23:41 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m8AENUYS025854; Wed, 10 Sep 2008 10:23:30 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Wed, 10 Sep 2008 10:23:30 -0400 From: Dan McDonald To: Julien Laganier Message-ID: <20080910142330.GA25843@kebe.east.sun.com> References: <20080909202410.GI24768@kebe.east.sun.com> <48C752D7.20401@googlemail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <48C752D7.20401@googlemail.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 tunnels *can* be fully-featured "interfaces" (sec 3.15.3) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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'd like to clarify what you have in mind -- is it something like below: > > client->gatweway: > > CP(CFG_REQUEST) = > INTERNAL_IP6_ADDRESS() > TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > gateway->client: > > CP(CFG_REPLY) = > INTERNAL_IP6_ADDRESS(FE80::54A9:E436:2B82:DB81/64) > TSi = (0, 0-65535, FE80::54A9:E436:2B82:DB81 - > FE80::54A9:E436:2B82:DB81) > TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > followed by configuration of a global address based on an existing > mechanism, e.g. router discovery over the IPsec tunnel to acquire an > IPv6 prefix valid over that tunnel, and then SLAAC or DHCPv6. Yes. That's EXACTLY what I had in mind. > Something more or less similar was present in earlier versions of > draft-eronen-ipsec-ikev2-ipv6-config-04, now summarized in its Annex A.1. Okay... > One problem of such approaches is that it requires interfaces between > address configuration function (as a result of e.g. SLAAC/NDP or > DHCPv6) and IKEv2 because following configuration of an address or > prefix, IKEv2 has to exchange traffic selectors that covers the IPv6 > prefix or address that the client will use. Yes... you would have to have any subsequent derived addresses added to the SPD as traffic selectors. I thought, however, that would be more of an implementation issue than a spec issue. > And then do I interpret correctly your statement that "there may not be > limitations in configuring IPv6 addresses -- at least not from the POV > of a spec. Now implementations may have issues, but that's not the > concern of a spec, right?" as the fact that the requirement for the > interfaces above is out-of-scope for an IKEv2 spec, i.e. it's up to the > implementation to manage? Yes. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 10 20:11:58 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACFD73A6A94; Wed, 10 Sep 2008 20:11: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 94A2F3A6A94 for ; Wed, 10 Sep 2008 20:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.284, 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 MNOKMWAHYeHl for ; Wed, 10 Sep 2008 20:11:56 -0700 (PDT) Received: from deprox.docomolab-euro.com (deprox.docomolab-euro.com [212.119.9.186]) by core3.amsl.com (Postfix) with ESMTP id 817A83A6828 for ; Wed, 10 Sep 2008 20:11:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by deprox.docomolab-euro.com (Postfix) with ESMTP id 3CB2F17049; Thu, 11 Sep 2008 05:11:28 +0200 (CEST) Received: from deprox.docomolab-euro.com ([127.0.0.1]) by localhost (deprox.docomolab-euro.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtecVHi0HWiB; Thu, 11 Sep 2008 05:11:26 +0200 (CEST) Received: from DEMAIL.docomolab-euro.com (demail.docomolab-euro.com [172.27.20.3]) by deprox.docomolab-euro.com (Postfix) with ESMTP; Thu, 11 Sep 2008 05:11:26 +0200 (CEST) Received: from [192.168.99.40] ([192.168.99.40]) by DEMAIL.docomolab-euro.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Sep 2008 05:11:24 +0200 Message-ID: <48C88C5E.5020609@googlemail.com> Date: Thu, 11 Sep 2008 12:11:26 +0900 From: Julien Laganier User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Tero Kivinen References: <20080909202410.GI24768@kebe.east.sun.com> <48C752D7.20401@googlemail.com> <18631.48160.786664.696629@fireball.kivinen.iki.fi> In-Reply-To: <18631.48160.786664.696629@fireball.kivinen.iki.fi> X-OriginalArrivalTime: 11 Sep 2008 03:11:24.0858 (UTC) FILETIME=[12E581A0:01C913BC] Cc: ipsec@ietf.org, Dan McDonald Subject: Re: [IPsec] IPsec tunnels *can* be fully-featured "interfaces" (sec 3.15.3) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Tero, Just to clarify my intent: I am perfectly fine with choices that were made w.r.t. address configuration for remote accesses based on tunnel mode IPsec. Just wanted to make sure I understood Dan's comment. --julien Tero Kivinen wrote: > Julien Laganier writes: >> followed by configuration of a global address based on an existing >> mechanism, e.g. router discovery over the IPsec tunnel to acquire an >> IPv6 prefix valid over that tunnel, and then SLAAC or DHCPv6. > > This is essentially what RFC3456 did for IPv4 for IKEv1. Most of the > IKEv1 implementations never implemented that rfc, and used > non standardized configuration mode instead, as it was much easier to > implement. When IKEv2 configuration protocol was designed both DHCP > over IPsec, DHCP over IKE and configuration payloads were being > discussed and configuration payloads was selected as best option. > >> Something more or less similar was present in earlier versions of >> draft-eronen-ipsec-ikev2-ipv6-config-04, now summarized in its Annex A.1. >> >> One problem of such approaches is that it requires interfaces between >> address configuration function (as a result of e.g. SLAAC/NDP or >> DHCPv6) and IKEv2 because following configuration of an address or >> prefix, IKEv2 has to exchange traffic selectors that covers the IPv6 >> prefix or address that the client will use. > > Actually it usually requires reimplementing IPv6 mechanisms (router > disovery etc) inside the IKE, as there usually is no way to use the > existing mechanisms in the system to do any work unless you are > talking about the native IPsec implementation built into the operating > system. For example our implementation of the RFC3456 did reimplement > DHCP client and server as there was not really general portable way > where we could cause the system's DHCP client to start its work when > we wanted (i.e. when the tunnel was up). Also as you said the IKE > still needed that information too, which meant it need to see all > those packets anyways to get the address information and so on, thus > it was easier not to use the system code at all. > > I currently think that for basic IP-address configuration (i.e. > information that needs to be shared with IPsec and system) it is much > easier to make IKE code to do it, especially as there usually IS > standard mechanisms to install the received IP-addresses etc to the > system (ioctl/ifconfig etc). _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 12 10:03:08 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857D63A6B70; Fri, 12 Sep 2008 10:03: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 967053A6B70 for ; Fri, 12 Sep 2008 10:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 y2IOvktt+gtK for ; Fri, 12 Sep 2008 10:03:06 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 9F4A23A681A for ; Fri, 12 Sep 2008 10:03:06 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8CH3DkP013921 for ; Fri, 12 Sep 2008 17:03:14 GMT Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.174.48]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m8CH3Ddb059659 for ; Fri, 12 Sep 2008 13:03:13 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8CGthZj023736 for ; Fri, 12 Sep 2008 12:55:43 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m8CGtg8c023735 for ipsec@ietf.org; Fri, 12 Sep 2008 12:55:42 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Fri, 12 Sep 2008 12:55:42 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20080912165542.GG23208@kebe.east.sun.com> MIME-Version: 1.0 Content-Disposition: inline Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: [IPsec] On the alignment of IKEv2 payload fields, and a modest proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 know at least in racoon2, there were reported bugs because some IKE payloads (certificates in particular) would often push payloads that follow it out of 32-bit or even 64-bit alignment. This causes implementations to perform some amount of unnatural acts due to not being able to assume alignment. I'm fully aware of "be liberal in what you recieve", but is there a way in IKEv2bis we can encourage aligned payloads? Actually, as I type it, I think there might be... A MODEST PROPOSAL... actually... a modest payload: ===================== (Cut up to and including here.) ===================== 3.x Alignment Payload The Alignment Payload SHOULD be inserted by a transmitter to re-establish alignment of subsequent payloads in an IKEv2 packet. It MUST be ignored upon receipt, and it MUST have the critical bit (C) set to 0 to confirm that it must be ignored. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |0| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ignored bytes (variable length)..... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For example, if an implementation wishes to send 32-bit aligned payloads, it would insert an Alignment Payload if and only if the previous payload was of length inequal to 0, modulo 4. This remainder/modulo 'X' (ranging between 1 and 3), would be used to compute a properly-sized Alignment Payload of length (8 - X) bytes to follow the previous payload. The payload subsequent to the Alignment Payload would once again be on a 32-bit boundary. In another example, if one desired a 16-byte aligned payload, extras 'X' would range between 1 and 15, and the Alignment Payload length would be computed as 4 + ((28 - X) % 16), because in the cases of 13 through 16, the four-byte base header would push the payload into the next alignment boundary. The general formula for computing an Alignment Header for an N-byte boundary (for N >= 4 and N divisible by 4) given an over-boundary-byte-count X is: 4 + ((2N - X - 4) % N) If powers-of-2 are the only allowable byte boundary, the above formula can be optimized to: 4 + ((2N - X - 4) & (N - 1)) using less-expensive logical-AND. ===================== (Cut up to and including here.) ===================== As noted above, I would recommend that implementations SHOULD use this payload to insure 32-bit alignment, and MAY use it to insure 64-bit alignment. What do you think? Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 12 10:26:48 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF41C3A6C35; Fri, 12 Sep 2008 10:26:48 -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 57C2C3A6B5A for ; Fri, 12 Sep 2008 10:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.446 X-Spam-Level: X-Spam-Status: No, score=-5.446 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_43=0.6, J_CHICKENPOX_54=0.6, 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 S-DGKOl9bOG2 for ; Fri, 12 Sep 2008 10:26:46 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 869B23A6A1D for ; Fri, 12 Sep 2008 10:26:46 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8CHQrpS020256 for ; Fri, 12 Sep 2008 17:26:53 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 m8CHQrKC025265 for ; Fri, 12 Sep 2008 13:26:53 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8CHJN8N023772 for ; Fri, 12 Sep 2008 13:19:23 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m8CHJMVf023771 for ipsec@ietf.org; Fri, 12 Sep 2008 13:19:22 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Fri, 12 Sep 2008 13:19:22 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20080912171922.GH23208@kebe.east.sun.com> References: <20080912165542.GG23208@kebe.east.sun.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080912165542.GG23208@kebe.east.sun.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] On the alignment of IKEv2 payload fields, and a modest proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 fully aware of "be liberal in what you recieve", but is there a way in > IKEv2bis we can encourage aligned payloads? Actually, as I type it, I think > there might be... Sorry for following up on my own post, but two other things: * My proposed payload shouldn't be needed/used a lot. In fact, a smart implementation would: - Put all fixed-size and aligned payloads up front. - Put all variable-sized/unaligned payloads at the end. - Only use the Alignment Payload to separate the unaligned payloads. I could also talk about proper payload design and designed-in alignment, but I'm too late for that. * Attached is some illustrative code for computing lengths. Dan ===================== (Cut up to and including here.) ===================== #include #include #include void usage(char *progname) { printf("Usage: %s {use-p2-calc?}\n", progname); exit(1); } uint_t f(uint_t x, uint_t boundary, uint_t headerlen, boolean_t usep2) { if (usep2) return (headerlen + (((boundary << 1) - x - headerlen) & (boundary - 1))); else return (headerlen + ((boundary * 2 - x - headerlen) % boundary)); } int main(int argc, char *argv[]) { uint_t boundary, headerlen, i; boolean_t usep2; if (argc < 3) usage(argv[0]); boundary = atoi(argv[1]); headerlen = atoi(argv[2]); /* If third argument is present, use the power-of-2 implementation. */ usep2 = (argv[3] != NULL); printf("OVERAGE\t\tPAD-BYTES (incl. header of %d bytes)\n", headerlen); printf("=======\t\t=======================================\n"); for (i = 1; i < boundary ; i++) { printf("%d\t\t%d\n", i, f(i, boundary, headerlen, usep2)); } return (0); } _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 12 11:03:52 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBCFB3A6B20; Fri, 12 Sep 2008 11:03:52 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8E4B3A6B20 for ; Fri, 12 Sep 2008 11:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.753 X-Spam-Level: X-Spam-Status: No, score=-4.753 tagged_above=-999 required=5 tests=[AWL=1.293, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 GZU9ZsNKnsWo for ; Fri, 12 Sep 2008 11:03:51 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 2B9923A6846 for ; Fri, 12 Sep 2008 11:03:51 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8CI3lAj018164 for ; Fri, 12 Sep 2008 18:03:47 GMT Received: from binky.Central.Sun.COM (dhcp-mopac-128-107.Central.Sun.COM [129.153.128.107]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m8CI3kXS057980 for ; Fri, 12 Sep 2008 12:03:46 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id m8CHu9JR010532; Fri, 12 Sep 2008 12:56:12 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id m8CHu1nP010531; Fri, 12 Sep 2008 12:56:01 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 12 Sep 2008 12:56:01 -0500 From: Nicolas Williams To: Dan McDonald Message-ID: <20080912175601.GD1875@Sun.COM> References: <20080912165542.GG23208@kebe.east.sun.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080912165542.GG23208@kebe.east.sun.com> User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org Subject: Re: [IPsec] On the alignment of IKEv2 payload fields, and a modest proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Fri, Sep 12, 2008 at 12:55:42PM -0400, Dan McDonald wrote: > For example, if an implementation wishes to send 32-bit aligned payloads, > [...] > As noted above, I would recommend that implementations SHOULD use this > payload to insure 32-bit alignment, and MAY use it to insure 64-bit > alignment. But how would the sender know what alignment the receiver prefers? I think a notify payload for indicating one's alignment preference becomes necessary. Alternatively 64-bit alignment should suffice, so say SHOULD 64-bit. But also, by putting all alignment-breaking payloads at the end of the message, as you also suggest, should be enough, no? Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 12 11:24:29 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A893A6B67; Fri, 12 Sep 2008 11:24:29 -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 4C2093A6C31 for ; Fri, 12 Sep 2008 11:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.946 X-Spam-Level: X-Spam-Status: No, score=-5.946 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 5pPT7h8pJ9ni for ; Fri, 12 Sep 2008 11:24:27 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id E8A093A6C27 for ; Fri, 12 Sep 2008 11:24:05 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m8CIO96e020983 for ; Fri, 12 Sep 2008 18:24:09 GMT Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.174.48]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m8CIO9HC037666 for ; Fri, 12 Sep 2008 14:24:09 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8CIGdFE023821 for ; Fri, 12 Sep 2008 14:16:39 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m8CIGcDE023820 for ipsec@ietf.org; Fri, 12 Sep 2008 14:16:38 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Fri, 12 Sep 2008 14:16:38 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20080912181638.GJ23208@kebe.east.sun.com> References: <20080912165542.GG23208@kebe.east.sun.com> <20080912175601.GD1875@Sun.COM> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080912175601.GD1875@Sun.COM> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] On the alignment of IKEv2 payload fields, and a modest proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Fri, Sep 12, 2008 at 12:56:01PM -0500, Nicolas Williams wrote: > > As noted above, I would recommend that implementations SHOULD use this > > payload to insure 32-bit alignment, and MAY use it to insure 64-bit > > alignment. > > But how would the sender know what alignment the receiver prefers? It doesn't. This is an aid, not a mandate. The inclusion of one ALIGNMENT payload could implicitly express a desired alignment quite simply. Also, the IPv4 + UDP headers are not 64-bit aligned (20 + 8 == 28) unless you mandate the zero-SPI, which makes things much worse. > I think a notify payload for indicating one's alignment preference > becomes necessary. Alternatively 64-bit alignment should suffice, so > say SHOULD 64-bit. IMHO a notify is too much. Then again, IMHO, I'm pushing it just suggesting an alignment payload. Also, the more I think about it, the more that any alignment beyond 32-bit is annoyingly hard, because of the sizeof(IPv4) vs. sizeof(IPv6) problem. > But also, by putting all alignment-breaking payloads at the end of the > message, as you also suggest, should be enough, no? Most of the time it should be, but I'm thinking about identities and such. The example third packet in ikev2bis has: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> and there are potentially four unaligned fields (IDi, IDr, CERT, CERTREQ). So you can put AUTH, SAi2, TSi and TSr up front, but after that, you're going to have potential problems. Though to be fair, your parsing code of those extensions is going to be performing unnatural acts already, so perhaps it is not so bad merely putting unaligned payloads at the end. It's worth a thread here on the list, at any rate. I'm particularly interested hearing from those who've written header-parsing code. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 12 11:37:15 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C8028C16C; Fri, 12 Sep 2008 11:37:15 -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 D0B3A3A69E5 for ; Fri, 12 Sep 2008 11:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 W4V0CaJCM8Cl for ; Fri, 12 Sep 2008 11:37:14 -0700 (PDT) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id E205A3A6850 for ; Fri, 12 Sep 2008 11:37:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,390,1217826000"; d="scan'208";a="371280731" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 12 Sep 2008 13:37:21 -0500 MIME-Version: 1.0 Message-ID: <18634.46115.50597.493207@gargle.gargle.HOWL> Date: Fri, 12 Sep 2008 14:25:39 -0400 From: Paul Koning To: danmcd@sun.com References: <20080912165542.GG23208@kebe.east.sun.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-OriginalArrivalTime: 12 Sep 2008 18:25:40.0196 (UTC) FILETIME=[F5A39240:01C91504] Cc: ipsec@ietf.org Subject: Re: [IPsec] On the alignment of IKEv2 payload fields, and a modest proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org >>>>> "Dan" == Dan McDonald writes: Dan> I know at least in racoon2, there were reported bugs because Dan> some IKE payloads (certificates in particular) would often push Dan> payloads that follow it out of 32-bit or even 64-bit alignment. Dan> This causes implementations to perform some amount of unnatural Dan> acts due to not being able to assume alignment. Dan> I'm fully aware of "be liberal in what you recieve", but is Dan> there a way in IKEv2bis we can encourage aligned payloads? Yes, but what purpose would that serve? If it's not mandatory, you still need the same code you have today at the receive end. So you've added complexity (at the transmit end) for no benefit (no savings at the receive end). Also, it seems to me that the "unnatural acts" amount to adding "packed" to a variable declaration -- and the code the compiler generates when you do this. Since IKE isn't fastpath that isn't enough to matter. paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 12 11:37:16 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5AC28C196; Fri, 12 Sep 2008 11:37: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 385B33A6850 for ; Fri, 12 Sep 2008 11:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 KeD9rF-4Pysh for ; Fri, 12 Sep 2008 11:37:14 -0700 (PDT) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id 6A6AA3A6980 for ; Fri, 12 Sep 2008 11:37:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,390,1217826000"; d="scan'208";a="371280738" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 12 Sep 2008 13:37:22 -0500 MIME-Version: 1.0 Message-ID: <18634.46241.850990.195544@gargle.gargle.HOWL> Date: Fri, 12 Sep 2008 14:27:45 -0400 From: Paul Koning To: danmcd@sun.com References: <20080912165542.GG23208@kebe.east.sun.com> <20080912175601.GD1875@Sun.COM> <20080912181638.GJ23208@kebe.east.sun.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-OriginalArrivalTime: 12 Sep 2008 18:27:47.0396 (UTC) FILETIME=[4174C040:01C91505] Cc: ipsec@ietf.org Subject: Re: [IPsec] On the alignment of IKEv2 payload fields, and a modest proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org >>>>> "Dan" == Dan McDonald writes: Dan> It's worth a thread here on the list, at any rate. I'm Dan> particularly interested hearing from those who've written Dan> header-parsing code. I have. I think the cost of the unaligned case is completely irrelevant both in code complexity (tiny) and performance (ditto). Now if we were talking fastpath, that might be different. In particular, compared to the hassle of dealing with byte order, alignment is a non-issue. paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 12 11:52:33 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A452D28C188; Fri, 12 Sep 2008 11:52: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 D5AF43A6C63 for ; Fri, 12 Sep 2008 11:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 HiEiQye5Z3PS for ; Fri, 12 Sep 2008 11:52:32 -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 224F33A6C5F for ; Fri, 12 Sep 2008 11:52:31 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8CIqdaG024280 for ; Fri, 12 Sep 2008 18:52:39 GMT Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.174.48]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m8CIqcFO049297 for ; Fri, 12 Sep 2008 14:52:39 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8CIj9pU023974 for ; Fri, 12 Sep 2008 14:45:09 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m8CIj8en023973 for ipsec@ietf.org; Fri, 12 Sep 2008 14:45:08 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Fri, 12 Sep 2008 14:45:08 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20080912184508.GL23208@kebe.east.sun.com> References: <20080912165542.GG23208@kebe.east.sun.com> <20080912175601.GD1875@Sun.COM> <20080912181638.GJ23208@kebe.east.sun.com> <18634.46241.850990.195544@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <18634.46241.850990.195544@gargle.gargle.HOWL> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] On the alignment of IKEv2 payload fields, and a modest proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 In my mind, "unnatural acts" include any load-one-byte-at-a-time ops, but as you point out, it's not like IKE is in ANYONE'S fastpath, given dominance by D-H operations. > Dan> It's worth a thread here on the list, at any rate. I'm > Dan> particularly interested hearing from those who've written > Dan> header-parsing code. > > I have. I think the cost of the unaligned case is completely > irrelevant both in code complexity (tiny) and performance (ditto). > Now if we were talking fastpath, that might be different. Agreed. > In particular, compared to the hassle of dealing with byte order, > alignment is a non-issue. Says you! ;) I have to deal with two different architectures, one with strict alignment but proper byte-order (SPARC), and one with loose alignment but improper byte-order (i386/amd64) Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 12 12:37:05 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82803A6C62; Fri, 12 Sep 2008 12:37:05 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38AEC3A6B86 for ; Fri, 12 Sep 2008 12:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 XvECb2L6+yx2 for ; Fri, 12 Sep 2008 12:37:00 -0700 (PDT) Received: from aussmtpmrkpc120.us.dell.com (aussmtpmrkpc120.us.dell.com [143.166.82.159]) by core3.amsl.com (Postfix) with ESMTP id 3C8343A6C6A for ; Fri, 12 Sep 2008 12:36:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,391,1217826000"; d="scan'208";a="355431436" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkpc120.us.dell.com with SMTP; 12 Sep 2008 14:37:01 -0500 MIME-Version: 1.0 Message-ID: <18634.49643.778018.35632@gargle.gargle.HOWL> Date: Fri, 12 Sep 2008 15:24:27 -0400 From: Paul Koning To: danmcd@sun.com References: <20080912165542.GG23208@kebe.east.sun.com> <20080912175601.GD1875@Sun.COM> <20080912181638.GJ23208@kebe.east.sun.com> <18634.46241.850990.195544@gargle.gargle.HOWL> <20080912184508.GL23208@kebe.east.sun.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-OriginalArrivalTime: 12 Sep 2008 19:24:29.0301 (UTC) FILETIME=[2D264250:01C9150D] Cc: ipsec@ietf.org Subject: Re: [IPsec] On the alignment of IKEv2 payload fields, and a modest proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org >>>>> "Dan" == Dan McDonald writes: Dan> Dan> In my mind, "unnatural acts" include any load-one-byte-at-a-time Dan> ops, ... Sure, but the compiler can do that for you. Dan> It's worth a thread here on the list, at any rate. I'm Dan> particularly interested hearing from those who've written Dan> header-parsing code. >> I have. I think the cost of the unaligned case is completely >> irrelevant both in code complexity (tiny) and performance (ditto). >> Now if we were talking fastpath, that might be different. Dan> Agreed. >> In particular, compared to the hassle of dealing with byte order, >> alignment is a non-issue. Dan> Says you! ;) I have to deal with two different architectures, Dan> one with strict alignment but proper byte-order (SPARC), and one Dan> with loose alignment but improper byte-order (i386/amd64) At least you don't have to deal with strict alignment AND wrong byte order (MIPS little endian) as we do... :-) paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 13 15:19:30 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39D103A67E6; Sat, 13 Sep 2008 15:19:30 -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 A35673A67E6 for ; Sat, 13 Sep 2008 15:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZQLcO83IkNI for ; Sat, 13 Sep 2008 15:19:27 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id D2B2E3A6783 for ; Sat, 13 Sep 2008 15:19:27 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1A09B2005A; Sat, 13 Sep 2008 15:19:37 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 13 Sep 2008 15:19:37 -0700 (PDT) Message-ID: <072c19c42a778ce03b768b2fa985964e.squirrel@www.trepanning.net> In-Reply-To: <20080912165542.GG23208@kebe.east.sun.com> References: <20080912165542.GG23208@kebe.east.sun.com> Date: Sat, 13 Sep 2008 15:19:37 -0700 (PDT) From: "Dan Harkins" To: "Dan McDonald" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org Subject: Re: [IPsec] On the alignment of IKEv2 payload fields, and a modest proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Dan, Why not just use a 3 of the reserved bits in the IKE header to indicate how much padding (included in the Payload Length) you've added to the particular payload that would've otherwise pushed the next payload out of alignment? regards, Dan. On Fri, September 12, 2008 9:55 am, Dan McDonald wrote: > I know at least in racoon2, there were reported bugs because some IKE > payloads (certificates in particular) would often push payloads that > follow > it out of 32-bit or even 64-bit alignment. This causes implementations to > perform some amount of unnatural acts due to not being able to assume > alignment. > > I'm fully aware of "be liberal in what you recieve", but is there a way in > IKEv2bis we can encourage aligned payloads? Actually, as I type it, I > think > there might be... > > A MODEST PROPOSAL... actually... a modest payload: > > ===================== (Cut up to and including here.) > ===================== > > 3.x Alignment Payload > > The Alignment Payload SHOULD be inserted by a transmitter to > re-establish > alignment of subsequent payloads in an IKEv2 packet. It MUST be > ignored > upon receipt, and it MUST have the critical bit (C) set to 0 to confirm > that it must be ignored. > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Payload |0| RESERVED | Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ignored bytes (variable length)..... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > For example, if an implementation wishes to send 32-bit aligned > payloads, > it would insert an Alignment Payload if and only if the previous > payload > was of length inequal to 0, modulo 4. This remainder/modulo 'X' > (ranging > between 1 and 3), would be used to compute a properly-sized Alignment > Payload of length (8 - X) bytes to follow the previous payload. The > payload subsequent to the Alignment Payload would once again be on a > 32-bit boundary. > > In another example, if one desired a 16-byte aligned payload, extras > 'X' > would range between 1 and 15, and the Alignment Payload length would be > computed as 4 + ((28 - X) % 16), because in the cases of 13 through > 16, the four-byte base header would push the payload into the next > alignment boundary. > > The general formula for computing an Alignment Header for an N-byte > boundary (for N >= 4 and N divisible by 4) given an > over-boundary-byte-count X is: > > 4 + ((2N - X - 4) % N) > > If powers-of-2 are the only allowable byte boundary, the above formula > can > be optimized to: > > 4 + ((2N - X - 4) & (N - 1)) > > using less-expensive logical-AND. > > ===================== (Cut up to and including here.) > ===================== > > As noted above, I would recommend that implementations SHOULD use this > payload to insure 32-bit alignment, and MAY use it to insure 64-bit > alignment. > > What do you think? > > Dan > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 15 03:59:55 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 356983A6B0A; Mon, 15 Sep 2008 03:59:55 -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 E7AE03A6820 for ; Mon, 15 Sep 2008 03:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 uNQmt9ytUpx1 for ; Mon, 15 Sep 2008 03:59:53 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 367DB3A690E for ; Mon, 15 Sep 2008 03:59:44 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8FAxk0W028971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Sep 2008 13:59:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8FAxiGv017509; Mon, 15 Sep 2008 13:59:44 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18638.16416.433670.351416@fireball.kivinen.iki.fi> Date: Mon, 15 Sep 2008 13:59:44 +0300 From: Tero Kivinen To: Paul Koning In-Reply-To: <18634.49643.778018.35632@gargle.gargle.HOWL> References: <20080912165542.GG23208@kebe.east.sun.com> <20080912175601.GD1875@Sun.COM> <20080912181638.GJ23208@kebe.east.sun.com> <18634.46241.850990.195544@gargle.gargle.HOWL> <20080912184508.GL23208@kebe.east.sun.com> <18634.49643.778018.35632@gargle.gargle.HOWL> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 14 min X-Total-Time: 23 min Cc: ipsec@ietf.org, danmcd@sun.com Subject: Re: [IPsec] On the alignment of IKEv2 payload fields, and a modest proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Paul Koning writes: > Dan> It's worth a thread here on the list, at any rate. I'm > Dan> particularly interested hearing from those who've written > Dan> header-parsing code. > >> I have. I think the cost of the unaligned case is completely > >> irrelevant both in code complexity (tiny) and performance (ditto). > >> Now if we were talking fastpath, that might be different. I have also written code that must work on any byte order and in any alignment requirements, and we do not even have any idea what those requirements are, as our customers can use our OEM toolkit in various platforms... We use SSH_{GET,PUT}_{8,16,24,32,40,64}BIT macros to do all the reading and writing data from actual packet. Those macros are then either generic c-code using unsigned char pointers or optimzed code for specific platforms (including assembler optimizations on some platforms). It really does not affect coding once you get used to that, and you normally first decode the packet completely to internal c-structures and use those from that on. That also makes sure you have already checked all payloads before you even start using the data, and you do not need to care about things like payload orderings and so on, as you decode full packet in the beginning. I do not really think alignment issues matters that much in modern processors, as the slow operation will be the fetching the data from the main memory to the cache, and after it is in the cache processor can quite quickly do whatever it likes with the data. Also parsing and generating IKE payloads is so fast compared to other things (Diffie-Hellman, RSA operations, even encryption and hashing) that it is not really even noticeable. I do not want to add any more complications to the IKE thus I do not think we need any alignment payloads. We did have some dicussion during the ikev2 protocol development phase too: http://www.ietf.org/mail-archive/web/ipsec/current/msg00348.html http://www.ietf.org/mail-archive/web/ipsec/current/msg00349.html (I think there was more discussion earlier, but cannot seem to find those). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 15 07:12:15 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375203A68F1; Mon, 15 Sep 2008 07:12:15 -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 A45E63A68C1 for ; Mon, 15 Sep 2008 07:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.971 X-Spam-Level: X-Spam-Status: No, score=-3.971 tagged_above=-999 required=5 tests=[AWL=-1.925, BAYES_00=-2.599, 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 ur9n40Jq41OM for ; Mon, 15 Sep 2008 07:12:08 -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 A6DD03A6835 for ; Mon, 15 Sep 2008 07:12:08 -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 m8FECISh026175 for ; Mon, 15 Sep 2008 14:12:18 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m8FECH3N045400 for ; Mon, 15 Sep 2008 10:12:18 -0400 (EDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8FE4iSM002090 for ; Mon, 15 Sep 2008 10:04:44 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m8FE4h3c002089 for ipsec@ietf.org; Mon, 15 Sep 2008 10:04:43 -0400 (EDT) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Mon, 15 Sep 2008 10:04:43 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20080915140443.GB2029@sun.com> References: <20080912165542.GG23208@kebe.east.sun.com> <20080912175601.GD1875@Sun.COM> <20080912181638.GJ23208@kebe.east.sun.com> <18634.46241.850990.195544@gargle.gargle.HOWL> <20080912184508.GL23208@kebe.east.sun.com> <18634.49643.778018.35632@gargle.gargle.HOWL> <18638.16416.433670.351416@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <18638.16416.433670.351416@fireball.kivinen.iki.fi> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] On the alignment of IKEv2 payload fields, and a modest proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Mon, Sep 15, 2008 at 01:59:44PM +0300, Tero Kivinen wrote: > I do not want to add any more complications to the IKE thus I do not > think we need any alignment payloads. Fair enough. I was more curious than anything else. I would *recommend* to people, though, especially given that we've agreed that payload order doesn't matter, that it would be nice if known-to-be-aligned payloads go first. Thanks, Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 15 07:47:59 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCC963A6B4B; Mon, 15 Sep 2008 07:47: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 BE1AF3A6B4B for ; Mon, 15 Sep 2008 07:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 HpSxfp6UjJbS for ; Mon, 15 Sep 2008 07:47:58 -0700 (PDT) Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id D583D3A6B01 for ; Mon, 15 Sep 2008 07:47:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.32,401,1217826000"; d="scan'208";a="371462040" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 15 Sep 2008 09:48:06 -0500 MIME-Version: 1.0 Message-ID: <18638.30115.965995.519725@gargle.gargle.HOWL> Date: Mon, 15 Sep 2008 10:48:03 -0400 From: Paul Koning To: danmcd@sun.com References: <20080912165542.GG23208@kebe.east.sun.com> <20080912175601.GD1875@Sun.COM> <20080912181638.GJ23208@kebe.east.sun.com> <18634.46241.850990.195544@gargle.gargle.HOWL> <20080912184508.GL23208@kebe.east.sun.com> <18634.49643.778018.35632@gargle.gargle.HOWL> <18638.16416.433670.351416@fireball.kivinen.iki.fi> <20080915140443.GB2029@sun.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-OriginalArrivalTime: 15 Sep 2008 14:48:05.0638 (UTC) FILETIME=[0FC15A60:01C91742] Cc: ipsec@ietf.org Subject: Re: [IPsec] On the alignment of IKEv2 payload fields, and a modest proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org >>>>> "Dan" == Dan McDonald writes: Dan> On Mon, Sep 15, 2008 at 01:59:44PM +0300, Tero Kivinen wrote: Dan> >> I do not want to add any more complications to the IKE thus I do >> not think we need any alignment payloads. Dan> Fair enough. I was more curious than anything else. Dan> I would *recommend* to people, though, especially given that Dan> we've agreed that payload order doesn't matter, that it would be Dan> nice if known-to-be-aligned payloads go first. I disagree. Such recommendations make no difference to conforming receiver implementations, but they may increase the probability of nonconfirming ones. (Someone might misinterpret that recommendation and code up a receiver that only works correctly with the recommended ordering.) If such a recommendation is included, it will be important for conformance tests to exercise drastically different orderings. paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 15 08:07:08 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B682428C152; Mon, 15 Sep 2008 08:07: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 5CC8A3A69FF; Sun, 14 Sep 2008 20:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 F1XI9MPd10Rk; Sun, 14 Sep 2008 20:41:01 -0700 (PDT) Received: from mclniron01-ext.bah.com (mclniron01-ext.bah.com [156.80.1.71]) by core3.amsl.com (Postfix) with ESMTP id 9AADB3A6928; Sun, 14 Sep 2008 20:40:58 -0700 (PDT) x-SBRS: None X-REMOTE-IP: 156.80.7.153 X-IronPort-AV: E=Sophos;i="4.32,399,1217822400"; d="scan'208";a="51862486" Received: from mclnexbh03.resource.ds.bah.com ([156.80.7.153]) by mclniron01-int.bah.com with ESMTP; 14 Sep 2008 23:40:56 -0400 Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.121]) by mclnexbh03.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 14 Sep 2008 23:40:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 14 Sep 2008 23:40:53 -0400 Message-ID: <37BDD2FAF2AEAE459C6C70FDC2892E4E03457938@MCLNEXVS05.resource.ds.bah.com> In-Reply-To: <674C0769-E278-4A59-A490-7634F2B0FF83@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of the RoHC over IPsec drafts Thread-Index: AckRt7hCgieeCYy7SsOrKCdN79t8jAFIF+RQ References: <674C0769-E278-4A59-A490-7634F2B0FF83@checkpoint.com> From: "Ertekin, Emre [USA]" To: "Yoav Nir" , "Christou, Christos [USA]" , X-OriginalArrivalTime: 15 Sep 2008 03:40:55.0916 (UTC) FILETIME=[DC2E82C0:01C916E4] X-Mailman-Approved-At: Mon, 15 Sep 2008 08:07:07 -0700 Cc: ipsec@ietf.org, rohc@ietf.org Subject: Re: [IPsec] Review of the RoHC over IPsec drafts X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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, Yoav, Thanks for your comments and review of our drafts. Please find our responses below. > The three drafts are: > > * draft-ietf-rohc-hcoipsec - integration of RoHC over IPsec SAs > * draft-ietf-rohc-ikev2-extensions-hcoipsec - IKEv2 extensions to > negotiate RoHC over IPsec > * draft-ietf-rohc-ipsec-extensions-hcoipsec - IPsec extenstions > > > > Overall the drafts drafts seem good, and in my opinion could offer a > substantial benefit for IPsec tunnels, especially where the bandwidth to > one or both endpoints is constrained. Here's my comments. Thanks! > * The IKE & IPsec drafts talk about the use of integrity algorithms to > verify that decompression was successful. According to section 2.1 of the > IKEv2 draft, these algorithms are the same algorithms (with associated > keys) as those used in IPsec. I can't figure out why you would want this. The reason for this additional integrity-check is to mitigate scenarios where intentional (severe) packet reordering or packet loss in the unprotected network can cause the decompressor to invalidly decompress packet headers (incorrectly reconstruct fields of a packet header), and forward them into the protected domain. To mitigate this, we add the additional integrity algorithm to verify that the decompression operation is successful. Note that since we are adding an additional ICV, the overall efficiency gain of header compression is reduced. It may be desired not to negotiate this additional RoHC integrity algorithm for the RoHC-enabled SA, but this comes with the risk that compressed headers may be invalidly decompressed and forwarded into the protected domain. > The entire packet, compressed header and data included, is already > integrity protected by IPsec. An attacker can't flip any bits because of > the ESP ICV, so the RoHC ICV is simply there to detect decompression > errors. I don't see why we need to exceed the recommendation in RFC 4995 > to use CRC. Even if you have decided that you want to upgrade error- > detection ICV to a cryptographically strong one, HMAC doesn't offer any > benefit that I can see - you could use straight MD5 or SHA-1 without any > key, but I still don't see why CRC is not good enough. I think that Pasi responded to this in his email. We want to be able to ensure (potentially to the level of the cryptographic strength negotiated for IPsec) the integrity of all bits in the decompressed header. Note, however, that the values negotiated for the integrity-check are based on Integrity Algorithms defined in the Transform Type 3 registry. Therefore, an implementation could negotiate the value of "0" (no integrity-algorithm), and as you mentioned, rely on the built-in RoHC CRC. > * The introduction to draft-ietf-rohc-hcoipsec-08 says that "However, > since current specifications for RoHC detail its operation on a hop-by-hop > basis, it may require extensions to enable its operation over IPsec SAs.". > This is not explained later. An IPsec tunnel is very much like a single > hop (for the tunneled traffic), so I don't see why special extensions > would be needed. We'll clarify the introduction based on your comment. What we intended to indicate was that for RoHCoIPsec, there may be multiple physical hops between compressor and decompressor (even though it looks like a single hop from the IPsec perspective). Therefore, RoHCv2 profiles that are tolerant to packet reordering/loss should be used. Initial profiles of RoHC did not necessarily account for significant packet reordering scenarios, since RoHC was initially designed to operate over a single physical hop. > * Section 4 of draft-ietf-rohc-hcoipsec-08 needs some rewording. Is > the second sentence about the TFC feature of IPsec? About the padding > feature of RoHC? About the problem in general? You might want to add > discussion about whether it is recommended to use RoHC padding or IPsec > TFC to avoid the problem. It's about the problem in general. The second sentence was intended to indicate that an ESP tunnel mode SA provides partial traffic flow confidentiality, but that tunneling incurs additional packet overhead. I'm inclined to leave the text as-is; let me know if you still think it needs to be modified. > * Section 5.2 of draft-ietf-rohc-hcoipsec (last paragraph) has some > strange text about ESP-NULL, which I don't understand. Why should ESP-NULL > be any different than any other ESP method? Fair comment. We'll delete this paragraph. > * There is, however, something to consider about ESP-NULL. Some > middleboxes may want to inspect traffic that is encrypted with ESP-NULL > (see draft-grewal-ipsec-traffic-visibility-00). It's possible that RoHC > will cause those middleboxes to drop all traffic that is compressed, > because they won't be able to parse the compressed headers. This is more of a question of policy rather than functionality. For example, the middlebox may have a policy to drop ESP-NULL encrypted packets whose inner-headers cannot be parsed. On the other hand, the middlebox could have a policy that says inspect all ESP-NULL encrypted packets, drop packets whose inner headers cannot be parsed, except for those packets whose the NextHeader field is set to "RoHC". > * Section 6.1.2 says "f the RoHC protocol requires bi-directional > communications, two SAs must be instantiated between the IPsec > implementations." This is a non-issue, since IKE creates SAs in pairs > anyways. So I don't see the point in the recommendation to use only non- > feedback profiles. You may want to mention that the decompressor needs to > relay feedback to the appropriate compressor Agreed. Later in the paragraph, we indicate: " Note that the requirement for two SAs aligns with the operation of IKE, which creates SAs in pairs by default." We'll modify the last sentence of the paragraph to indicate that the decompressor associated with an inbound SA will relay feedback to the compressor associated with the corresponding outbound SA. > Regarding the IKEv2 draft, I only have several comments about section 2.1: > > * It's common for IKEv2 drafts to have at the beginning a figure of > the entire payload and then explain the various fields. Sure, we can add a figure illustrating the Notify payload. We actually had this illustration in the -02 version of the draft, and then removed it since it was identical to Figure 16 of RFC 4306. But, we'll add it back. > * The explanation of the "Critical" bit is incorrect. It does not > refer to the content of the payload, only to the type of the payload, in > this case "Notify". The bit MUST be off for Notify payloads, because all > IKEv2 implementations must support it. Similarly, there's not reason to > define the content of the reserved bits, because they're the same as for > any payload. Agreed--we have updated the draft to indicate that this bit if off. We also removed the definition of the content of the reserved field. > * Protocol ID field: According to the first paragraph of 2.1, the > notification is only in CCSA and IKE_AUTH. So there's no case where this > notification is used outside of the creation of the child SA, and there's > no need to ever set the protocol ID. Agreed--this is fixed. Best Regards, Emre _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 15 23:14:14 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15A628C0EF; Mon, 15 Sep 2008 23:14: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 0637828C0EF for ; Mon, 15 Sep 2008 23:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[AWL=0.440, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uANVBS4EZj5H for ; Mon, 15 Sep 2008 23:14:13 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 786A33A68A6 for ; Mon, 15 Sep 2008 23:14:12 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E112E294004; Tue, 16 Sep 2008 09:14:22 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id D7AA9294003; Tue, 16 Sep 2008 09:14:20 +0300 (IDT) Received: from [172.16.10.186] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8G6EJOx018047; Tue, 16 Sep 2008 09:14:20 +0300 (IDT) Message-ID: <48CF4EBB.6010601@checkpoint.com> Date: Tue, 16 Sep 2008 09:14:19 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Dan McDonald References: <20080912165542.GG23208@kebe.east.sun.com> <20080912175601.GD1875@Sun.COM> <20080912181638.GJ23208@kebe.east.sun.com> <18634.46241.850990.195544@gargle.gargle.HOWL> <20080912184508.GL23208@kebe.east.sun.com> <18634.49643.778018.35632@gargle.gargle.HOWL> <18638.16416.433670.351416@fireball.kivinen.iki.fi> <20080915140443.GB2029@sun.com> In-Reply-To: <20080915140443.GB2029@sun.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] On the alignment of IKEv2 payload fields, and a modest proposal X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0216916254==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0216916254== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040708020706020103090407" This is a cryptographically signed message in MIME format. --------------ms040708020706020103090407 Content-Type: multipart/alternative; boundary="------------060408000309050107000903" This is a multi-part message in MIME format. --------------060408000309050107000903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Dan, going back to your original mail on this thread, I'd like to point out that the goal of IKEv2bis is very specifically to clarify the standard, rather than to change or extend it. If extensions are needed, there are other ways to have them, namely a separate RFC. Thanks, Yaron Dan McDonald wrote: > On Mon, Sep 15, 2008 at 01:59:44PM +0300, Tero Kivinen wrote: > > >> I do not want to add any more complications to the IKE thus I do not >> think we need any alignment payloads. >> > > Fair enough. I was more curious than anything else. > > I would *recommend* to people, though, especially given that we've agreed > that payload order doesn't matter, that it would be nice if > known-to-be-aligned payloads go first. > > Thanks, > Dan > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > --------------060408000309050107000903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi Dan,


going back to your original mail on this thread, I'd like to point out that the goal of IKEv2bis is very specifically to clarify the standard, rather than to change or extend it. If extensions are needed, there are other ways to have them, namely a separate RFC.


Thanks,

    Yaron


Dan McDonald wrote:

On Mon, Sep 15, 2008 at 01:59:44PM +0300, Tero Kivinen wrote:
<mucho snippage deleted!>
  
I do not want to add any more complications to the IKE thus I do not
think we need any alignment payloads.
    

Fair enough.  I was more curious than anything else.

I would *recommend* to people, though, especially given that we've agreed
that payload order doesn't matter, that it would be nice if
known-to-be-aligned payloads go first.

Thanks,
Dan
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.
--------------060408000309050107000903-- --------------ms040708020706020103090407 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRTTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggYyMIIFGqADAgECAhEAgMrIN93nrNdSrhqpeULWJjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0wODA5MTAwMDAwMDBaFw0wOTA5MTAyMzU5NTlaMIHeMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNWWFyb24gU2hlZmZlcjEkMCIGCSqGSIb3DQEJARYVeWFyb25mQGNoZWNrcG9pbnQuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuoavXgAQ/+VLs6BdNizwuOYNliDc p6Cl0Ze58Bdr3c1uYABDUSaqRUHDy8L8RxgIz4P25RZ4rS4LsGmYJqUUOHbwAwwhQohbRUa8 MX6QTzOOdyH+PvCGha86+PrIXFhk173N9SVlnvEFz4sQ/Oqx3igtsrtrtaS9kC5Qd8fSiIeT aaIRmRdkX+aGkan8umUt4DxvnV+9CG/xSojPBGCFVMsMICciFWT/D5YyZGFwem1hkNrSA6GP LNpr/iQbWgfDjgB71xmnCzxNcv4k6tR2Ykbq4VjfAHRi8/D1v+7RZ5jtKerRsMXny8M3DSNp Cx8ijHEQT4yxwD0lu5o9pcgV2QIDAQABo4ICFzCCAhMwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFI1sqGIlUgOSHLkdED6ePL6haIowMA4GA1UdDwEB/wQE AwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjAR BglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEF BQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqg SIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50 aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1V U0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEE YDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRD QS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAgBgNVHREEGTAX gRV5YXJvbmZAY2hlY2twb2ludC5jb20wDQYJKoZIhvcNAQEFBQADggEBAF6aCGSenu0JxYn4 /O+imThscFppgX80m2StItcl05vynbzq45L7umjQMgT7OH2IjJUxOrkYWSV5XMhVAdY4g58I yfFtiHq2CslRkp0Mcwkba+HPaLZ0U4nNacyeixaYqwMMyma0swfWaf7fWVCSn6uBQCS4VSu4 A+sbqazkFVo79Nr7IEZ0QnR5ws4q4DfOYqebLxt5x5embg52QEZZZ0u8Ea4//6/yfwrBV/bP M1Npl4TL7Xf0wf0ZOtVOIec6yB2S++xO7twCXeaFHFH6jrRdTR9B2TeO1s+vN4W4rl9NjrIq VbZ7+uUmDeECvcWQimzM1GCe74FQNgWD1WdiONgwggYyMIIFGqADAgECAhEAgMrIN93nrNdS rhqpeULWJjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0wODA5MTAwMDAwMDBa Fw0wOTA5MTAyMzU5NTlaMIHeMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2Yg dXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAw MyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNWWFyb24gU2hlZmZlcjEkMCIGCSqGSIb3DQEJ ARYVeWFyb25mQGNoZWNrcG9pbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAuoavXgAQ/+VLs6BdNizwuOYNliDcp6Cl0Ze58Bdr3c1uYABDUSaqRUHDy8L8RxgIz4P2 5RZ4rS4LsGmYJqUUOHbwAwwhQohbRUa8MX6QTzOOdyH+PvCGha86+PrIXFhk173N9SVlnvEF z4sQ/Oqx3igtsrtrtaS9kC5Qd8fSiIeTaaIRmRdkX+aGkan8umUt4DxvnV+9CG/xSojPBGCF VMsMICciFWT/D5YyZGFwem1hkNrSA6GPLNpr/iQbWgfDjgB71xmnCzxNcv4k6tR2Ykbq4Vjf AHRi8/D1v+7RZ5jtKerRsMXny8M3DSNpCx8ijHEQT4yxwD0lu5o9pcgV2QIDAQABo4ICFzCC AhMwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFI1sqGIlUgOS HLkdED6ePL6haIowMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7 BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5l dC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVRO LVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0 cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25h bmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNv bW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmNvbW9kb2NhLmNvbTAgBgNVHREEGTAXgRV5YXJvbmZAY2hlY2twb2ludC5jb20wDQYJKoZI hvcNAQEFBQADggEBAF6aCGSenu0JxYn4/O+imThscFppgX80m2StItcl05vynbzq45L7umjQ MgT7OH2IjJUxOrkYWSV5XMhVAdY4g58IyfFtiHq2CslRkp0Mcwkba+HPaLZ0U4nNacyeixaY qwMMyma0swfWaf7fWVCSn6uBQCS4VSu4A+sbqazkFVo79Nr7IEZ0QnR5ws4q4DfOYqebLxt5 x5embg52QEZZZ0u8Ea4//6/yfwrBV/bPM1Npl4TL7Xf0wf0ZOtVOIec6yB2S++xO7twCXeaF HFH6jrRdTR9B2TeO1s+vN4W4rl9NjrIqVbZ7+uUmDeECvcWQimzM1GCe74FQNgWD1WdiONgx ggRTMIIETwIBATCBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5T YWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQL ExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwCQYFKw4D AhoFAKCCAmMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgw OTE2MDYxNDE5WjAjBgkqhkiG9w0BCQQxFgQUBc5eM1wAAhKm9gs0B23NUuciB8swUgYJKoZI hvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgdUGCSsGAQQBgjcQBDGBxzCBxDCBrjELMAkGA1UE BhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMV VGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5j b20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBF bWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwgdcGCyqGSIb3DQEJEAILMYHHoIHEMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQK ExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0 LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5k IEVtYWlsAhEAgMrIN93nrNdSrhqpeULWJjANBgkqhkiG9w0BAQEFAASCAQAAA6pkXIiOSfhL ZeHk2Fasb8ko82jUf7XisuGNO0PNYHcka8CjDLRC9ZrzG/voC7WvDdo/gk6Po4wBfDxdki1Y 7/z2SmzUWov3L18ozfrIKqqzRfWBzQFwty/X546b1Ql+CRX87t0vcFdXd1wyf5rcu/8E3Uxf 8cEdWF+3KPBwvS0Mpyrg2FeWQsWv8DP13/4MhKL4ACddc0u/NfuZ9DAj56K9Yl3E1zUgQW6m swRN1T8X/rTIa2z3V/TXjBMjVUjvo0NH4T3ph6JZ+cy+WfKFt3enSFMa4gKXr0PMYfYcC7N6 044Rv1RrQgVKXMTrQFfBwmczfz6S8b9OwdVeuSNpAAAAAAAA --------------ms040708020706020103090407-- --===============0216916254== 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 --===============0216916254==-- From ipsec-bounces@ietf.org Tue Sep 16 00:17:40 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DF5328C120; Tue, 16 Sep 2008 00:17: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 DA8B028C120 for ; Tue, 16 Sep 2008 00:17:38 -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 hroOV5jPFPhg for ; Tue, 16 Sep 2008 00:17:38 -0700 (PDT) Received: from strongswan.org (sidv0150.hsr.ch [152.96.52.150]) by core3.amsl.com (Postfix) with ESMTP id 8CC1328C0E8 for ; Tue, 16 Sep 2008 00:17:37 -0700 (PDT) Received: from [152.96.15.212] (unknown [152.96.15.212]) by strongswan.org (Postfix) with ESMTP id 14B31EFA2A for ; Tue, 16 Sep 2008 09:17:31 +0200 (CEST) Message-ID: <48CF5D7D.7070701@strongswan.org> Date: Tue, 16 Sep 2008 09:17:17 +0200 From: Martin Willi User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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, The reauthentication procedure for IKEv2 works as follows (from draft-ietf-ipsecme-ikev2bis-00 2.8.2): IKEv2 does not have any special support for reauthentication. Reauthentication is done by creating a new IKE_SA from scratch (using IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify payloads), creating new CHILD_SAs within the new IKE_SA (without REKEY_SA notify payloads), and finally deleting the old IKE_SA (which deletes the old CHILD_SAs as well). While this approach works and reuses existing protocol elements, it has some disadvantages. The problem is that we actually can't know that an incoming IKE_SA setup is used for reauthentication, as creating multiple identical IKE_SAs is perfectly feasible. 1. If a lot CHILD_SAs are established within the IKE_SA, this procedure needs a lot of exchanges to complete, increase load and reauth duration. During this stage, we also have multiple CHILD_SAs with the same traffic selectors. Defining priorities is difficult, as we don't know if the new IKE_SA is actually for reauthentication or not. 2. The server doesn't know that the new IKE_SA creation is used for reauthentication and can't assign the same INTERNAL_ADDRESS to the peer without risking an address conflict. This will result in an address change and will close established connections using that address. 3. Housekeeping and connection monitoring gets ways more complicated, as the new IKE_SA does not have any relation to the old one. Mainly because of 2., we have been forced to do the reauthentication procedure by closing the IKE_SA before establishing the new one. This will eliminate the address flicker, but introduces a connectivity gap of seconds. While there are workarounds to these problems, I don't see a way to implement reauthentication properly and reliable. Because of these problems I'm thinking about an extension to do the reauthentication within an established IKE_SA (think of the existing rekeying procedure, but with an additional AUTH/EAP exchange). What do you think about such an extension? Already considered something similar, or does your reauthentication procedure work hassle-free? I'm wondering if we are the only ones facing these problems or if such an extension would gain broader acceptance... Regards, Martin - strongSwan project _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 16 02:09:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A663128C1AB; Tue, 16 Sep 2008 02:09:23 -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 B9F7D3A691A for ; Tue, 16 Sep 2008 02:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Z6BAaE2W37Af for ; Tue, 16 Sep 2008 02:09:18 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 8240E3A68D8 for ; Tue, 16 Sep 2008 02:09:07 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8G99FIM000872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2008 12:09:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8G99EJ2016866; Tue, 16 Sep 2008 12:09:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18639.30650.345788.976989@fireball.kivinen.iki.fi> Date: Tue, 16 Sep 2008 12:09:14 +0300 From: Tero Kivinen To: Martin Willi In-Reply-To: <48CF5D7D.7070701@strongswan.org> References: <48CF5D7D.7070701@strongswan.org> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 11 min X-Total-Time: 12 min Cc: ipsec@ietf.org Subject: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Martin Willi writes: > What do you think about such an extension? Already considered something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... The first question I have is why are you doing reauthentication at all? What is the benefits of the reauthentication? What is the benefits of the reauthentication that can be done WITHOUT user intervention (i.e. no user typing in password or pin code or fingerprint or similar)? I myself can only really see benefits from reauthentication when it does require that user is really sitting there on the machine, and gives something that the machine itself cannot give. In those cases the user is required to type in something or do something anyways, thus it does not really matter if the communications is interrupted for second if user must stop his work for much longer time to type in his passphrase or pin code. The RFC 4478 simply skips this question and says "With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that security associations (SAs) can be used by a third party who has gained control of the IPsec peer." In most cases if third party has gained control of the IPsec peer he will also get control of all authentication information inside the peer, including private keys and pre shared keys. Only way to make sure that he does not get access to those is to protect them with passphrase, or pin code or similar that is only known by the user. This is also said out in the RFC 4478: "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials ..." Because of this I do not think there is that much requirement for reauthentication protocol that is faster than what we already have. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 16 04:15:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 874F928C1AA; Tue, 16 Sep 2008 04:15:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7D828C198 for ; Tue, 16 Sep 2008 04:15:23 -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 63O1MJaZw4PA for ; Tue, 16 Sep 2008 04:15:22 -0700 (PDT) Received: from strongswan.org (sidv0150.hsr.ch [152.96.52.150]) by core3.amsl.com (Postfix) with ESMTP id 4F95F3A6AA1 for ; Tue, 16 Sep 2008 04:15:22 -0700 (PDT) Received: from [152.96.15.212] (unknown [152.96.15.212]) by strongswan.org (Postfix) with ESMTP id 53CE2EFA2A; Tue, 16 Sep 2008 13:15:32 +0200 (CEST) Message-ID: <48CF9549.6060607@strongswan.org> Date: Tue, 16 Sep 2008 13:15:21 +0200 From: Martin Willi User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Tero Kivinen References: <48CF5D7D.7070701@strongswan.org> <18639.30650.345788.976989@fireball.kivinen.iki.fi> In-Reply-To: <18639.30650.345788.976989@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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, > I myself can only really see benefits from reauthentication when it > does require that user is really sitting there on the machine, and > gives something that the machine itself cannot give. Yes I absolutely agree, this is the point of reauthentication. If the user uses smartcard authentication and leaves for a coffee break, he removes the smartcard. This will keep the tunnel and all applications up until the user returns. If he does not return in time, the tunnel will get unusable. > the user is required to type in something or do something anyways, > thus it does not really matter if the communications is interrupted > for second if user must stop his work for much longer time to type in > his passphrase or pin code. If the pin code is cached while the smartcard is connected, no user intervention is required at all. But the real problem are application session: They might break during these communication interrupts, and are guaranteed to break if the INTERNAL_ADDRESS changes. > Because of this I do not think there is that much requirement for > reauthentication protocol that is faster than what we already have. Speed is not the main problem, but keeping up IPsec tunnels during reauthentication. Martin _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 16 05:03:37 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B0B28C136; Tue, 16 Sep 2008 05:03:37 -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 93EC13A6B64 for ; Tue, 16 Sep 2008 05:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 XtyNO5aiEiat for ; Tue, 16 Sep 2008 05:03:30 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 98E773A6A43 for ; Tue, 16 Sep 2008 05:03:18 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8GC3Qs4000250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Sep 2008 15:03:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8GC3OpL027323; Tue, 16 Sep 2008 15:03:24 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18639.41100.797684.125348@fireball.kivinen.iki.fi> Date: Tue, 16 Sep 2008 15:03:24 +0300 From: Tero Kivinen To: Martin Willi In-Reply-To: <48CF9549.6060607@strongswan.org> References: <48CF5D7D.7070701@strongswan.org> <18639.30650.345788.976989@fireball.kivinen.iki.fi> <48CF9549.6060607@strongswan.org> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 16 min X-Total-Time: 20 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Martin Willi writes: > But the real problem are application session: They might break during > these communication interrupts, and are guaranteed to break if the > INTERNAL_ADDRESS changes. I agree, thats why I think the way you presented there where you first remove the IKE SA and then start it over so you get the same address is the only one that really works. In most cases for remote access cases you have only one IPsec SA so creating new IKE SA and that IPsec SA is fast and should not disturb normal TCP/IP flows (unless your operating system does stupid things, like destroy all TCP/IP flows when you do the recreationg of the IKE SA). > > Because of this I do not think there is that much requirement for > > reauthentication protocol that is faster than what we already have. > > Speed is not the main problem, but keeping up IPsec tunnels during > reauthentication. I do not really think we need to keep the IPsec tunnels up. We do need to keep the TCP/IP connections running inside those IPsec tunnels up. In most remote access cases the number of IPsec SAs is very small (usually one). In cases where you are doing host to host transport mode IPsec, you can have lots of IPsec SAs, but in those cases most of them are also between different peers. Can you give some example where you really have lots of (hundreds of IPsec SAs) between two peers in cases where you would like to use reauthentication? If we are only talking about the INTERNAL_ADDRESS cases, there might be better ways to solve it. For example an exchange in the old IKE SA which releases the address (and forbids making new IPsec SAs for the IKE SA, but still keeps existing IPsec SAs working), and then the new IKE SA can get the same address and then you can create new IPsec SAs and delete the old ones from old IKE SA until you have moved all traffic and then you can remove old IKE SA. Or you could even make the implementation so it allows requesting and getting the same address for 2 different IKE SAs provided they both come from same IP-address and port, and are using exactly same identity to authenticate them, and the new IKE SA creation didn't use INITIAL_CONTACT notification, but did include all exactly same parameters given to first IKE SA as hints when doing configuration payloads. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 16 07:09:35 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5BA3A6A29; Tue, 16 Sep 2008 07:09:35 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B4223A6B5A for ; Tue, 16 Sep 2008 07:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uYu9A8918H2n for ; Tue, 16 Sep 2008 07:09:28 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 0D74B3A6A29 for ; Tue, 16 Sep 2008 07:09:27 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8GEC7gN025069 for ; Tue, 16 Sep 2008 10:12:07 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8GE9E5I265490 for ; Tue, 16 Sep 2008 10:09:20 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8GE9ExR031381 for ; Tue, 16 Sep 2008 10:09:14 -0400 Received: from d01mll83.pok.ibm.com (d01mll83.pok.ibm.com [9.57.160.143]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8GE9CoK031222 for ; Tue, 16 Sep 2008 10:09:13 -0400 To: ipsec@ietf.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Tue, 16 Sep 2008 10:09:10 -0400 X-MIMETrack: Serialize by Router on D01MLL83/01/M/IBM(Release 7.0.2FP2|April 16, 2007) at 09/16/2008 10:09:14 MIME-Version: 1.0 Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1541717948==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1541717948== Content-type: multipart/alternative; Boundary="0__=0ABBFE55DFDE14748f9e8a93df938690918c0ABBFE55DFDE1474" Content-Disposition: inline --0__=0ABBFE55DFDE14748f9e8a93df938690918c0ABBFE55DFDE1474 Content-type: text/plain; charset=US-ASCII >> What do you think about such an extension? Already considered something >> similar, or does your reauthentication procedure work hassle-free? I'm >> wondering if we are the only ones facing these problems or if such an >> extension would gain broader acceptance... > >The first question I have is why are you doing reauthentication at >all? > >What is the benefits of the reauthentication? > >What is the benefits of the reauthentication that can be done WITHOUT >user intervention (i.e. no user typing in password or pin code or >fingerprint or similar)? > >I myself can only really see benefits from reauthentication when it >does require that user is really sitting there on the machine, and >gives something that the machine itself cannot give. In those cases >the user is required to type in something or do something anyways, >thus it does not really matter if the communications is interrupted >for second if user must stop his work for much longer time to type in >his passphrase or pin code. > >The RFC 4478 simply skips this question and says "With some IPsec >peers, particularly in the remote access scenario, it is desirable to >repeat the mutual authentication periodically. The purpose of this is >to limit the time that security associations (SAs) can be used by a >third party who has gained control of the IPsec peer." > RCF 4718 States: While rekeying the IKE_SA may be important in some environments, reauthentication (the verification that the parties still have access to the long-term credentials) is often more important. Bottom line is that some implementers believe reauthentication makes sense. Given that it seems as if Martin's request for an extension is reasonable. As I pointed out in the past there is no way to detect the simultaneous reauthentication of an IKE_SA. Such an extension would solve that issue. >In most cases if third party has gained control of the IPsec peer he >will also get control of all authentication information inside the >peer, including private keys and pre shared keys. Only way to make >sure that he does not get access to those is to protect them with >passphrase, or pin code or similar that is only known by the user. > >This is also said out in the RFC 4478: "However, in the remote access >scenario it is usually up to a human user to supply the >authentication credentials ..." > >Because of this I do not think there is that much requirement for >reauthentication protocol that is faster than what we already have. Dave Wierbowski z/OS Comm Server Developer --0__=0ABBFE55DFDE14748f9e8a93df938690918c0ABBFE55DFDE1474 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

>> What do you think about such an extension? Already considered something
>> similar, or does your reauthentication procedure work hassle-free? I'm
>> wondering if we are the only ones facing these problems or if such an
>> extension would gain broader acceptance...
>
>The first question I have is why are you doing reauthentication at
>all?
>
>What is the benefits of the reauthentication?
>
>What is the benefits of the reauthentication that can be done WITHOUT
>user intervention (i.e. no user typing in password or pin code or
>fingerprint or similar)?
>
>I myself can only really see benefits from reauthentication when it
>does require that user is really sitting there on the machine, and
>gives something that the machine itself cannot give. In those cases
>the user is required to type in something or do something anyways,
>thus it does not really matter if the communications is interrupted
>for second if user must stop his work for much longer time to type in
>his passphrase or pin code.
>
>The RFC 4478 simply skips this question and says "With some IPsec
>peers, particularly in the remote access scenario, it is desirable to
>repeat the mutual authentication periodically. The purpose of this is
>to limit the time that security associations (SAs) can be used by a
>third party who has gained control of the IPsec peer."
>
RCF 4718 States:
While rekeying the IKE_SA may be important in some environments,
reauthentication (the verification that the parties still have access
to the long-term credentials) is often more important.

Bottom line is that some implementers believe reauthentication
makes sense. Given that it seems as if Martin's request for an
extension is reasonable. As I pointed out in the past there is
no way to detect the simultaneous reauthentication of an IKE_SA.
Such an extension would solve that issue.

>In most cases if third party has gained control of the IPsec peer he
>will also get control of all authentication information inside the
>peer, including private keys and pre shared keys. Only way to make
>sure that he does not get access to those is to protect them with
>passphrase, or pin code or similar that is only known by the user.
>
>This is also said out in the RFC 4478: "However, in the remote access
>scenario it is usually up to a human user to supply the
>authentication credentials ..."
>
>Because of this I do not think there is that much requirement for
>reauthentication protocol that is faster than what we already have.

Dave Wierbowski


z/OS Comm Server Developer


--0__=0ABBFE55DFDE14748f9e8a93df938690918c0ABBFE55DFDE1474-- --===============1541717948== 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 --===============1541717948==-- From ipsec-bounces@ietf.org Tue Sep 16 07:12:15 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFA603A68D8; Tue, 16 Sep 2008 07:12: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 B9CAB28C1E0 for ; Tue, 16 Sep 2008 07:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ScFEhSSNi85L for ; Tue, 16 Sep 2008 07:12:09 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 912423A6B5A for ; Tue, 16 Sep 2008 07:12:09 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8GECL1o009000 for ; Tue, 16 Sep 2008 10:12:21 -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 v9.1) with ESMTP id m8GECLgT271284 for ; Tue, 16 Sep 2008 10:12:21 -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 m8GECKVO003749 for ; Tue, 16 Sep 2008 10:12:20 -0400 Received: from d01mll83.pok.ibm.com (d01mll83.pok.ibm.com [9.57.160.143]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8GECKIu003705 for ; Tue, 16 Sep 2008 10:12:20 -0400 To: ipsec@ietf.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: David Wierbowski Date: Tue, 16 Sep 2008 10:12:21 -0400 X-MIMETrack: Serialize by Router on D01MLL83/01/M/IBM(Release 7.0.2FP2|April 16, 2007) at 09/16/2008 10:12:21 MIME-Version: 1.0 Subject: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1213284725==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1213284725== Content-type: multipart/alternative; Boundary="0__=0ABBFE55DFDE4FE38f9e8a93df938690918c0ABBFE55DFDE4FE3" Content-Disposition: inline --0__=0ABBFE55DFDE4FE38f9e8a93df938690918c0ABBFE55DFDE4FE3 Content-type: text/plain; charset=US-ASCII >> But the real problem are application session: They might break during >> these communication interrupts, and are guaranteed to break if the >> INTERNAL_ADDRESS changes. > >I agree, thats why I think the way you presented there where you first >remove the IKE SA and then start it over so you get the same address >is the only one that really works. In most cases for remote >access cases you have only one IPsec SA so creating new IKE SA and >that IPsec SA is fast and should not disturb normal TCP/IP flows >(unless your operating system does stupid things, like destroy all >TCP/IP flows when you do the recreationg of the IKE SA). Are we clarifying the IKEv2 clarifications now? RFC 4718 states: IKEv2 does not have any special support for reauthentication. Reauthentication is done by creating a new IKE_SA from scratch (using IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify payloads), creating new CHILD_SAs within the new IKE_SA (without REKEY_SA notify payloads), and finally deleting the old IKE_SA (which deletes the old CHILD_SAs as well). The suggestion above contradicts 4718. It seems as if the best resolution would be to add real support for reauthentication. Dave Wierbowski z/OS Comm Server Developer --0__=0ABBFE55DFDE4FE38f9e8a93df938690918c0ABBFE55DFDE4FE3 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

>> But the real problem are application session: They might break during
>> these communication interrupts, and are guaranteed to break if the
>> INTERNAL_ADDRESS changes.
>
>I agree, thats why I think the way you presented there where you first
>remove the IKE SA and then start it over so you get the same address
>is the only one that really works. In most cases for remote
>access cases you have only one IPsec SA so creating new IKE SA and
>that IPsec SA is fast and should not disturb normal TCP/IP flows
>(unless your operating system does stupid things, like destroy all
>TCP/IP flows when you do the recreationg of the IKE SA).

Are we clarifying the IKEv2 clarifications now? RFC 4718 states:

IKEv2 does not have any special support for reauthentication.
Reauthentication is done by creating a new IKE_SA from scratch (using
IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
payloads), creating new CHILD_SAs within the new IKE_SA (without
REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
deletes the old CHILD_SAs as well).

The suggestion above contradicts 4718. It seems as if the best resolution
would be to add real support for reauthentication.

Dave Wierbowski


z/OS Comm Server Developer


--0__=0ABBFE55DFDE4FE38f9e8a93df938690918c0ABBFE55DFDE4FE3-- --===============1213284725== 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 --===============1213284725==-- From ipsec-bounces@ietf.org Tue Sep 16 14:24:48 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E74F3A695A; Tue, 16 Sep 2008 14:24:48 -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 CEAD93A695A for ; Tue, 16 Sep 2008 14:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 7+zlSpvAcnH8 for ; Tue, 16 Sep 2008 14:24:46 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 508F53A6826 for ; Tue, 16 Sep 2008 14:24:46 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 04594294002; Wed, 17 Sep 2008 00:24:57 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 89564294001; Wed, 17 Sep 2008 00:23:14 +0300 (IDT) Received: from [172.31.24.66] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8GLNDOx002021; Wed, 17 Sep 2008 00:23:13 +0300 (IDT) Message-Id: <2AE5C31F-D8AB-4135-86A1-E000ADD0FB5B@checkpoint.com> From: Yoav Nir To: Martin Willi In-Reply-To: <48CF5D7D.7070701@strongswan.org> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 16 Sep 2008 22:23:12 +0100 References: <48CF5D7D.7070701@strongswan.org> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Martin. Please see my comments below. On Sep 16, 2008, at 8:17 AM, Martin Willi wrote: > Hi, > > The reauthentication procedure for IKEv2 works as follows (from > draft-ietf-ipsecme-ikev2bis-00 2.8.2): > > IKEv2 does not have any special support for reauthentication. > Reauthentication is done by creating a new IKE_SA from scratch > (using > IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify > payloads), creating new CHILD_SAs within the new IKE_SA (without > REKEY_SA notify payloads), and finally deleting the old IKE_SA > (which > deletes the old CHILD_SAs as well). > > While this approach works and reuses existing protocol elements, it > has > some disadvantages. The problem is that we actually can't know that an > incoming IKE_SA setup is used for reauthentication, as creating > multiple > identical IKE_SAs is perfectly feasible. > > 1. If a lot CHILD_SAs are established within the IKE_SA, this > procedure > needs a lot of exchanges to complete, increase load and reauth > duration. During this stage, we also have multiple CHILD_SAs with > the same traffic selectors. Defining priorities is difficult, as > we don't know if the new IKE_SA is actually for reauthentication or > not. Multiple CHILD_SAs is not a problem, as that is also explicitly permitted by RFC 4306. As long as the old CHILD_SA has not been deleted, it's perfectly fine to use it. Besides, as Tero said, remote access VPNs tend to have either one child SA or only a few. I do see a problem with the text, in that it says that you re-create all the child SAs before deleting the old IKE SA. IMO the better way is to (1) create a new IKE SA, (2) delete the old IKE SA (and all associated child SAs) and then (3) create new child SAs as needed. > > 2. The server doesn't know that the new IKE_SA creation is used for > reauthentication and can't assign the same INTERNAL_ADDRESS to the > peer without risking an address conflict. This will result in an > address change and will close established connections using that > address. In the new IKE_AUTH exchange, the initiator will have the same IDi payload as in the setup of the old SA. Additionally, the initiator will ask not for any IP address in CFG, but for the IP address that it already has. If this condition is met (address belongs to an IKE SA authenticated with the same IDi), it's OK to re-assign the IP address. > > 3. Housekeeping and connection monitoring gets ways more complicated, > as the new IKE_SA does not have any relation to the old one. I agree. > Mainly because of 2., we have been forced to do the reauthentication > procedure by closing the IKE_SA before establishing the new one. This > will eliminate the address flicker, but introduces a connectivity > gap of > seconds. Again, I don't think that #2 is a problem. > While there are workarounds to these problems, I don't see a way to > implement reauthentication properly and reliable. Because of these > problems I'm thinking about an extension to do the reauthentication > within an established IKE_SA (think of the existing rekeying > procedure, > but with an additional AUTH/EAP exchange). > > What do you think about such an extension? Already considered > something > similar, or does your reauthentication procedure work hassle-free? I'm > wondering if we are the only ones facing these problems or if such an > extension would gain broader acceptance... OK, when I was writing 4478, I did consider four possibilities: 1. Do nothing. Let's call the client Carol and the server Steve. Steve just deletes the IKE SA when it's time, and Carol begins a new IKE SA at once. 2. What 4478 says. Re-authenticate by making a new IKE SA and deleting the old one. New child SAs created as needed. Steve only tells Carol when she should re-authenticate. The advantage here is that Carol the user can type in her password or insert her smartcard at her leisure, without her connections being cut. It's also rather simple to implement over an existing IKEv2, and if Carol doesn't support the extension, we revert to #1. 3. In addition to #2, add an indication to the AUTH exchange (using a notification probably) that this replaces this old IKE SA. In that case, after the AUTH exchange completes, all child SAs are transferred to the new IKE SA, and so does the CFG address. This was rejected by people on this mailing list, because it makes the code more complicated, and doesn't save us anything. 4. Similar to what you propose. we can do the AUTH exchange alone, under the existing IKE SA (with or without rekeying) and no new child SAs at all. There is the question of what buffer we would be signing with the AUTH payloads (do we keep a copy of the original INITIAL exchange?), but this can be resolved one way or another. This is probably what Dave Wierbowski means by "real support". It's also more efficient on the wire and in terms of computation. I agree that this makes a lot of sense, and if we were designing IKEv3 now, I would be all for this. However, this is an extension that is usable is some scenarios but not others. As AUTH is defined now in the RFCs and in the bis document, you're not allowed to do an AUTH exchange without a piggybacked CHILD SA exchange, and you're not allowed to do an AUTH exchange over an open IKE SA, in parallel with other exchanges (maybe the window is not 1) and with existing child SAs. All these differences may mean a significant change to the state machines for the AUTH exchange. I liked option #4 very much, but I felt that it was too much of an alteration to IKEv2 for the benefit it gives. Using the make-before- break logic of RFC 4478 you can get the same results, with slightly less efficiency, but with substantially less code complexity. That seems to me to be the better balance. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 16 14:28:33 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 803033A695F; Tue, 16 Sep 2008 14:28: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 421F23A695F for ; Tue, 16 Sep 2008 14:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 cLCZMPFObbaa for ; Tue, 16 Sep 2008 14:28:31 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 4444C3A686C for ; Tue, 16 Sep 2008 14:28:31 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3D91F294003; Wed, 17 Sep 2008 00:28:43 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6A837294001; Wed, 17 Sep 2008 00:28:42 +0300 (IDT) Received: from [172.31.24.66] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8GLSfOx002986; Wed, 17 Sep 2008 00:28:41 +0300 (IDT) Message-Id: <701D2D87-4D49-44F5-BA39-1B83B4C4413A@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18639.41100.797684.125348@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 16 Sep 2008 22:28:40 +0100 References: <48CF5D7D.7070701@strongswan.org> <18639.30650.345788.976989@fireball.kivinen.iki.fi> <48CF9549.6060607@strongswan.org> <18639.41100.797684.125348@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Sep 16, 2008, at 1:03 PM, Tero Kivinen wrote: > Martin Willi writes: >> But the real problem are application session: They might break during >> these communication interrupts, and are guaranteed to break if the >> INTERNAL_ADDRESS changes. > > I agree, thats why I think the way you presented there where you first > remove the IKE SA and then start it over so you get the same address > is the only one that really works. In most cases for remote > access cases you have only one IPsec SA so creating new IKE SA and > that IPsec SA is fast and should not disturb normal TCP/IP flows > (unless your operating system does stupid things, like destroy all > TCP/IP flows when you do the recreationg of the IKE SA). Destroying the TCP/IP flows because of IKE SA is stupid. But it does make sense to turn off the virtual interface if the IKE SA has been destroyed, and no new IKE SA is created. That's why I prefer the make- before-break way. > > >>> Because of this I do not think there is that much requirement for >>> reauthentication protocol that is faster than what we already have. >> >> Speed is not the main problem, but keeping up IPsec tunnels during >> reauthentication. > > I do not really think we need to keep the IPsec tunnels up. We do need > to keep the TCP/IP connections running inside those IPsec tunnels up. > In most remote access cases the number of IPsec SAs is very small > (usually one). In cases where you are doing host to host transport > mode IPsec, you can have lots of IPsec SAs, but in those cases most of > them are also between different peers. > > Can you give some example where you really have lots of (hundreds of > IPsec SAs) between two peers in cases where you would like to use > reauthentication? > > If we are only talking about the INTERNAL_ADDRESS cases, there might > be better ways to solve it. For example an exchange in the old IKE SA > which releases the address (and forbids making new IPsec SAs for the > IKE SA, but still keeps existing IPsec SAs working), and then the new > IKE SA can get the same address and then you can create new IPsec SAs > and delete the old ones from old IKE SA until you have moved all > traffic and then you can remove old IKE SA. Or you could even make the > implementation so it allows requesting and getting the same address > for 2 different IKE SAs provided they both come from same IP-address > and port, and are using exactly same identity to authenticate them, > and the new IKE SA creation didn't use INITIAL_CONTACT notification, > but did include all exactly same parameters given to first IKE SA as > hints when doing configuration payloads. Agree, but I think you don't even need IP and port. Just same IDi and requesting same address. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 17 03:35:48 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452B228C10C; Wed, 17 Sep 2008 03:35:48 -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 DAF0628C10C for ; Wed, 17 Sep 2008 03:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 PLp7TFHHTl0J for ; Wed, 17 Sep 2008 03:35:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id E728D3A659B for ; Wed, 17 Sep 2008 03:35:38 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8HAZm8B014490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Sep 2008 13:35:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8HAZkad020817; Wed, 17 Sep 2008 13:35:46 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18640.56706.660550.115329@fireball.kivinen.iki.fi> Date: Wed, 17 Sep 2008 13:35:46 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 15 min X-Total-Time: 22 min Cc: ipsec@ietf.org Subject: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 David Wierbowski writes: > > >> But the real problem are application session: They might break during > >> these communication interrupts, and are guaranteed to break if the > >> INTERNAL_ADDRESS changes. > > > >I agree, thats why I think the way you presented there where you first > >remove the IKE SA and then start it over so you get the same address > >is the only one that really works. In most cases for remote > >access cases you have only one IPsec SA so creating new IKE SA and > >that IPsec SA is fast and should not disturb normal TCP/IP flows > >(unless your operating system does stupid things, like destroy all > >TCP/IP flows when you do the recreationg of the IKE SA). > > Are we clarifying the IKEv2 clarifications now? No, I think the plan was to have new protocol. > RFC 4718 states: > > IKEv2 does not have any special support for reauthentication. > Reauthentication is done by creating a new IKE_SA from scratch (using > IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify > payloads), creating new CHILD_SAs within the new IKE_SA (without > REKEY_SA notify payloads), and finally deleting the old IKE_SA (which > deletes the old CHILD_SAs as well). > > The suggestion above contradicts 4718. That way of reauthentication is good if you do not have internal ip allocated from the gateway. If you do have internal ip-address allocated from the gateway, then that will most likely fail, as unless the server implementation knows how about reauthentications it will not allow giving out same IP-address to some other IKE SA. > It seems as if the best resolution > would be to add real support for reauthentication. If we add new reauthentication protocol that would need to be separate document not part of IKEv2bis. If we simply clarify how to do the reauthentication without adding new protocols that can most likely be added to the IKEv2bis. We could for example add following paragraph to explain reauthentication (after the paragraph you quoted): This method of reauthentication can introduce problems when used in combiation with configuration payloads (i.e. when client has INTERNAL_ADDRESS allocated from the gateway) unless the server implementation allows duplicate INTERNAL_ADDRESSs to be allocated to new IKE SA even when it is still in use with the old IKE SA. The server implementation should check that such duplicate addresses are only allowed when the new IKE SA connection comes from the same IP address and port, and has same configuration parameters than the existing IKE SA (i.e. requests same IP-address that is already in use) and when the authenticated identity of the both IKE SAs is exactly same. The server can also move the old IKE SA to degraded state, where it refuses to create more IPsec SAs (returning NO_ADDITIONAL_SAS error instead). (I noticed that mentioning INITIAL_CONTACT notification is not needed, as if there is INITIAL_CONTACT in the new IKE SA then the old IKE SA will be removed when processing that INITIAL_CONTACT notification, thus the IP address will be free). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 17 04:03:38 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A89723A6C91; Wed, 17 Sep 2008 04:03:38 -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 B23B73A6C91 for ; Wed, 17 Sep 2008 04:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 phxxstjx6XGn for ; Wed, 17 Sep 2008 04:03:32 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 05FF13A6C22 for ; Wed, 17 Sep 2008 04:03:20 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8HB3Rac003931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Sep 2008 14:03:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8HB3QSW006327; Wed, 17 Sep 2008 14:03:26 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18640.58366.503035.79923@fireball.kivinen.iki.fi> Date: Wed, 17 Sep 2008 14:03:26 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <701D2D87-4D49-44F5-BA39-1B83B4C4413A@checkpoint.com> References: <48CF5D7D.7070701@strongswan.org> <18639.30650.345788.976989@fireball.kivinen.iki.fi> <48CF9549.6060607@strongswan.org> <18639.41100.797684.125348@fireball.kivinen.iki.fi> <701D2D87-4D49-44F5-BA39-1B83B4C4413A@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > Agree, but I think you don't even need IP and port. Just same IDi and > requesting same address. The IP and port check would protect against cases where you happen to have 2 laptops or similars sharing same ID and same authentication data. In normal case that should not happen, but that might happen (for example when you have new and old laptop and are moving stuff from old to new etc) and adding those checks is cheap and they should not affect normal use. I.e. if the IP-address is different then second connection is considered to be new connection instead of reauthentication, and it gets new internal IP-address and everything works. Do you see any problems by adding the IP address and port check? Only case I can see is when using mobike and moving between IP-addresses and doing reauthentication at the exactly same time. This could be prevented by saying that the IP-address check includes all possible IP-addresses the client has announced in the additional addresses notifications. The problems by giving two different devices same IP-address is more serious than changing the IP-address of existing device, so thats why I think we want to make strict checks to detect that the devices are same. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 17 04:36:21 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55C1E3A6C81; Wed, 17 Sep 2008 04:36: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 CA2D73A6C81 for ; Wed, 17 Sep 2008 04:36:19 -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 JsJyQ+WWgqud for ; Wed, 17 Sep 2008 04:36:16 -0700 (PDT) Received: from strongswan.org (sidv0150.hsr.ch [152.96.52.150]) by core3.amsl.com (Postfix) with ESMTP id 005193A6966 for ; Wed, 17 Sep 2008 04:36:15 -0700 (PDT) Received: from [152.96.15.212] (unknown [152.96.15.212]) by strongswan.org (Postfix) with ESMTP id 4EAD0EFA3D; Wed, 17 Sep 2008 13:36:10 +0200 (CEST) Message-ID: <48D0EB98.9020105@strongswan.org> Date: Wed, 17 Sep 2008 13:35:52 +0200 From: Martin Willi User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: Yoav Nir References: <48CF5D7D.7070701@strongswan.org> <2AE5C31F-D8AB-4135-86A1-E000ADD0FB5B@checkpoint.com> In-Reply-To: <2AE5C31F-D8AB-4135-86A1-E000ADD0FB5B@checkpoint.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 do see a problem with the text, in that it says that you re-create all > the child SAs before deleting the old IKE SA. IMO the better way is to > (1) create a new IKE SA, (2) delete the old IKE SA (and all associated > child SAs) and then (3) create new child SAs as needed. Yes, if we want to get usable and interoperable reauthentication without an extension, we have to define that procedure more in detail (as Tero has already done in a previous mail): - The make-before-break as discussed - Requesting the same INTERNAL_ADDRESS explicitly - IRAS must assign used INTERNAL_ADDRESS if explicitly requested to the same Identity - Probably other details As I already said, it IS possible to do that with the currently defined procedure. But in my experience, you'll need a lot of quirks to get things working smoothly, and I really see it skeptical to get good interoperability results between different vendors. > I liked option #4 very much, but I felt that it was too much of an > alteration to IKEv2 for the benefit it gives. Using the > make-before-break logic of RFC 4478 you can get the same results, with > slightly less efficiency, but with substantially less code complexity. In my opinion, doing the reauthentication the current way IS complex, involves multiple active IKE_SA, transferring state between them, invalidating the old, ... And there are unresolved issues, such as collisions, which will introduce an additional layer of complexity in the whole thing. At least for our implementation, it would be much simpler to do it inline. It is almost the same as rekeying, but with additional authentication with the primitives used in IKE_AUTH. Martin _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 17 07:43:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B35B28C2BE; Wed, 17 Sep 2008 07:43: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 12BF63A6C6F for ; Wed, 17 Sep 2008 07:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.431 X-Spam-Level: X-Spam-Status: No, score=-2.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 3cIDryVtRFZl for ; Wed, 17 Sep 2008 07:43:09 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 071FD3A6C67 for ; Wed, 17 Sep 2008 07:43:08 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so2013134fga.41 for ; Wed, 17 Sep 2008 07:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:cc :content-disposition:date:mime-version:content-type :content-transfer-encoding:message-id:from; bh=gFDVw7zawccKq1Frm5delUsIJ7eKqLPlbkC4AvV3Yik=; b=po/15yFA/m6QLU7o261s04t66NtP0km+gSAYbGXjsnbWmprMi6nyvlQAGW3QORWi0w k43W/E/9/XagY4uFWJB9nDy0x9z0fgsCSgJyGx2akgAEVMYMwHtfUv09ii/IbjnC5RND /Gowh/FVPeMut04FBIJn0PTAW5u4fv/ruAFoQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:cc:content-disposition:date:mime-version:content-type :content-transfer-encoding:message-id:from; b=skoflpuoN7JN6y8I55KKGm0G7DYfl09NDwuSQMDSE1eDX1DH/un/dS358LjHy00AjK qWpJ0DXX9gXxHDHf5ElgHEjIsrPKf7rU4F0t8jzww6tE9HcaZ/sVeef8dZguSQBpTfpy Ki0efOXIZJMObT/cxGQhGFcHpLMD9hSqjJcKo= Received: by 10.180.234.2 with SMTP id g2mr1120254bkh.54.1221662600404; Wed, 17 Sep 2008 07:43:20 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id d13sm18473375fka.3.2008.09.17.07.43.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Sep 2008 07:43:19 -0700 (PDT) To: ipsec@ietf.org Content-Disposition: inline Date: Wed, 17 Sep 2008 16:43:21 +0200 MIME-Version: 1.0 Message-Id: <200809171643.21965.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: cmadson@cisco.com, Pasi.Eronen@nokia.com Subject: [IPsec] INTERNAL_IP6_ADDRESS for link local address assignment X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Folks, draft-eronen-ipsec-ikev2-ipv6-config-04 introduces the INTERNAL_IP6_LINK configuration attribute (below) that provides the client with two parameters: - a Link Identifier used by the client and VPN gateway to identify an IPv6 virtual link associated with one or more IKE SAs. - an IPv6 Interface Identifier used by the client to configure its IPv6 link-local address. Since the Interface Identifier is only used to form an IPv6 link-local address (non-link-local addresses can be configured from the assigned prefixes and any interface identifier) it would be simpler that the client's IPv6 link-local address is assigned via the existing configuration attribute INTERNAL_IP6_ADDRESS, while the INTERNAL_IP6_LINK would contain the Link Identifier only. What do you think? --julien > 7.1. INTERNAL_IP6_LINK Configuration Attribute > > The INTERNAL_IP6_LINK configuration attribute is formatted as > follows: > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > !R| Attribute Type ! Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Link-Local | > | Interface ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ IKEv2 Link ID ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > o Reserved (1 bit) - See [IKEv2]. > > o Attribute Type (15 bits) - INTERNAL_IP6_LINK (TBD1). > > o Length (2 octets) - Length in octets of the Value field (Link- > Local Interface ID and IKEv2 Link ID); 8 or more. > > o Link-Local Interface ID (8 octets) - The Interface ID used for > link-local address (by the party that sent this attribute). > > o IKEv2 Link ID (variable length) - The link ID (may be empty > when the client does not yet know the link ID). _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 17 08:26:54 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09F5B3A6B7F; Wed, 17 Sep 2008 08:26: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 615CF3A6B7F for ; Wed, 17 Sep 2008 08:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.757 X-Spam-Level: X-Spam-Status: No, score=-5.757 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 5YrAZRHeVwTs for ; Wed, 17 Sep 2008 08:26:52 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 03B3B28C245 for ; Wed, 17 Sep 2008 08:26:47 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m8HFQvGH027399 for ; Wed, 17 Sep 2008 15:26:57 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 m8HFQuPb050970 for ; Wed, 17 Sep 2008 11:26:56 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m8HEupxB009468; Wed, 17 Sep 2008 10:56:51 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m8HEunRK009467; Wed, 17 Sep 2008 10:56:49 -0400 (EDT) X-Authentication-Warning: kebe.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Wed, 17 Sep 2008 10:56:49 -0400 From: Dan McDonald To: Julien Laganier Message-ID: <20080917145649.GB9360@kebe.east.sun.com> References: <200809171643.21965.julien.laganier.IETF@googlemail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <200809171643.21965.julien.laganier.IETF@googlemail.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ipsec@ietf.org, cmadson@cisco.com, Pasi.Eronen@nokia.com Subject: Re: [IPsec] INTERNAL_IP6_ADDRESS for link local address assignment X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 > Since the Interface Identifier is only used to form an IPv6 link-local > address (non-link-local addresses can be configured from the assigned > prefixes and any interface identifier) it would be simpler that the > client's IPv6 link-local address is assigned via the existing > configuration attribute INTERNAL_IP6_ADDRESS, Agreed. (And isn't this what I mentioned earlier on this list?) > while the INTERNAL_IP6_LINK would contain the Link Identifier only. > > What do you think? > > > 7.1. INTERNAL_IP6_LINK Configuration Attribute > > > > The INTERNAL_IP6_LINK configuration attribute is formatted as > > follows: > > > > 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > !R| Attribute Type ! Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NUKE> | Link-Local | NUKE> | Interface ID | NUKE> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ~ IKEv2 Link ID ~ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ So INTERNAL_IP6_LINK would remove the bits I have prefixed with NUKE> ? I have another question, but I suspect reading the draft will answer it. Thanks! Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 17 08:51:11 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63BD528C2C5; Wed, 17 Sep 2008 08:51:11 -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 BEB8128C2BA for ; Wed, 17 Sep 2008 08:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 bVJgHO65WLX6 for ; Wed, 17 Sep 2008 08:51:03 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id A2A7128C274 for ; Wed, 17 Sep 2008 08:51:02 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so2028420fga.41 for ; Wed, 17 Sep 2008 08:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=21keQQoiPm5iPPxAB5FDFocvxWeoF2ThsdAkhpa96qk=; b=uuH5SIneC+TE2kna6BrpauZdhfyg05TfY5YtO35resejMQ9RO1M0r4f+KT5vARJE7x djVEdEFAs+3bcF9CWVdur2Rai6k9u1Cm4sQXbrtES91lKxxuVvxtRbYmkl2fZHDp1J85 IzwtJOq/2IcQvX2G9pN8IzBb6fOzJmuEzlziE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=WA5t401QGe0HrJdoK0Cgsb1mlSnTx1wnLsp1E2sG0KD6OmAbjYs3Yr0uM7S/YlUg71 j9xrhAZfyw8j4WMf6idatjifns1QkPTSkEgVILDJ4i0e1f7kFd3JHLMPc7ii++NzbmSL hsieVRsbAdkLPQiLAy01LAHmyibxolvUPdewE= Received: by 10.180.248.10 with SMTP id v10mr1994414bkh.21.1221666673339; Wed, 17 Sep 2008 08:51:13 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id p9sm18539534fkb.5.2008.09.17.08.51.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Sep 2008 08:51:12 -0700 (PDT) To: Dan McDonald Date: Wed, 17 Sep 2008 17:51:14 +0200 User-Agent: KMail/1.9.9 References: <200809171643.21965.julien.laganier.IETF@googlemail.com> <20080917145649.GB9360@kebe.east.sun.com> In-Reply-To: <20080917145649.GB9360@kebe.east.sun.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200809171751.14694.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: ipsec@ietf.org, cmadson@cisco.com, Pasi.Eronen@nokia.com Subject: Re: [IPsec] INTERNAL_IP6_ADDRESS for link local address assignment X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Wednesday 17 September 2008, Dan McDonald wrote: > > Since the Interface Identifier is only used to form an IPv6 > > link-local address (non-link-local addresses can be configured from > > the assigned prefixes and any interface identifier) it would be > > simpler that the client's IPv6 link-local address is assigned via > > the existing configuration attribute INTERNAL_IP6_ADDRESS, > > Agreed. (And isn't this what I mentioned earlier on this list?) Yes, this is one of the things you mentioned. > > while the INTERNAL_IP6_LINK would contain the Link Identifier only. > > > > What do you think? > > > > > 7.1. INTERNAL_IP6_LINK Configuration Attribute > > > > > > The INTERNAL_IP6_LINK configuration attribute is formatted as > > > follows: > > > > > > 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 > > > 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > !R| Attribute Type ! Length | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > NUKE> | Link-Local | > NUKE> | Interface ID | > NUKE> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > ~ IKEv2 Link ID ~ > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > So INTERNAL_IP6_LINK would remove the bits I have prefixed with NUKE> > ? Right. And probably INTERNAL_IP6_LINK would become INTERNAL_IP6_LINKID. > I have another question, but I suspect reading the draft will answer > it. All right then. --julien _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 17 11:32:09 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6342D3A682D; Wed, 17 Sep 2008 11:32: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 E718E3A682D for ; Wed, 17 Sep 2008 11:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 TpjPsX62RmZc for ; Wed, 17 Sep 2008 11:32:07 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 020F13A67F1 for ; Wed, 17 Sep 2008 11:32:06 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6A0D9294002; Wed, 17 Sep 2008 21:32:19 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3C430294001; Wed, 17 Sep 2008 21:30:43 +0300 (IDT) Received: from [172.31.24.66] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8HIUfOx003131; Wed, 17 Sep 2008 21:30:42 +0300 (IDT) Message-Id: <5F9BE8DF-F041-4EBB-88D1-A9349B1DC3D3@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18640.58366.503035.79923@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 17 Sep 2008 19:30:40 +0100 References: <48CF5D7D.7070701@strongswan.org> <18639.30650.345788.976989@fireball.kivinen.iki.fi> <48CF9549.6060607@strongswan.org> <18639.41100.797684.125348@fireball.kivinen.iki.fi> <701D2D87-4D49-44F5-BA39-1B83B4C4413A@checkpoint.com> <18640.58366.503035.79923@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Sep 17, 2008, at 12:03 PM, Tero Kivinen wrote: > Yoav Nir writes: >> Agree, but I think you don't even need IP and port. Just same IDi and >> requesting same address. > > The IP and port check would protect against cases where you happen to > have 2 laptops or similars sharing same ID and same authentication > data. In normal case that should not happen, but that might happen > (for example when you have new and old laptop and are moving stuff > from old to new etc) and adding those checks is cheap and they should > not affect normal use. I.e. if the IP-address is different then second > connection is considered to be new connection instead of > reauthentication, and it gets new internal IP-address and everything > works. > > Do you see any problems by adding the IP address and port check? I haven't thought this through, but I think there could be weird interactions and race conditions between MOBIKE or simple mobility and the re-authentication. If the IDi is the same, AND the client specifically requests the IP address that belongs to the other IKE SA, then I don't see how the old/new laptop case is a problem. The new laptop will not know the IP address assigned to the old laptop, and will (SHOULD?) request an empty address. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 18 00:42:09 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C093A6AAD; Thu, 18 Sep 2008 00:42: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 304DD3A6977 for ; Thu, 18 Sep 2008 00:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.432, 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 VCboIS5iz48P for ; Thu, 18 Sep 2008 00:42:07 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 0B6603A6AAD for ; Thu, 18 Sep 2008 00:42:06 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m8I7fYun023082; Thu, 18 Sep 2008 10:41:46 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Sep 2008 10:41:23 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Sep 2008 10:41:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Sep 2008 10:41:13 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201A3FE6D@vaebe104.NOE.Nokia.com> In-Reply-To: <5F9BE8DF-F041-4EBB-88D1-A9349B1DC3D3@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Reauthentication extension for IKEv2 Thread-Index: AckY88A88lPQUjKUQOGVDg1LLZU10wAbJ2SA References: <48CF5D7D.7070701@strongswan.org><18639.30650.345788.976989@fireball.kivinen.iki.fi><48CF9549.6060607@strongswan.org><18639.41100.797684.125348@fireball.kivinen.iki.fi><701D2D87-4D49-44F5-BA39-1B83B4C4413A@checkpoint.com><18640.58366.503035.79923@fireball.kivinen.iki.fi> <5F9BE8DF-F041-4EBB-88D1-A9349B1DC3D3@checkpoint.com> From: To: , X-OriginalArrivalTime: 18 Sep 2008 07:41:13.0672 (UTC) FILETIME=[ED12BC80:01C91961] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir wrote: > I haven't thought this through, but I think there could be weird > interactions and race conditions between MOBIKE or simple mobility > and the re-authentication. If the IDi is the same, AND the client > specifically requests the IP address that belongs to the other IKE > SA, then I don't see how the old/new laptop case is a problem. The > new laptop will not know the IP address assigned to the old laptop, > and will (SHOULD?) request an empty address. We could add some advice on when the client should request a specific address, and when just ask for any address (empty request). I think the former case would occur basically if (a) the client is explicitly configured to do so, or (b) it has an existing IKE_SA with that address, or (c) if it had an IKE_SA with that address within some short amount of time, and still has active connections using that address. Similarly, it probably wouldn't hurt to give some advice for the gateway about reallocating addresses. If you reallocate an address to another VPN client too soon, this may even lead to security problems if e.g. firewall state between the gateway and the rest of the world hasn't timed out yet (for connections established by the VPN client who had this address earlier). Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 18 01:17:08 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 324E928C32B; Thu, 18 Sep 2008 01:17: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 8F3583A6DDA for ; Thu, 18 Sep 2008 01:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 ebAmHbHnCeqY for ; Thu, 18 Sep 2008 01:17:05 -0700 (PDT) Received: from tietoe03.tietoenator.com (datnt07.tieto.com [194.110.47.24]) by core3.amsl.com (Postfix) with ESMTP id 6C3FC3A6A72 for ; Thu, 18 Sep 2008 01:17:04 -0700 (PDT) X-AuditID: c26e2f18-000021d800001d68-27-48d20eb06394 Received: from camaro.eu.tieto.com ([192.176.143.43]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Sep 2008 11:17:52 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 Sep 2008 10:17:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Sep 2008 10:17:30 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Use of IKE to obtain address of home agent thread-index: AckZZv5ObZqHPt6UR0OJAJuohjJ70w== From: To: X-OriginalArrivalTime: 18 Sep 2008 08:17:30.0536 (UTC) FILETIME=[FE95D280:01C91966] X-Brightmail-Tracker: AAAAAA== Subject: [IPsec] Use of IKE to obtain address of home agent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 This mail-list is of course not responsible for all uses of the IKE protocol. But I wonder if the following case has been or is being discussed. 3GPP has in document TS 24.302 (can be retrieved from http://www.3gpp.org/ftp/Specs/html-info/24302.htm), section 7.2.2, specified a use of IKE, where IKE sets up a secure tunnel to a security gateway, denoted ePDG, and expects this security gateway to return both an address to the mobile node, which normally will be a care-of address, and the address(es) of the home agent. The said document thinks this possible by having two Configuration Payloads. IKEv2bis, and previous documents, only indicated one Configuration Payload to be present, and with the recent discussion in mind where the order of the payloads in an IKE packet should not matter, then having two Configuration Payloads is not a viable approach. It would be better to introduce two new configuration attributes, for example named INTERNAL_IP4_HA and INTERNAL_IP6_HA. Let me know if this has already been discussed. Christian _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 18 03:14:29 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A65BD28C3DA; Thu, 18 Sep 2008 03:14:29 -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 EAEF928C32A for ; Thu, 18 Sep 2008 03:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 MoJRIVUQDVS0 for ; Thu, 18 Sep 2008 03:14:27 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 1BBA83A6864 for ; Thu, 18 Sep 2008 03:14:11 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8IADVqP015732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2008 13:13:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8IADTqt021048; Thu, 18 Sep 2008 13:13:29 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18642.10697.341129.262891@fireball.kivinen.iki.fi> Date: Thu, 18 Sep 2008 13:13:29 +0300 From: Tero Kivinen To: Julien Laganier In-Reply-To: <200809171751.14694.julien.laganier.IETF@googlemail.com> References: <200809171643.21965.julien.laganier.IETF@googlemail.com> <20080917145649.GB9360@kebe.east.sun.com> <200809171751.14694.julien.laganier.IETF@googlemail.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 13 min X-Total-Time: 13 min Cc: ipsec@ietf.org, cmadson@cisco.com, Pasi.Eronen@nokia.com, Dan McDonald Subject: Re: [IPsec] INTERNAL_IP6_ADDRESS for link local address assignment X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Julien Laganier writes: > On Wednesday 17 September 2008, Dan McDonald wrote: > > > Since the Interface Identifier is only used to form an IPv6 > > > link-local address (non-link-local addresses can be configured from > > > the assigned prefixes and any interface identifier) it would be > > > simpler that the client's IPv6 link-local address is assigned via > > > the existing configuration attribute INTERNAL_IP6_ADDRESS, > > > > Agreed. (And isn't this what I mentioned earlier on this list?) > > Yes, this is one of the things you mentioned. As long as the prefix itself is negotiated using the INTERNAL_IP6_PREFIX this does not really matter. Either way is ok. Of course this means the implementations need to be smart enough to distinguish link local addresses from normal addresses. This would again mean that server can remove the link-local address from the client or change it, as when we are using the INTERNAL_IP6_ADDRESS we are using the rules bound to it, meaning the client only sends hints for the server and server replies back with the accepted values. I already proposed that we should use that same rule with INTERNAL_IP6_LINK attribute too, just to keep it sync with other attributes. > Right. And probably INTERNAL_IP6_LINK would become INTERNAL_IP6_LINKID. After this change the negotiation would come: CP(CFG_REQUEST) = { INTERNAL_IP6_LINKID(IKEv2 Link ID (or empty if first time)) INTERNAL_IP6_ADDRESS(Client's Link-Local Address) INTERNAL_IP6_DHCP() } TSi = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) --> CP(CFG_REPLY) = { INTERNAL_IP6_LINK(IKEv2 Link ID), INTERNAL_IP6_ADDRESS(Client's Link-Local Address) INTERNAL_IP6_PREFIX(Prefix1/64), [INTERNAL_IP6_PREFIX(Prefix2/64),...], INTERNAL_IP6_DHCP(Address) ] TSi = ((0, 0-65535, - ) (0, 0-65535, Prefix1::0 - Prefix1::FFFF:FFFF:FFFF:FFFF), [(0, 0-65535, Prefix2::0 - Prefix2::FFFF:FFFF:FFFF:FFFF), ...]) TSr = (0, 0-65535, 0:0:0:0:0:0:0:0 - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) One problem with this could be that stupid old server implementation would interpert that so that client only wanted the client's link local address as its IPv6 address, and it would not allocate any other address to the client. In most cases even old servers would not allow client to use link local addresses as their addresses, thus they would follow the rules in the RFC4306 and take the interface id from the link local address, and use that and replace the prefix with their own prefix they have reserved for the IPv6 addresses and it would return real routable address back on the INTERNAL_IP6_ADDRESS reply (and no prefixes or link information as it is old server which do not support this extension yet). I think the first case of really stupid servers which do not verify that the address client requested is usable is something that we do not really need to care, as that server would not be usable in IPv6 case at all. So I think this would be even bit better way to do this (especially as it has even better backwards compatibility with existing specification). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 18 03:21:26 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 358443A68D5; Thu, 18 Sep 2008 03:21: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 AC66B3A68D5 for ; Thu, 18 Sep 2008 03:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 uO+Me7dwvHPz for ; Thu, 18 Sep 2008 03:21:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 85C9D3A686E for ; Thu, 18 Sep 2008 03:21:13 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8IALLIK000661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2008 13:21:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8IALK01025226; Thu, 18 Sep 2008 13:21:20 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18642.11168.850237.607352@fireball.kivinen.iki.fi> Date: Thu, 18 Sep 2008 13:21:20 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <5F9BE8DF-F041-4EBB-88D1-A9349B1DC3D3@checkpoint.com> References: <48CF5D7D.7070701@strongswan.org> <18639.30650.345788.976989@fireball.kivinen.iki.fi> <48CF9549.6060607@strongswan.org> <18639.41100.797684.125348@fireball.kivinen.iki.fi> <701D2D87-4D49-44F5-BA39-1B83B4C4413A@checkpoint.com> <18640.58366.503035.79923@fireball.kivinen.iki.fi> <5F9BE8DF-F041-4EBB-88D1-A9349B1DC3D3@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > I haven't thought this through, but I think there could be weird > interactions and race conditions between MOBIKE or simple mobility and > the re-authentication. If the IDi is the same, AND the client > specifically requests the IP address that belongs to the other IKE SA, > then I don't see how the old/new laptop case is a problem. The new > laptop will not know the IP address assigned to the old laptop, and > will (SHOULD?) request an empty address. Quite often dhcp clients etc do store the address they got to the disk and try to get the same address every time. Same kind of thing would be logical and good in VPNs too, i.e. the VPN client tries to get same IP-address even across reboots and so on. This makes some things easier. The mobike might have cases where there is change in the addresses at the same time the reauthentication is requested and that causes the IP-addresses to change. On the other hand as I explained in my previous email, I think the case where two different nodes might have same address is much more serious than the case where the IP-address changes (provided this can only happen in very corner case race conditions). I agree that it might be enough to check ID and requested IP-address, but would myself most likely put the IP-address check too, just in case. On the other hand this is internal implementation detail level things, that we do not need to specify exactly, as this does not really affect interoperability, only how effectively implementation handles different corner cases (i.e. both will work). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 18 03:28:41 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41CD93A69F3; Thu, 18 Sep 2008 03:28: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 BF5473A69F3 for ; Thu, 18 Sep 2008 03:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 f8+NvHAuUuAB for ; Thu, 18 Sep 2008 03:28:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id DEBB93A6999 for ; Thu, 18 Sep 2008 03:28:15 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8IASQhq021714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2008 13:28:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8IASQNl006044; Thu, 18 Sep 2008 13:28:26 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18642.11594.53974.930622@fireball.kivinen.iki.fi> Date: Thu, 18 Sep 2008 13:28:26 +0300 From: Tero Kivinen To: In-Reply-To: <1696498986EFEC4D9153717DA325CB7201A3FE6D@vaebe104.NOE.Nokia.com> References: <48CF5D7D.7070701@strongswan.org> <18639.30650.345788.976989@fireball.kivinen.iki.fi> <48CF9549.6060607@strongswan.org> <18639.41100.797684.125348@fireball.kivinen.iki.fi> <701D2D87-4D49-44F5-BA39-1B83B4C4413A@checkpoint.com> <18640.58366.503035.79923@fireball.kivinen.iki.fi> <5F9BE8DF-F041-4EBB-88D1-A9349B1DC3D3@checkpoint.com> <1696498986EFEC4D9153717DA325CB7201A3FE6D@vaebe104.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: ipsec@ietf.org, ynir@checkpoint.com Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > We could add some advice on when the client should request a specific > address, and when just ask for any address (empty request). I have always assumed that client will give its previous address as hint to the server regardless what that address was and when it was last time used, provided it still remembers what this address is. Also I would hope server would try to give that same address to client if it is free, and the server should try to keep addresses free as long as possible, i.e. using LRU list of addresses. Of course this is again implementation details, that do not affect interoperability, but do affect how well the implementations work on certain situations. Different situations might have different requirements, for example in some cases the server might want to give new random address to each client every time, just to protect the identity of the client. Because of this I do not think we need to write any specific rules how to handle this cases, but we can add some text explaining the effects of different ways of doing things. > Similarly, it probably wouldn't hurt to give some advice for the > gateway about reallocating addresses. If you reallocate an address to > another VPN client too soon, this may even lead to security problems > if e.g. firewall state between the gateway and the rest of the world > hasn't timed out yet (for connections established by the VPN client > who had this address earlier). I think that kind of text should be part of the security considerations section, i.e. explain that case and say that servers SHOULd not reallocate same address to different entities too quickly. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 18 03:43:28 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D10C28C41E; Thu, 18 Sep 2008 03:43:28 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8400628C41E for ; Thu, 18 Sep 2008 03:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 CGTplJeQedV8 for ; Thu, 18 Sep 2008 03:43:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id A18CC28C403 for ; Thu, 18 Sep 2008 03:43:14 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8IAhQ3c001290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2008 13:43:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8IAhQDf028232; Thu, 18 Sep 2008 13:43:26 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18642.12494.564286.298618@fireball.kivinen.iki.fi> Date: Thu, 18 Sep 2008 13:43:26 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 9 min X-Total-Time: 14 min Cc: ipsec@ietf.org Subject: [IPsec] Use of IKE to obtain address of home agent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Christian.Kaas-Petersen@tietoenator.com writes: > 3GPP has in document TS 24.302 (can be retrieved from > http://www.3gpp.org/ftp/Specs/html-info/24302.htm), section 7.2.2, > specified a use of IKE, where IKE sets up a secure tunnel to > a security gateway, denoted ePDG, and expects this security gateway > to return both an address to the mobile node, which normally > will be a care-of address, and the address(es) of the home agent. > The said document thinks this possible by having two Configuration > Payloads. IKEv2bis, and previous documents, only indicated one > Configuration Payload to be present, and with the recent discussion > in mind where the order of the payloads in an IKE packet should > not matter, then having two Configuration Payloads is not a viable > approach. It would be better to introduce two new configuration > attributes, for example named INTERNAL_IP4_HA and INTERNAL_IP6_HA. Yes, it would be better to have 2 new configuration options. The section 7.2.2. does not actually specify which configuration attribute type is used to negotiate Home Agent addresses. Including more than one configuration payloads in the exchange, would be bad idea, as the configuration payloads do not hve any kind of transaction id or similar, meaning there is no way to know which CFG_REPLY matches which CFG_REQUEST if there is multiple configuration payloads (of same CFG TYPE) in same exchange. Another option is to use the INTERNAL_IP{4,6}_DHCP attribute in IKEv2 and then get the home agent address from the DHCP server. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 18 04:13:59 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2216C3A6873; Thu, 18 Sep 2008 04:13: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 B69153A6873 for ; Thu, 18 Sep 2008 04:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.442, 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 Dlv0A83KzZqJ for ; Thu, 18 Sep 2008 04:13:57 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 9A0083A67A6 for ; Thu, 18 Sep 2008 04:13:56 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m8IBDGQ7024738; Thu, 18 Sep 2008 14:13:44 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Sep 2008 14:13:27 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Sep 2008 14:13:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 18 Sep 2008 14:13:26 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201A86C5C@vaebe104.NOE.Nokia.com> In-Reply-To: <18642.11594.53974.930622@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Reauthentication extension for IKEv2 Thread-Index: AckZeV2lAMvjN8yNTI++15Gbim1kRwABO0aQ References: <48CF5D7D.7070701@strongswan.org><18639.30650.345788.976989@fireball.kivinen.iki.fi><48CF9549.6060607@strongswan.org><18639.41100.797684.125348@fireball.kivinen.iki.fi><701D2D87-4D49-44F5-BA39-1B83B4C4413A@checkpoint.com><18640.58366.503035.79923@fireball.kivinen.iki.fi><5F9BE8DF-F041-4EBB-88D1-A9349B1DC3D3@checkpoint.com><1696498986EFEC4D9153717DA325CB7201A3FE6D@vaebe104.NOE.Nokia.com> <18642.11594.53974.930622@fireball.kivinen.iki.fi> From: To: X-OriginalArrivalTime: 18 Sep 2008 11:13:27.0282 (UTC) FILETIME=[92E56D20:01C9197F] X-Nokia-AV: Clean Cc: ipsec@ietf.org, ynir@checkpoint.com Subject: Re: [IPsec] Reauthentication extension for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Tero Kivinen wrote: > > We could add some advice on when the client should request a > > specific address, and when just ask for any address (empty > > request). > > I have always assumed that client will give its previous address as > hint to the server regardless what that address was and when it was > last time used, provided it still remembers what this address is. Also > I would hope server would try to give that same address to client if > it is free, and the server should try to keep addresses free as long > as possible, i.e. using LRU list of addresses. > > Of course this is again implementation details, that do not affect > interoperability, but do affect how well the implementations work on > certain situations. Different situations might have different > requirements, for example in some cases the server might want to give > new random address to each client every time, just to protect the > identity of the client. > > Because of this I do not think we need to write any specific rules how > to handle this cases, but we can add some text explaining the effects > of different ways of doing things. As was pointed out earlier in this thread, this *can* affect whether reauthentication works correctly or not: some combinations of client and gateway behavior lead to problems. When writing RFC 4718, I had thought that it's OK for the server to give the requested address if it's free, or if it's given to the same authenticated initiator identity (often IDi, except when EAP is used; see RFC 4718 Section 3.5). But depending on the client behavior, this could lead to problems if the same initiator identity is used on multiple client hosts... checking the outer IP/port (from IKE packet) would probably solve that, if it doesn't interact badly with MOBIKE. Or it could be solved by saying the client shouldn't request a specific address if it's nor currently using it. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 18 04:18:19 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76AF3A6884; Thu, 18 Sep 2008 04:18:18 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83A9A3A6884 for ; Thu, 18 Sep 2008 04:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 QDXz+ZE+wWZO for ; Thu, 18 Sep 2008 04:18:17 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by core3.amsl.com (Postfix) with ESMTP id 15A283A6864 for ; Thu, 18 Sep 2008 04:18:16 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so3326528fkq.5 for ; Thu, 18 Sep 2008 04:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:to:subject:date:user-agent:cc :references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:from; bh=QT6atgV3Pg5CKZ3zuqXMBK6Lps5NKwVs9IeCfQ3NqLE=; b=VJmTjbtU1uqfF0zUlKSZnKbE8viwrq2CCbavCNmv4m+T0q5VZUaOnpR91FhlYR49tZ DCHOsyGPwm90joHgdVJEXHVyEBClQnAUKs02MyJp1A2rir+aPwoyfSyIsFp0lhd+1CNh YCi8cIxRE7Ev0yIgCq4cPC1KlT2zp+sHYAFL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=to:subject:date:user-agent:cc:references:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :message-id:from; b=uP0CUo/Khl5EWsE8OywjJMEf1687qtGfo+9CXG+wqO8sCc4msLHsStRkBq59OBcYDu zI+p2uYnRNfw59bXZipQzAcL85z4R9ikR/vZddwJ+oxJD3TpjCUyB5Ig5Mn+jyJxeK7a VgaBXT86WEOgsv80XOnEzbNvmgSdx6xhb0r70= Received: by 10.180.230.6 with SMTP id c6mr2635705bkh.27.1221736660102; Thu, 18 Sep 2008 04:17:40 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 28sm19894318fkx.1.2008.09.18.04.17.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Sep 2008 04:17:39 -0700 (PDT) To: ipsec@ietf.org Date: Thu, 18 Sep 2008 13:17:41 +0200 User-Agent: KMail/1.9.9 References: <18642.12494.564286.298618@fireball.kivinen.iki.fi> In-Reply-To: <18642.12494.564286.298618@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200809181317.42653.julien.laganier.IETF@googlemail.com> From: Julien Laganier Cc: Christian.Kaas-Petersen@tietoenator.com, Tero Kivinen Subject: Re: [IPsec] Use of IKE to obtain address of home agent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Christian and Tero, Quick follow-up on this topic: On Thursday 18 September 2008, Tero Kivinen wrote: > Christian.Kaas-Petersen@tietoenator.com writes: > > 3GPP has in document TS 24.302 (can be retrieved from > > http://www.3gpp.org/ftp/Specs/html-info/24302.htm), section 7.2.2, > > specified a use of IKE, where IKE sets up a secure tunnel to > > a security gateway, denoted ePDG, and expects this security gateway > > to return both an address to the mobile node, which normally > > will be a care-of address, and the address(es) of the home agent. > > The said document thinks this possible by having two Configuration > > Payloads. IKEv2bis, and previous documents, only indicated one > > Configuration Payload to be present, and with the recent discussion > > in mind where the order of the payloads in an IKE packet should > > not matter, then having two Configuration Payloads is not a viable > > approach. It would be better to introduce two new configuration > > attributes, for example named INTERNAL_IP4_HA and INTERNAL_IP6_HA. > > Yes, it would be better to have 2 new configuration options. The > section 7.2.2. does not actually specify which configuration > attribute type is used to negotiate Home Agent addresses. > > Including more than one configuration payloads in the exchange, would > be bad idea, as the configuration payloads do not hve any kind of > transaction id or similar, meaning there is no way to know which > CFG_REPLY matches which CFG_REQUEST if there is multiple > configuration payloads (of same CFG TYPE) in same exchange. I have a different reading of 3GPP TS 24.302; I think there's a little mistake in the text and what it want to say is that "the UE may also request the address(es) of a Home Agent for DSMIPv6 related signaling, by including a corresponding _attribute_ in the CFG_REQUEST configuration payload." That would be in-line with the Editor's note that follows which state "it is FFS which type of attribute (private or assigned by IANA) is used in the configuration payload. I see absolutely no reason to use two CFG_REQUEST be needed... Thus TS 24.302 has to be fixed. > Another option is to use the INTERNAL_IP{4,6}_DHCP attribute in IKEv2 > and then get the home agent address from the DHCP server. The alternative of getting the HA information via DHCP is already covered as part of 3GPP TS 24.303 "Mobility Management based on Dual-Stack Mobile IPv6", amongst other alternatives (DNS, and GTP Protocol Configuration Options.) --julien _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 18 23:34:02 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 655B33A67A1; Thu, 18 Sep 2008 23:34:02 -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 0636528C0FA for ; Thu, 18 Sep 2008 23:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 w6eINd8KMDIY for ; Thu, 18 Sep 2008 23:34:00 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id B71A93A67EA for ; Thu, 18 Sep 2008 23:33:59 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 09EF7294003; Fri, 19 Sep 2008 09:34:13 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0DD78294001; Fri, 19 Sep 2008 09:31:28 +0300 (IDT) Received: from [172.31.24.66] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8J6VQOx016558; Fri, 19 Sep 2008 09:31:27 +0300 (IDT) Message-Id: From: Yoav Nir To: Stephen Bevan In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 19 Sep 2008 07:31:26 +0100 References: X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Stephen. On Sep 19, 2008, at 4:52 AM, Stephen Bevan wrote: > The drafts for QCD and SIR both assume that the crash, reboot and > subsequent INVALID_SPI will be generated less time than DPD can detect > failure. Both point at RFC 4306 section 2 suggests DPD should run for > several minutes to indicate the results that can be expected from > using DPD. I did not see either mention what typical/expected > crash/reboot times are. Boot times can be very short. See below. DPD is not always appropriate, because of issues at the client side. DPD requires sending occasional keep-alive packets, which consumes bandwidth and battery on small devices, and in other cases keeps a PPP connection (PPTP, L2TP-over-DSL) alive, which costs the user money and reduces battery life. > The commodity PC hardware I'm typing this message on will spend at > about 30 seconds in the BIOS before it even starts booting the kernel > and it takes a minute or more before the IKE daemon is up and ready > to send out an INVALID_SPI. Thus with either protocol the best I > could hope for on this hardware would be 1 minute of traffic loss. > Two ways of bringing down that time are :- > > 1. Get hardware the boots an order of magnitude faster. > > 2. Use an IKE daemon that allows me to configure the DPD settings to > whatever I deem correct for my toplogy. > > I'd dearly love 1 but where do I get it and how much more does it > cost? Thus I'm left looking at 2 which is a quality of implementation > issue that requires no protocol changes. VPN gateways that run on specialty hardware rather than commodity PCs or servers boot up and are ready for IKE connections in less than 20 seconds. They are very common, probably more so than "software-based" VPN gateways. But that doesn't matter. As a vendor, I can tell you that nearly all our customers use some kind of hot standby gateway. Unless all IKE and IPsec SAs between the active and stand-by member are synchronized, the stand-by will take over within a second, using the same identifiers, but with no state. This is equivalent to a single gateway rebooting instantly. > There may be other scenarios where the protocols do better than DPD > with configurable timeouts in which case I suggest the introductory > sections of the drafts be updated to make the case for those scenarios > _much_ more strongly in order to clearly indicate why DPD is not > sufficient and a new protocol is required. Thank you. In the next update, I will emphasize the hot stand-by case. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 19 06:06:01 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A257D28C10E; Fri, 19 Sep 2008 06:06: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 CAD5B3A6A31 for ; Fri, 19 Sep 2008 06:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 OOIVN56-B5kV for ; Fri, 19 Sep 2008 06:05:59 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id C4C0B3A6862 for ; Fri, 19 Sep 2008 06:05:47 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8JD5orO018245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Sep 2008 16:05:50 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8JD5mDd025445; Fri, 19 Sep 2008 16:05:48 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18643.41900.851013.866168@fireball.kivinen.iki.fi> Date: Fri, 19 Sep 2008 16:05:48 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 16 min X-Total-Time: 15 min Cc: ipsec@ietf.org, Stephen Bevan Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > DPD is not always appropriate, because of issues at the client side. > DPD requires sending occasional keep-alive packets, which consumes > bandwidth and battery on small devices, and in other cases keeps a PPP > connection (PPTP, L2TP-over-DSL) alive, which costs the user money and > reduces battery life. As I explained in my previous email DPD can also be done in more efficient way, i.e. by detecting the one way communication. Our implementation does it so that when it detecs it has been sending out packets for more than 10 seconds without receiving any single packet back, it will start DPD process. If the DPD gets reply back immediately (as it normally does as other end is still up, but traffic is one way for some other reason than reboot) this faster one-way dpd trigger is disabled until traffic changes back to two-way. In normal case this does not require any extra bandwidth or battery power, as normally traffic is two-way (i.e. TCP acks etc coming back). In case the traffic changes to one-way outgoing traffic, without any incoming packets then we do one extra DPD very quickly after traffic changes to one-way, and after that we do not do any extra DPDs. Keeping PPP connections etc alive does not matter as by definition there is traffic going out all the time (one one-way packet is not yet enough to trigger the one-way traffic trigger). > VPN gateways that run on specialty hardware rather than commodity PCs > or servers boot up and are ready for IKE connections in less than 20 > seconds. Quite a many of the ADLS modems require more than 20 seconds to just negotiate the ADLS link up (I witnessed this for one modem when I was trying to "guess" correct parameters for it to replace my broken ADLS modem, and I needed to reboot it several dozen times, and even when the actual boot time of the device was around 10-20 seconds, the ADLS link took at least same amount of time to establish). > They are very common, probably more so than "software-based" > VPN gateways. But that doesn't matter. As a vendor, I can tell you > that nearly all our customers use some kind of hot standby gateway. > Unless all IKE and IPsec SAs between the active and stand-by member > are synchronized, the stand-by will take over within a second, using > the same identifiers, but with no state. This is equivalent to a > single gateway rebooting instantly. It is much better to keep the IKE SAs synced between the gateways, thus there is no need for secure crash recovery. The hot standby can just send IKE SA delete notifications for old IPsec SAs the other end had and create new IPsec SAs, or it can even have synced state for the IPsec SAs too (but that is much more expensive because of the replay protection counters). I do not think this hot standby case is that relevant for the secure crash recovery, as those methods used there are much better anyways. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 19 10:14:45 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9C23A69C4; Fri, 19 Sep 2008 10:14:45 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD7953A69C4 for ; Fri, 19 Sep 2008 10:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 XEsQJBkOlonq for ; Fri, 19 Sep 2008 10:14:43 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 17D513A68A3 for ; Fri, 19 Sep 2008 10:14:42 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 19A3E294004; Fri, 19 Sep 2008 19:56:11 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 76568294001; Fri, 19 Sep 2008 19:53:55 +0300 (IDT) Received: from [172.31.24.131] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8JGrsOx028030; Fri, 19 Sep 2008 19:53:54 +0300 (IDT) Message-Id: <7E894C6E-2F44-4C52-B893-B066B4DE3FC8@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18643.41900.851013.866168@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 19 Sep 2008 17:53:36 +0100 References: <18643.41900.851013.866168@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org, Stephen Bevan Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Sep 19, 2008, at 2:05 PM, Tero Kivinen wrote: > Yoav Nir writes: >> DPD is not always appropriate, because of issues at the client side. >> DPD requires sending occasional keep-alive packets, which consumes >> bandwidth and battery on small devices, and in other cases keeps a >> PPP >> connection (PPTP, L2TP-over-DSL) alive, which costs the user money >> and >> reduces battery life. > > As I explained in my previous email DPD can also be done in more > efficient way, i.e. by detecting the one way communication. > > Our implementation does it so that when it detecs it has been sending > out packets for more than 10 seconds without receiving any single > packet back, it will start DPD process. If the DPD gets reply back > immediately (as it normally does as other end is still up, but traffic > is one way for some other reason than reboot) this faster one-way dpd > trigger is disabled until traffic changes back to two-way. That's a good way, but then if your email client polls the IMAP server every 5 minutes, you'll only get a burst of activity every 5 minutes. Even a gateway running on a commodity PC has time to reboot in 5 minutes, and DPD will take more time than necessary (30 seconds in your case IIRC) > In normal case this does not require any extra bandwidth or battery > power, as normally traffic is two-way (i.e. TCP acks etc coming back). > > In case the traffic changes to one-way outgoing traffic, without any > incoming packets then we do one extra DPD very quickly after traffic > changes to one-way, and after that we do not do any extra DPDs. > > Keeping PPP connections etc alive does not matter as by definition > there is traffic going out all the time (one one-way packet is not yet > enough to trigger the one-way traffic trigger). > >> VPN gateways that run on specialty hardware rather than commodity PCs >> or servers boot up and are ready for IKE connections in less than 20 >> seconds. > > Quite a many of the ADLS modems require more than 20 seconds to just > negotiate the ADLS link up (I witnessed this for one modem when I was > trying to "guess" correct parameters for it to replace my broken ADLS > modem, and I needed to reboot it several dozen times, and even when > the actual boot time of the device was around 10-20 seconds, the ADLS > link took at least same amount of time to establish). > >> They are very common, probably more so than "software-based" >> VPN gateways. But that doesn't matter. As a vendor, I can tell you >> that nearly all our customers use some kind of hot standby gateway. >> Unless all IKE and IPsec SAs between the active and stand-by member >> are synchronized, the stand-by will take over within a second, using >> the same identifiers, but with no state. This is equivalent to a >> single gateway rebooting instantly. > > It is much better to keep the IKE SAs synced between the gateways, > thus there is no need for secure crash recovery. The hot standby can > just send IKE SA delete notifications for old IPsec SAs the other end > had and create new IPsec SAs, or it can even have synced state for the > IPsec SAs too (but that is much more expensive because of the replay > protection counters). > > I do not think this hot standby case is that relevant for the secure > crash recovery, as those methods used there are much better anyways. We actually sync IKE SAs between gateways, although this is getting more difficult, because IKEv2 requires the message counters to be synched. My co-authors tell me that very often, their gateways are deployed with no back-channel sync. We are hearing more people who want a physical separation between the gateways (like putting them in different parts of town) and in that case synching becomes much more difficult. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 19 11:56:28 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F43D3A6B92; Fri, 19 Sep 2008 11:56:28 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A7313A6B97; Fri, 19 Sep 2008 11:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 toMbFySRR8tu; Fri, 19 Sep 2008 11:56:25 -0700 (PDT) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id 760B83A6A0C; Fri, 19 Sep 2008 11:56:25 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8JIuZ9Y005580; Fri, 19 Sep 2008 14:56:35 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8JIuTb4169494; Fri, 19 Sep 2008 12:56:31 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8JIuSdH000467; Fri, 19 Sep 2008 12:56:28 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8JIuS1I000457; Fri, 19 Sep 2008 12:56:28 -0600 In-Reply-To: <18643.41900.851013.866168@fireball.kivinen.iki.fi> References: <18643.41900.851013.866168@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 1CE37100:A6DEF8DA-852574C9:0067F11E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen Message-ID: Date: Fri, 19 Sep 2008 14:56:27 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V85_M2_08202008HFIGS1|August 20, 2008) at 09/19/2008 12:56:27, Serialize complete at 09/19/2008 12:56:27 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Stephen Bevan , Yoav Nir Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1803197061==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1803197061== Content-Type: multipart/alternative; boundary="=_alternative 0068086E852574C9_=" This is a multipart message in MIME format. --=_alternative 0068086E852574C9_= Content-Type: text/plain; charset="US-ASCII" Hi Tero, you comment: >> "Our implementation does it so that when it detecs it has been sending out packets . . . without receiving any single packet back, it will start DPD process." This made me go back to RFC 4306 to make sure I was understanding it right. It seems there is a little bit of a lack of clarity in the RFC. This sentence suggests the approach you have taken; i.e., to do a liveness test only when there is unreciprocated outbound traffic on the SAs: >> "If there has only been outgoing traffic on all of the SAs associated with an IKE_SA, it is essential to confirm liveness of the other endpoint to avoid black holes." But the sentences immediately following this in the RFC suggest that a liveness test should be done even when there is dead air, i.e., without regard to whether we have been sending traffic. >> "If no cryptographically protected messages have been received on an IKE_SA or any of its CHILD_SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. Receipt of a fresh cryptographically protected message on an IKE_SA or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its CHILD_SAs." Is it the intent of the RFC to do liveness checks only when there is unreciprocated outbound traffic? Should the RFC allow or forbid liveness checks more broadly in the "dead air" case where there is no traffic flowing in either direction? There may be some value in proactively discovering the peer's deadness in the dead-air case, but Yoav's concerns about overutilized connections also have merit. If the RFC takes an agnostic approach to the dead-air case, we may still want to recommend that if an implementation allows for dead-air liveness checks, it should be configurable on a per-PAD-entry basis. Or perhaps the RFC could recommend a more conservative approach to the dead-air case, such as backing off the interval between dead-air liveness checks with each successful iteration. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Yoav Nir Cc: ipsec@ietf.org, Stephen Bevan Date: 09/19/2008 09:07 AM Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 Yoav Nir writes: > DPD is not always appropriate, because of issues at the client side. > DPD requires sending occasional keep-alive packets, which consumes > bandwidth and battery on small devices, and in other cases keeps a PPP > connection (PPTP, L2TP-over-DSL) alive, which costs the user money and > reduces battery life. As I explained in my previous email DPD can also be done in more efficient way, i.e. by detecting the one way communication. Our implementation does it so that when it detecs it has been sending out packets for more than 10 seconds without receiving any single packet back, it will start DPD process. If the DPD gets reply back immediately (as it normally does as other end is still up, but traffic is one way for some other reason than reboot) this faster one-way dpd trigger is disabled until traffic changes back to two-way. In normal case this does not require any extra bandwidth or battery power, as normally traffic is two-way (i.e. TCP acks etc coming back). In case the traffic changes to one-way outgoing traffic, without any incoming packets then we do one extra DPD very quickly after traffic changes to one-way, and after that we do not do any extra DPDs. Keeping PPP connections etc alive does not matter as by definition there is traffic going out all the time (one one-way packet is not yet enough to trigger the one-way traffic trigger). > VPN gateways that run on specialty hardware rather than commodity PCs > or servers boot up and are ready for IKE connections in less than 20 > seconds. Quite a many of the ADLS modems require more than 20 seconds to just negotiate the ADLS link up (I witnessed this for one modem when I was trying to "guess" correct parameters for it to replace my broken ADLS modem, and I needed to reboot it several dozen times, and even when the actual boot time of the device was around 10-20 seconds, the ADLS link took at least same amount of time to establish). > They are very common, probably more so than "software-based" > VPN gateways. But that doesn't matter. As a vendor, I can tell you > that nearly all our customers use some kind of hot standby gateway. > Unless all IKE and IPsec SAs between the active and stand-by member > are synchronized, the stand-by will take over within a second, using > the same identifiers, but with no state. This is equivalent to a > single gateway rebooting instantly. It is much better to keep the IKE SAs synced between the gateways, thus there is no need for secure crash recovery. The hot standby can just send IKE SA delete notifications for old IPsec SAs the other end had and create new IPsec SAs, or it can even have synced state for the IPsec SAs too (but that is much more expensive because of the replay protection counters). I do not think this hot standby case is that relevant for the secure crash recovery, as those methods used there are much better anyways. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0068086E852574C9_= Content-Type: text/html; charset="US-ASCII"
Hi Tero, you comment:

>>        "Our implementation does it so that when it detecs it has been sending out packets . . . without receiving any single packet back, it will start DPD process."

This made me go back to RFC 4306 to make sure I was understanding it right.  It seems there is a little bit of a lack of clarity in the RFC.  This sentence suggests the approach you have taken; i.e., to do a liveness test only when there is unreciprocated outbound traffic on the SAs:

>>        "If there has only been outgoing traffic on all of the SAs associated with an IKE_SA, it is essential to confirm liveness of the other endpoint to avoid black holes."

But the sentences immediately following this in the RFC suggest that a liveness test should be done even when there is dead air, i.e., without regard to whether we have been sending traffic.

>>        "If no cryptographically protected messages have been received on an IKE_SA or any of its CHILD_SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. Receipt of a fresh cryptographically protected message on an IKE_SA or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its CHILD_SAs."

Is it the intent of the RFC to do liveness checks only when there is unreciprocated outbound traffic?  Should the RFC allow or forbid liveness checks more broadly in the "dead air" case where there is no traffic flowing in either direction?  There may be some value in proactively discovering the peer's deadness in the dead-air case, but Yoav's concerns about overutilized connections also have merit.  If the RFC takes an agnostic approach to the dead-air case, we may still want to recommend that if an implementation allows for dead-air liveness checks, it should be configurable on a per-PAD-entry basis.  Or perhaps the RFC could recommend a more conservative approach to the dead-air case, such as backing off the interval between dead-air liveness checks with each successful iteration.


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


From: Tero Kivinen <kivinen@iki.fi>
To: Yoav Nir <ynir@checkpoint.com>
Cc: ipsec@ietf.org, Stephen Bevan <stephen.bevan@gmail.com>
Date: 09/19/2008 09:07 AM
Subject: Re: [IPsec] Secure Crash Discovery for IKEv2




Yoav Nir writes:
> DPD is not always appropriate, because of issues at the client side.  
> DPD requires sending occasional keep-alive packets, which consumes  
> bandwidth and battery on small devices, and in other cases keeps a PPP  
> connection (PPTP, L2TP-over-DSL) alive, which costs the user money and  
> reduces battery life.

As I explained in my previous email DPD can also be done in more
efficient way, i.e. by detecting the one way communication.

Our implementation does it so that when it detecs it has been sending
out packets for more than 10 seconds without receiving any single
packet back, it will start DPD process. If the DPD gets reply back
immediately (as it normally does as other end is still up, but traffic
is one way for some other reason than reboot) this faster one-way dpd
trigger is disabled until traffic changes back to two-way.

In normal case this does not require any extra bandwidth or battery
power, as normally traffic is two-way (i.e. TCP acks etc coming back).

In case the traffic changes to one-way outgoing traffic, without any
incoming packets then we do one extra DPD very quickly after traffic
changes to one-way, and after that we do not do any extra DPDs.

Keeping PPP connections etc alive does not matter as by definition
there is traffic going out all the time (one one-way packet is not yet
enough to trigger the one-way traffic trigger).

> VPN gateways that run on specialty hardware rather than commodity PCs  
> or servers boot up and are ready for IKE connections in less than 20  
> seconds.

Quite a many of the ADLS modems require more than 20 seconds to just
negotiate the ADLS link up (I witnessed this for one modem when I was
trying to "guess" correct parameters for it to replace my broken ADLS
modem, and I needed to reboot it several dozen times, and even when
the actual boot time of the device was around 10-20 seconds, the ADLS
link took at least same amount of time to establish).

> They are very common, probably more so than "software-based"  
> VPN gateways. But that doesn't matter. As a vendor, I can tell you  
> that nearly all our customers use some kind of hot standby gateway.  
> Unless all IKE and IPsec SAs between the active and stand-by member  
> are synchronized, the stand-by will take over within a second, using  
> the same identifiers, but with no state. This is equivalent to a  
> single gateway rebooting instantly.

It is much better to keep the IKE SAs synced between the gateways,
thus there is no need for secure crash recovery. The hot standby can
just send IKE SA delete notifications for old IPsec SAs the other end
had and create new IPsec SAs, or it can even have synced state for the
IPsec SAs too (but that is much more expensive because of the replay
protection counters).

I do not think this hot standby case is that relevant for the secure
crash recovery, as those methods used there are much better anyways.
--
kivinen@safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 0068086E852574C9_=-- --===============1803197061== 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 --===============1803197061==-- From ipsec-bounces@ietf.org Fri Sep 19 13:06:46 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B82F3A6868; Fri, 19 Sep 2008 13:06: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 1F3283A6868 for ; Fri, 19 Sep 2008 13:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] 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 ZIMokVjOG6E4 for ; Fri, 19 Sep 2008 13:06:43 -0700 (PDT) Received: from emx1.cybertrust.com (emx1.cybertrust.com [64.209.238.44]) by core3.amsl.com (Postfix) with ESMTP id 657CD3A67D8 for ; Fri, 19 Sep 2008 13:06:43 -0700 (PDT) Received: by emx1.cybertrust.com (ESMTP, from userid 414) id 6CE391CA; Fri, 19 Sep 2008 16:06:57 -0400 (EDT) From: "Darren Hartman" To: References: Date: Fri, 19 Sep 2008 16:06:53 -0400 Organization: ICSA Labs Message-ID: <000201c91a93$42931560$7a0211ac@mcilink.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ackag0EE3K70vhSyQvKmhP0TW8PQlAAD+2gw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: Subject: [IPsec] IKEv2 Interoperability Workshop X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dhartman@icsalabs.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 ICSA Labs has been working towards finalizing plans for the facility and timeframe to hold the next IKEv2 interop workshop. At this time, a facility is available for the first week of November '08, in Sunnyvale, California. Currently, we are trying to estimate the number of attendees. If you plan to participate, please contact us by next Wed (Sep. 24) with the number of people expected to attend and whether you will be testing more than one implementation, i.e. the number of test stations you will need. Thanks, Darren Hartman ICSA Labs _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 20 04:54:14 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8015D3A6A19; Sat, 20 Sep 2008 04: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 BF7993A6A19 for ; Sat, 20 Sep 2008 04:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfCvZ6LzlrUq for ; Sat, 20 Sep 2008 04:54:12 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 7D64B3A6A15 for ; Sat, 20 Sep 2008 04:54:12 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so308847eyd.31 for ; Sat, 20 Sep 2008 04:54:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=qjrRzU73yzqxOJez1czY+6OgZv6sGai2WLvKiDltjyA=; b=vQuBxl34uroBQKJPIPB8FEqYARPVEaIU+MyO+7qILdq4k2seD9tEGOOaTekgFXpUU6 vKpF66hgw+AYUIa5PqQAgBRwgbtRoxprz+ypkYyJMD8l/8gAxvmAEsCnqao6Ep7vXDSw u5aiDGoYIEwFGJ+jLHFpeQylwOjBcpp4oalyM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=DNFefNJKeISAA70v4o7lGgKSgsZ2yp6IqekpZOhG+bElMaiRc9K+ZPNoO/AHLRwQBB 9DLuzDsIedivlXqRNto0+pvj+4h/uix0eid8TbGr1V8lyiF09Wr/2dyYKxb9qJF9H6vg b2jwCXVstTOPqoTW+k/lLW0zMOPMIMsJx+72U= Received: by 10.210.71.12 with SMTP id t12mr1626019eba.146.1221911666834; Sat, 20 Sep 2008 04:54:26 -0700 (PDT) Received: by 10.210.115.8 with HTTP; Sat, 20 Sep 2008 04:54:26 -0700 (PDT) Message-ID: <1d38a3350809200454q2dab82d8i2da7df107ee6149a@mail.gmail.com> Date: Sat, 20 Sep 2008 19:54:26 +0800 From: "Hui Deng" To: Christian.Kaas-Petersen@tietoenator.com In-Reply-To: MIME-Version: 1.0 References: Cc: ipsec@ietf.org Subject: Re: [IPsec] Use of IKE to obtain address of home agent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1522054305==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1522054305== Content-Type: multipart/alternative; boundary="----=_Part_50618_23073197.1221911666808" ------=_Part_50618_23073197.1221911666808 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Please allow me cut in, If we plan to specifiy INTERNAL_IP4_HA and INTERNAL_IP6_HA, do we have to specifiy INTERNAL_IP4_LMA and INTERNAL_IP6_MAG as well for PMIP6? thanks -Hui 2008/9/18 > This mail-list is of course not responsible for all uses of the IKE > protocol. But I wonder if the following case has been or is being > discussed. > > 3GPP has in document TS 24.302 (can be retrieved from > http://www.3gpp.org/ftp/Specs/html-info/24302.htm), section 7.2.2, > specified a use of IKE, where IKE sets up a secure tunnel to > a security gateway, denoted ePDG, and expects this security gateway > to return both an address to the mobile node, which normally > will be a care-of address, and the address(es) of the home agent. > The said document thinks this possible by having two Configuration > Payloads. IKEv2bis, and previous documents, only indicated one > Configuration Payload to be present, and with the recent discussion > in mind where the order of the payloads in an IKE packet should > not matter, then having two Configuration Payloads is not a viable > approach. It would be better to introduce two new configuration > attributes, for example named INTERNAL_IP4_HA and INTERNAL_IP6_HA. > > Let me know if this has already been discussed. > > Christian > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ------=_Part_50618_23073197.1221911666808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Please allow me cut in,
If we plan to specifiy INTERNAL_IP4_HA and INTERNAL_IP6_HA,
do we have to specifiy INTERNAL_IP4_LMA and INTERNAL_IP6_MAG as well for PMIP6?
 
thanks
 
-Hui

2008/9/18 <Christian.Kaas-Petersen@tietoenator.com>
This mail-list is of course not responsible for all uses of the IKE
protocol.  But I wonder if the following case has been or is being
discussed.

3GPP has in document TS 24.302 (can be retrieved from
http://www.3gpp.org/ftp/Specs/html-info/24302.htm), section 7.2.2,
specified a use of IKE, where IKE sets up a secure tunnel to
a security gateway, denoted ePDG, and expects this security gateway
to return both an address to the mobile node, which normally
will be a care-of address, and the address(es) of the home agent.
The said document thinks this possible by having two Configuration
Payloads.  IKEv2bis, and previous documents, only indicated one
Configuration Payload to be present, and with the recent discussion
in mind where the order of the payloads in an IKE packet should
not matter, then having two Configuration Payloads is not a viable
approach.  It would be better to introduce two new configuration
attributes, for example named INTERNAL_IP4_HA and INTERNAL_IP6_HA.

Let me know if this has already been discussed.

Christian
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

------=_Part_50618_23073197.1221911666808-- --===============1522054305== 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 --===============1522054305==-- From ipsec-bounces@ietf.org Sat Sep 20 04:59:04 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D38223A69EF; Sat, 20 Sep 2008 04:59:04 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E43FA3A69EF for ; Sat, 20 Sep 2008 04:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HEXOCTDWORD=2] 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 L7BZ3+HSG8SG for ; Sat, 20 Sep 2008 04:59:03 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 8E7003A68C8 for ; Sat, 20 Sep 2008 04:59:02 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so309100eyd.31 for ; Sat, 20 Sep 2008 04:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=Ww9Zaq9DzvFJsOrNg1LPmQu5rfnSPT54rb/Dl/nyWRs=; b=sifiRS9qJzE9KvbTrAeR3HLnRvOl5Bp83/F7Gh/B2r3BjO7KqNqARYHaLnTX8/Dwnu 0hNMxdeOx36UEVz8KEPtuW4Xv5lYFUO7awR1AKHxiViQEav/N/WxNquQ/hDuZ6PKMEqX 9DBEhYAmDnj8KQ4HQqHcdomlom6ku85rdyO3c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=p82cBAH/GlD3KSdKAEr7NtTTcoBqTjkJsXQy3qtYIXfBVf4rqFwJrN1FUgl8Kcj12N WbxtBbk88a7+ekqCCCZmqif9gUWG4CxnJodGp3jGyFZthHdRpnGUEWO6MSqCXNQfa+DG j2+42IU7s6wFvKli3o9DziLpIa2T8C/cEw4J4= Received: by 10.210.36.8 with SMTP id j8mr1636798ebj.130.1221911957232; Sat, 20 Sep 2008 04:59:17 -0700 (PDT) Received: by 10.210.115.8 with HTTP; Sat, 20 Sep 2008 04:59:17 -0700 (PDT) Message-ID: <1d38a3350809200459m3f9d0216k30377fb443fb51f6@mail.gmail.com> Date: Sat, 20 Sep 2008 19:59:17 +0800 From: "Hui Deng" To: "Tero Kivinen" In-Reply-To: <18642.12494.564286.298618@fireball.kivinen.iki.fi> MIME-Version: 1.0 References: <18642.12494.564286.298618@fireball.kivinen.iki.fi> Cc: Christian.Kaas-Petersen@tietoenator.com, ipsec@ietf.org Subject: Re: [IPsec] Use of IKE to obtain address of home agent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1891069129==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1891069129== Content-Type: multipart/alternative; boundary="----=_Part_50655_1403034.1221911957218" ------=_Part_50655_1403034.1221911957218 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Please allow me to cut in, 2008/9/18 Tero Kivinen > Christian.Kaas-Petersen@tietoenator.com writes: > > 3GPP has in document TS 24.302 (can be retrieved from > > http://www.3gpp.org/ftp/Specs/html-info/24302.htm), section 7.2.2, > > specified a use of IKE, where IKE sets up a secure tunnel to > > a security gateway, denoted ePDG, and expects this security gateway > > to return both an address to the mobile node, which normally > > will be a care-of address, and the address(es) of the home agent. > > The said document thinks this possible by having two Configuration > > Payloads. IKEv2bis, and previous documents, only indicated one > > Configuration Payload to be present, and with the recent discussion > > in mind where the order of the payloads in an IKE packet should > > not matter, then having two Configuration Payloads is not a viable > > approach. It would be better to introduce two new configuration > > attributes, for example named INTERNAL_IP4_HA and INTERNAL_IP6_HA. > > Yes, it would be better to have 2 new configuration options. The > section 7.2.2. does not actually specify which configuration attribute > type is used to negotiate Home Agent addresses. > > Including more than one configuration payloads in the exchange, would > be bad idea, as the configuration payloads do not hve any kind of > transaction id or similar, meaning there is no way to know which > CFG_REPLY matches which CFG_REQUEST if there is multiple configuration > payloads (of same CFG TYPE) in same exchange. > ==> I can't imagine the issue if we include two payloads even without an transaction ID here. could you help to elaborate more, bascially, I assume there are consecutively ordered. thanks -Hui > > Another option is to use the INTERNAL_IP{4,6}_DHCP attribute in IKEv2 > and then get the home agent address from the DHCP server. > -- > kivinen@safenet-inc.com > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > ------=_Part_50655_1403034.1221911957218 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Please allow me to cut in,

2008/9/18 Tero Kivinen <kivinen@iki.fi>
Christian.Kaas-Petersen@tietoenator.com writes:
> 3GPP has in document TS 24.302 (can be retrieved from
> http://www.3gpp.org/ftp/Specs/html-info/24302.htm), section 7.2.2,
> specified a use of IKE, where IKE sets up a secure tunnel to
> a security gateway, denoted ePDG, and expects this security gateway
> to return both an address to the mobile node, which normally
> will be a care-of address, and the address(es) of the home agent.
> The said document thinks this possible by having two Configuration
> Payloads.  IKEv2bis, and previous documents, only indicated one
> Configuration Payload to be present, and with the recent discussion
> in mind where the order of the payloads in an IKE packet should
> not matter, then having two Configuration Payloads is not a viable
> approach.  It would be better to introduce two new configuration
> attributes, for example named INTERNAL_IP4_HA and INTERNAL_IP6_HA.

Yes, it would be better to have 2 new configuration options. The
section 7.2.2. does not actually specify which configuration attribute
type is used to negotiate Home Agent addresses.

Including more than one configuration payloads in the exchange, would
be bad idea, as the configuration payloads do not hve any kind of
transaction id or similar, meaning there is no way to know which
CFG_REPLY matches which CFG_REQUEST if there is multiple configuration
payloads (of same CFG TYPE) in same exchange.
==> I can't imagine the issue if we include two payloads even without an transaction ID here. could you help to elaborate more, bascially, I assume there are consecutively ordered.
 
thanks
 
-Hui
 

Another option is to use the INTERNAL_IP{4,6}_DHCP attribute in IKEv2
and then get the home agent address from the DHCP server.
--
kivinen@safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

------=_Part_50655_1403034.1221911957218-- --===============1891069129== 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 --===============1891069129==-- From ipsec-bounces@ietf.org Sat Sep 20 19:28:02 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A016C3A6A3F; Sat, 20 Sep 2008 19:28:02 -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 032963A6A3F for ; Sat, 20 Sep 2008 19:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.492 X-Spam-Level: * X-Spam-Status: No, score=1.492 tagged_above=-999 required=5 tests=[AWL=-4.123, BAYES_40=-0.185, J_CHICKENPOX_31=0.6, J_CHICKENPOX_42=0.6, MANGLED_HERE=2.3, MANGLED_TOOL=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 1Dfsj8UDIepF for ; Sat, 20 Sep 2008 19:27:57 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8B61B3A6885 for ; Sat, 20 Sep 2008 19:27:56 -0700 (PDT) Received: from [10.20.30.152] (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 m8L2S7k5094373 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 20 Sep 2008 19:28:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18574.24516.764629.590327@fireball.kivinen.iki.fi> References: <18574.24516.764629.590327@fireball.kivinen.iki.fi> Date: Sat, 20 Sep 2008 19:27:43 -0700 To: ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] Some (ok, a lot) comments to ikev2bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 3:09 AM +0300 7/29/08, Tero Kivinen wrote: >Here is my comments to the draft-hoffman-ikev2bis-03.txt. As Pasi said >I need to include new text for all of them before they will be >accepted, I had to make this email quite long... Still wasn't manage >to include new text for all of my comments, but I hope the editors can >still understand and accept even those comments :-) Whew. There are three types of responses. Each type has a different effect on the new WG issue tracker. My responses are marked with "===" at the beginning of the line. - Done. This is now in my working copy of -01. Yaron won't fill these in the tracker. - Not done, but take it to the list. This is not a simple editorial change or clarification, and needs to be taken to the list for discussion. Yaron will mark these in the tracker as open issues. - Not done and disagree. Some of these are editorial changes that make things harder to understand, others are disagreements about whether they are correct. Yaron will mark these in the issue tracker as closed issues; someone can re-open them if sufficiently motivated. > 1. Introduction > > IKE performs mutual authentication between two parties and > establishes an IKE security association (SA) that includes shared > secret information that can be used to efficiently establish SAs for > Encapsulating Security Payload (ESP) [ESP] and/or Authentication > Header (AH) [AH] and a set of cryptographic algorithms to be used by > the SAs to protect the traffic that they carry. In this document, > the term "suite" or "cryptographic suite" refers to a complete set of > algorithms used to protect an SA. An initiator proposes one or more > suites by listing supported algorithms that can be combined into > suites in a mix-and-match fashion. IKE can also negotiate use of IP > Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA. > We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get > set up through that IKE_SA we call "CHILD_SAs". I think all of those "ESP and/or AH" should be changed to "ESP or AH" just to clarify that there cannot bve combined ESP and AH, so s/and\/or/or/g; ===Done > The second request/response (IKE_AUTH) transmits identities, proves > knowledge of the secrets corresponding to the two identities, and > sets up an SA for the first (and often only) AH and/or ESP CHILD_SA. Should already say here that even if the child sa creation fails in here, the IKE sa is created and stays up i.e: The second request/response (IKE_AUTH) transmits identities, proves knowledge of the secrets corresponding to the two identities, and sets up an SA for the first (and often only) AH or ESP CHILD_SA (unless there is failure setting up the AH or ESP CHILD_SA, in which case the IKE SA is still established without IPsec SA). ===Done > 1.2. The Initial Exchanges ... > HDR, SK {IDi, [CERT,] [CERTREQ,] > [IDr,] AUTH, SAi2, > TSi, TSr} --> > > The initiator asserts its identity with the IDi payload, proves > knowledge of the secret corresponding to IDi and integrity protects > the contents of the first message using the AUTH payload (see > Section 2.15). It might also send its certificate(s) in CERT > payload(s) and a list of its trust anchors in CERTREQ payload(s). If > any CERT payloads are included, the first certificate provided MUST > contain the public key used to verify the AUTH field. The optional > payload IDr enables the initiator to specify which of the responder's > identities it wants to talk to. This is useful when the machine on > which the responder is running is hosting multiple identities at the > same IP address. The initiator begins negotiation of a CHILD_SA I think we might want to say something about here that IDr is only hint for the responder of which ID to use, i.e if the IDr is not acceptable for the responder, he might use some other IDr on the next packet and finish the exchange (as they have already done some of the expensive calculations, like Diffie-Hellman). If the initiator then does not accept that fact that responder used different IDr that which was requested, it can close the SA after noticing the fact. ===Done > same IP address. The initiator begins negotiation of a CHILD_SA > using the SAi2 payload. The final fields (starting with SAi2) are > described in the description of the CREATE_CHILD_SA exchange. > > <-- HDR, SK {IDr, [CERT,] AUTH, > SAr2, TSi, TSr} > > The responder asserts its identity with the IDr payload, optionally > sends one or more certificates (again with the certificate containing > the public key used to verify AUTH listed first), authenticates its > identity and protects the integrity of the second message with the > AUTH payload, and completes negotiation of a CHILD_SA with the > additional fields described below in the CREATE_CHILD_SA exchange. > > The recipients of messages 3 and 4 MUST verify that all signatures > and MACs are computed correctly and that the names in the ID payloads > correspond to the keys used to generate the AUTH payload. > > {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange > fails for some reason, the IKE_SA is still created as usual. The > list of responses in the IKE_AUTH exchange that do not prevent an > IKE_SA from being set up include at least the following: > NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, > INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. In the case of the that kind of failure the return packet will then be without the SAr2, Tsi, and TSr, i.e.: <-- HDR, SK {IDr, [CERT,] AUTH, N(error_for_child_sa)} If the authentication fails in such ways that the entries cannot create IKE SA (authentication failure or similar), then the response will be unencrypted, unauthenticated notify. There is no point of sending the notify encrypted and integrity protected, as it is not authenticated (as initiator and responder have not yet verified the AUTH payloads): <-- HDR, N(error_for_ike_sa) The initiator receiving such reply MUST NOT immediately stop the SA creation, but it should still retransmit the message few times, in case that error notify was forgery and the real responder will reply with valid reply. It can use the recipient of such message as a hint to tell that authentication failed, thus it can shorten the retransmission timers from few minutes down to few tens of seconds. ===Not done. This is interesting, but should be discussed on the list. > 1.3. The CREATE_CHILD_SA Exchange ... > The CREATE_CHILD_SA response for creating a new CHILD_SA is: > > <-- HDR, SK {SA, Nr, [KEr], > TSi, TSr} > > The responder replies (using the same Message ID to respond) with the ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This is confusing, as we have not introduced message id at all at this point. I suggest removing the "(using the same Message ID to respond)". ===Not done. Disagree. It is important here. > 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange > > The CREATE_CHILD_SA request for rekeying an IKE_SA is: > > Initiator Responder > ------------------------------------------------------------------- > HDR, SK {SA, Ni, [KEi]} --> > > The initiator sends SA offer(s) in the SA payload, a nonce in the Ni > payload, and a Diffie-Hellman value in the KEi payload. The KEi > payload SHOULD be included. New initiator and responder SPIs are > supplied in the SPI fields. Add text where the SPIs fields are: New initiator and responder SPIs are supplied in the SPI fields, of SA payload. ===Done. > The CREATE_CHILD_SA response for rekeying an IKE_SA is: > > <-- HDR, SK {SA, Nr,[KEr]} > > The responder replies (using the same Message ID to respond) with the Same here with the "using the same Message ID to respond)". ===Not done. Disagree. It is important here. > 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange ... > {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a > CREATE_CHILD_SA exchange if the purpose of the exchange is to replace > an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is > identified by the SPI field in the Notify payload; this is the SPI > the exchange initiator would expect in inbound ESP or AH packets. > There is no data associated with this Notify type. Add clarification here specifying the value of the Protocol ID field: The Protocol ID field of REKEY_SA notify is set accordingly to ESP (3) or AH (2). ===Not done. Disagree. There may be additional protocol IDs in the future. > The CREATE_CHILD_SA response for rekeying a CHILD_SA is: > > <-- HDR, SK {SA, Nr, [KEr], > Si, TSr} There is missing T in the picture: <-- HDR, SK {SA, Nr, [KEr], TSi, TSr} ===Done > The responder replies (using the same Message ID to respond) with the Again the "using the same Message ID to respond)". ===Not done. Disagree. It is important here. > accepted offer in an SA payload, and a Diffie-Hellman value in the > KEr payload if KEi was included in the request and the selected > cryptographic suite includes that group. > > The traffic selectors for traffic to be sent on that SA are specified > in the TS payloads in the response, which may be a subset of what the > initiator of the CHILD_SA proposed. Add comment about which traffic selectors to use in the rekeying: When doing rekeying the traffic selectors SHOULD come from the original decorrelated policy, i.e. not the same traffic selectors which the old SA had in case the responder narrowed them, but from the policy which initiator used originally to create the IPsec SA. This allows the SA to expand to full traffic selector set allowed by latest (perhaps changed) policy. ===Not done. This is interesting, but should be discussed on the list. Also I think we should mention that the traffic selectors for the rekying should have those selectors from the packet (see section 2.9): To allow responder to do intelligent narrowing of the traffic selector the responder should know which packet triggered the rekeying, so it will not narrow the traffic selectors to set which is not usable for the packet triggering the rekeying. This means that even the traffic selectors for the rekeying needs to have those selectors from the packet (see section 2.9). Note, that if the responders policy has changed, it is possible that originally traffic that fit to one SA cannot fit to one SA anymore, which means the responder will narrow the traffic selectors so that not all original traffic fits to SA anymore. In that case the initiator getting packet that only fits the old SA (which is waiting to be deleted) but not new, should create new SA for this traffic too (but it is not rekeying anymore, so no REKEY_SA notify is included in the exchange). Same thing happens when the original SA expires, and one ends gets packet which not fit the current traffic selectors, but instead triggers new SA creation. ===Not done. This is interesting, but should be discussed on the list. > 1.5. Informational Messages outside of an IKE_SA ... > {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE > INFORMATIONAL exchange when a node receives an ESP or AH packet with > an invalid SPI. The Notification Data contains the SPI of the > invalid packet. This usually indicates a node has rebooted and > forgotten an SA. If this Informational Message is sent outside the > context of an IKE_SA, it should only be used by the recipient as a > "hint" that something might be wrong (because it could easily be > forged). If the notification data is used for the SPI of the invalid packet, how can the recipient of such notify know whether that SPI was for ESP or AH? As far as I can see, it cannot, but I think it does not matter as SPIs are now supposed to be unique (i.e. protocol is no loger include as key). Perhaps we should just note this fact here? ===Not done. This is interesting, but should be discussed on the list. > {{ Clarif-7.7 }} There are two cases when such a one-way notification > is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are > sent outside of an IKE_SA. Note that such notifications are > explicitly not Informational exchanges; these are one-way messages > that must not be responded to. In case of INVALID_IKE_SPI, the > message sent is a response message, and thus it is sent to the IP > address and port from whence it came with the same IKE SPIs and the > Message ID copied. In case of INVALID_SPI, however, there are no IKE > SPI values that would be meaningful to the recipient of such a > notification. Using zero values or random values are both > acceptable. In a sense INVALID_MAJOR_VERSION is also this kind of notification which is sent outside of an IKE_SA, altought it is sent as a response to the incoming IKE SA creation. Perhaps we should note this fact here? ===Not done. This is interesting, but should be discussed on the list. > 1.6. Requirements Terminology ... > IKEv2 (and IKEv1) developers have noted that there is a great deal of > material in the tables of codes in Section 3.10.1. This leads to > implementers not having all the needed information in the main body > of the docment. Much of the material from those tables has been ^^^^^^^ Typo. ===Done. > 2.1. Use of Retransmission Timers ... > For every pair of IKE messages, the initiator is responsible for > retransmission in the event of a timeout. The responder MUST never > retransmit a response unless it receives a retransmission of the > request. In that event, the responder MUST ignore the retransmitted > request except insofar as it triggers a retransmission of the > response. The initiator MUST remember each request until it receives > the corresponding response. The responder MUST remember each > response until it receives a request whose sequence number is larger > than or equal to the sequence number in the response plus its window > size (see Section 2.3). One of the problems here is that if we are using large window size, we have to keep that many messages for ever. It would be nice, we the responder of the request, could forget the response packet after lets say 10 minutes after it sent it out to requestor. There is no reason why the other end should be allowed to resend his request 4 hours later and expect that other end can still resend reply back. So suggest adding: Responder are allowed to forget response after long timeout for the memory saving purposes. The timeout must be longer than several minutes that could be used for the retransmission timers of the other end. ===Not done. This is a change to the protocol. The WG might want it, but it will have to be an explicit decision from the WG. > IKE is a reliable protocol, in the sense that the initiator MUST > retransmit a request until either it receives a corresponding reply > OR it deems the IKE security association to have failed and it > discards all state associated with the IKE_SA and any CHILD_SAs > negotiated using that IKE_SA. > > {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require > some special handling. When a responder receives an IKE_SA_INIT > request, it has to determine whether the packet is retransmission > belonging to an existing "half-open" IKE_SA (in which case the > responder retransmits the same response), or a new request (in which > case the responder creates a new IKE_SA and sends a fresh response), > or it belongs to an existing IKE_SA where the IKE_AUTH request has > been already received (in which case the responder ignores it). There is also the case of the invalid ke and cookie notifies, i.e we need to add comment about those too: ... or it belongs to an existing IKE_SA where the IKE_AUTH request has been already received (in which case the responder ignores it), or it is INVALID_KE_PAYLOAD or COOKIE notify responses to the IKE_SA_INIT request. ===Not done. This is interesting, but should be discussed on the list. > It is not sufficient to use the initiator's SPI and/or IP address to > differentiate between these three cases because two different peers > behind a single NAT could choose the same initiator SPI. Instead, a > robust responder will do the IKE_SA lookup using the whole packet, > its hash, or the Ni payload. We might want to also explicitly say that the retransmissions from the initiator MUST be bitwise identicdal to the original request. We do say that for the responses, but I do not think we have explicit text about for the requests. ===Done. > 2.2. Use of Sequence Numbers for Message ID > > The Message ID is a 32-bit quantity, which is zero for the > IKE_SA_INIT messages (including retries of the message due to > responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), > and incremented for each subsequent exchange. Add text: The Message ID is reset to zero also after IKE SA rekey for the new IKE SA. ===Not done. This is interesting, but should be discussed on the list. > Note that Message IDs are cryptographically protected and provide > protection against message replays. In the unlikely event that > Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be > closed. Rekeying an IKE_SA resets the sequence numbers. ^ or rekeyed. ===Done. > 2.3. Window Size for Overlapping Requests ... > An IKE endpoint MUST wait for a response to each of its messages > before sending a subsequent message unless it has received a > SET_WINDOW_SIZE Notify message from its peer informing it that the > peer is prepared to maintain state for multiple outstanding messages > in order to allow greater throughput. Or the text about allowed to forget responses after some long time could be here too instead of the section 2.1. ===Not done. This is a change to the protocol. The WG might want it, but it will have to be explicit. > 2.4. State Synchronization and Connection Timeouts ... > payload that contains no payloads). If a cryptographically protected > message has been received from the other side recently, unprotected > notifications MAY be ignored. Implementations MUST limit the rate at > which they take actions based on unprotected messages. I suggest adding "fresh" to the sentence there i.e.: If a cryptographically protected fresh (i.e. not retransmissions) message has been received from the other side recently, unprotected notifications MAY be ignored ===Dpme > 2.5. Version Numbers and Forward Compatibility ... > IKEv2 adds a "critical" flag to each payload header for further > flexibility for forward compatibility. If the critical flag is set > and the payload type is unrecognized, the message MUST be rejected > and the response to the IKE request containing that payload MUST > include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an > unsupported critical payload was included. {{ 3.10.1-1 }} In that > Notify payload, the notification data contains the one-octet payload > type. If the critical flag is not set and the payload type is > unsupported, that payload MUST be ignored. Payloads sent in IKE > response messages MUST NOT have the critical flag set. Note that the > critical flag applies only to the payload type, not the contents. If > the payload type is recognized, but the payload contains something > which is not (such as an unknown transform inside an SA payload, or > an unknown Notify Message Type inside a Notify payload), the critical > flag is ignored. What if such UNSUPPORTED_CRITICAL_PAYLOAD error happens during the initial IKE_SA_INIT message, or do we forbid enchancements and modifications which might cause such error? ===Not done. This is interesting, but should be discussed on the list. > NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the > order shown in the figures in Section 2? Can we eliminate the > requirement in the following paragraph? If not, we will probably > have to add a new appendix with the order, but there is no reason to > do that if no one actually cares. {{ Remove this paragraph before the > document is finalized, of course. }} Our implemnentation do not care about the order of the payloads except in some specific places (CERT payloads and so on). ===Note done. We still need to hear from others. > {{ Demoted the SHOULD in the second clause }}Although new payload > types may be added in the future and may appear interleaved with the > fields defined in this specification, implementations MUST send the > payloads defined in this specification in the order shown in the > figures in Section 2; implementations are explicitly allowed to > reject as invalid a message with those payloads in any other order. I would really like to change this to say that payloads must be accepted in any order, but implementations should try to send them out in the order shown in the figures. Exceptions to this is the CERT payloads (the end entity cert MUST be first), and REKEY and COOKIE notifies. ===Not done. This is interesting, but should be discussed on the list. > 2.6. Cookies This should probably be renamed to "IKE SA SPIs and Cookies". ===Done. > Unlike ESP and AH where only the recipient's SPI appears in the > header of a message, in IKE the sender's SPI is also sent in every > message. Since the SPI chosen by the original initiator of the > IKE_SA is always sent first, an endpoint with multiple IKE_SAs open > that wants to find the appropriate IKE_SA using the SPI it assigned > must look at the I(nitiator) Flag bit in the header to determine > whether it assigned the first or the second eight octets. Our implementation originally only checked its own SPI half, and didn't verify that the other ends SPI half didn't change. This was found out in the interop, and we fixed it to check the other ends SPI also, but I wonder should we say one way or the other here? Also what SPI should the response have, i.e. the SPIs from the request, or the SPIs from the original IKE SA creation. I think it might be easier to just say, that implementations can use their own SPI to find the IKE SA data, but MUST also check that the other ends SPI matches the SPIs stored with IKE SA data. ===Not done. This is interesting, but should be discussed on the list. ... > A good way to do this is to set the responder cookie to be: > > Cookie = | Hash(Ni | IPi | SPIi | ) I was starting to wonder if that Cookie should also include the Port part, especially in the NAT-T case? ===Not done. This is interesting, but should be discussed on the list. > where is a randomly generated secret known only to the > responder and periodically changed and | indicates concatenation. > should be changed whenever is > regenerated. The cookie can be recomputed when the IKE_SA_INIT > arrives the second time and compared to the cookie in the received > message. If it matches, the responder knows that the cookie was > generated since the last change to and that IPi must be the > same as the source address it saw the first time. Incorporating SPIi > into the calculation ensures that if multiple IKE_SAs are being set > up in parallel they will all get different cookies (assuming the > initiator chooses unique SPIi's). Incorporating Ni into the hash The real reason to hash the SPIs to the cookie is to make sure that attacker cannot fetch one one cookie from the other end, and then initiate 100 IKE_SA_INIT exchanges all with different initiator SPIs (and perhaps port numbers) so that the for the responder it looked like there is lots of machines behind one NAT box who are all trying to connect. As the cookie is tied to the SPIi the attacker cannot use cookie multiple times. ===Not done. This is interesting, but should be discussed on the list. > {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request > containing a cookie whose contents do not match the value expected, > that party MUST ignore the cookie and process the message as if no > cookie had been included; usually this means sending a response > containing a new cookie. We might want to add text here saying: Initiator should limit the number of cookie exchanges it tries before giving up, especially as if the attacker decides to forge multiple cookie responses to the initiators IKE_SA_INIT message, each of those forged cookie reply will trigger 2 packets, one packet from the initiator to the responder (which will reject those cookies), and one reply from responder to initiator giving out correct cookie. ===Done. > 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD > > {{ This section added by Clarif-2.4 }} > > There are two common reasons why the initiator may have to retry the > IKE_SA_INIT exchange: the responder requests a cookie or wants a > different Diffie-Hellman group than was included in the KEi payload. > If the initiator receives a cookie from the responder, the initiator > needs to decide whether or not to include the cookie in only the next > retry of the IKE_SA_INIT request, or in all subsequent retries as > well. > > If the initiator includes the cookie only in the next retry, one > additional roundtrip may be needed in some cases. An additional > roundtrip is needed also if the initiator includes the cookie in all > retries, but the responder does not support this. For instance, if > the responder includes the SAi1 and KEi payloads in cookie > calculation, it will reject the request by sending a new cookie. > > If both peers support including the cookie in all retries, a slightly > shorter exchange can happen. Implementations SHOULD support this > shorter exchange, but MUST NOT fail if other implementations do not > support this shorter exchange. We should also explain better what this slightly shorter exchange is, and what other options there are. I think clarification had more text about this that could be copied her.e ===Done. > 2.7. Cryptographic Algorithm Negotiation ... > Each IPsec protocol proposal contains one or more transforms. Each > transform contains a transform type. The accepted cryptographic > suite MUST contain exactly one transform of each type included in the > proposal. For example: if an ESP proposal includes transforms > ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, > AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one > of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six > combinations are acceptable. Perhaps we should add here paragraph explaining the most common reason of the multiple propsoals: If both combined mode ciphers and normal ciphers with integrity protection needs to be proposed, the inititor needs to use two proposals. One of them includes all the combined mode ciphers, without the integrity algorithms (as combined mode ciphers are not allowed to have any other integrity algorithm than none), and the another includes normal ciphers and the integrity algoritms for them. ===Not done. This level of specificity is not needed, and we don't talk about combined modes in the original IKEv2 doc. > 2.8. Rekeying ... > {{ Demoted the SHOULD }} The node that initiated the surviving > rekeyed SA should delete the replaced SA after the new one is > established. I think this paragraph is in bit funny place, perhaps move it to some better location. ===Note done. It is fine where it is. > 2.8.1. Simultaneous CHILD_SA rekeying Instead of simultaneous CHILD_SA rekeying, there should be section of simultaneous IKE SA rekeying. Simultaneous CHILD_SA rekeying just results few extra SAs that will disappear after next rekeys (at worst there will be 2 SA pairs, but all others will be deleted instead of being rekeyed as they are not used. The simultaneous IKE SA rekeying is much more important case to get correct, as both ends MUST agree on which IKE SA survive, as otherwise they will move the CHILD SA to wrong IKE SA and their state is completely messed up after that. This section should also explain that even if the simultaneous rekeying of IKE SA is noticed only AFTER the whole rekeying is already finished, both ends MUST still correctly detect it and act based on the fact which IKE SA will survive. This means that the old IKE SA should not be deleted too quickly after the IKE SA rekey finished, just in case there happened to be simultaneous rekey in progress. The one doing the delete should wait at least few minutes before deleting the old IKE SA, so it can be sure that other end does not have simultaneous rekey going on the IKE SA. ===Not done. More specific text is needed. This is interesting, but should be discussed on the list. > 2.8.2. Rekeying the IKE_SA Versus Reauthentication ... > Although rekeying the IKE_SA may be important in some environments, > reauthentication (the verification that the parties still have access > to the long-term credentials) is often more important. I disagree with that statement, and I think we should not have this kind of opinions in the document, as they do not really give any new information for the protocol point of view. So I suggest removing the whole paragraph. ===Not done. It explains the motivation for the rest of the section. It is true that it is "often" more important. > 2.9. Traffic Selector Negotiation > > {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives > an IP packet and matches a "protect" selector in its Security Policy > Database (SPD), the subsystem protects that packet with IPsec. When > no SA exists yet, it is the task of IKE to create it. Maintenance of > a system's SPD is outside the scope of IKE (see [PFKEY] for an > example protocol), though some implementations might update their SPD > in connection with the running of IKE (for an example scenario, see > Section 1.1.3). I do not think we should be using PFKEY as example there, as it does not support IKEv2. That could of course be new work item for the WG some day, i.e. update of the PFKEY document to update IKEv2, but before we have that, we should not point to it, it will just cause confusion. ===Done. Actually, pointed out that PFKEY is for IKEv1 only. > 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. TSr specifies the destination address of the traffic > forwarded to (or the source address of the traffic forwarded from) > the responder of the CHILD_SA pair. For example, if the original > initiator requests the creation of a CHILD_SA pair, and wishes to > tunnel all traffic from subnet 192.0.1.* on the initiator's side to > subnet 192.0.2.* on the responder's side, the initiator would include > a single traffic selector in each TS payload. TSi would specify the > address range (192.0.1.0 - 192.0.1.255) and TSr would specify the > address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was > acceptable to the responder, it would send identical TS payloads > back. (Note: The IP address range 192.0.2.* has been reserved for > use in examples in RFCs and similar documents. This document needed > two such ranges, and so also used 192.0.1.*. This should not be > confused with any actual address.) I think we should use only the one example network that has been reserved for that purpose, i.e get the rid of the 192.0.1.* address space. As we do use ranges in all cases in the IKEv2, there is no reason why the networks need to be /24 subnets. How about using 192.0.2.0/25 (i.e. 192.0.2.0 - 192.0.2.127) and 192.0.2.128/25 (i.e. 192.0.2.128 - 192.0.2.255) instead. ===Not done. People really relate to /24s much better. Otherwise we might want to add comment to all other places having that 192.0.1.* network (which is actually used much more than the real example network of 192.0.2.*). ===Not done. Developers reading this document understand what is going on. ... > o If the responder's policy allows it to accept the first selector > of TSi and TSr, then the responder MUST narrow the traffic > selectors to a subset that includes the initiator's first choices. > In this example above, the responder might respond with TSi being > (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. Or it can also return some bigger range that is subset of the initiators offer. ===Not done. That is covered by the first sentence. > o If the responder's policy does not allow it to accept the first > selector of TSi and TSr, the responder narrows to an acceptable > subset of TSi and TSr. > > When narrowing is done, there may be several subsets that are > acceptable but their union is not. In this case, the responder > arbitrarily chooses one of them, and MAY include an I do not think the responder can arbitrarily choose one of them, it MUST select the one that includes the first TS if it was acceptable. ===Not done. This is a technical change. This is interesting, but should be discussed on the list. > 2.9.1. Traffic Selectors Violating Own Policy > > {{ Clarif-4.12 }} > > When creating a new SA, the initiator needs to avoid proposing > traffic selectors that violate its own policy. If this rule is not > followed, valid traffic may be dropped. We should note here, that if you follow the RFC 4301 and use decorrelated policies, then this kind of policy violations cannot happen. ===Done. > 2.15. Authentication of the IKE_SA ... > RestOfRespIDPayload = IDType | RESERVED | InitIDData ^^^^ Should be RespIDData. ===Done. > MACedIDForR = prf(SK_pr, RestOfRespIDPayload) > > Note that all of the payloads are included under the signature, > including any payload types not defined in this document. If the > first message of the exchange is sent twice (the second time with a > responder cookie and/or a different Diffie-Hellman group), it is the > second version of the message that is signed. The first message might be sent more than twice, in case both INVALID_KE_PAYLOAD and COOKIE exchanges happen, i.e. change to: If the first message of the exchange is sent multiple times (i.e with a responder cookie (or even multiple of cookie exchanges) and/or a different Diffie-Hellman group), it is the last version of the message that is signed. ===Done. > 2.16. Extensible Authentication Protocol Methods ... > In addition to authentication using public key signatures and shared > secrets, IKE supports authentication using methods defined in RFC > 3748 [EAP]. Typically, these methods are asymmetric (designed for a > user authenticating to a server), and they may not be mutual. {{ In > the next sentence, changed "public key signature based" to "strong" > }} For this reason, these protocols are typically used to > authenticate the initiator to the responder and MUST be used in > conjunction with a strong authentication of the responder to the This change is quite big protocol change to the bits on the wire, and also opens word "strong" to interpretation. I.e. what is strong authentication? As this is not defined here to vendors might implement that differently and result versions which cannot interoperate, because of this different interpretation. ===Done. > 2.19. Requesting an Internal Address on a Remote Network ... > {{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by > responder in the case where CP(CFG_REQUEST) was expected but not > received, and so is a conflict with locally configured policy. There > is no associated data. This should be combined with last paragraph in this section: > The responder MUST NOT send a CFG_REPLY without having first received > a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS > to perform an unnecessary configuration lookup if the IRAC cannot > process the REPLY. In the case where the IRAS's configuration > requires that CP be used for a given identity IDi, but IRAC has > failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and > terminate the IKE exchange with a FAILED_CP_REQUIRED error. ===Done (simple move). We should also mention here that the FAILED_CP_REQUIRED is not fatal error to the IKE SA, it just cause the CHILD SA creation fail on the IKE_AUTH, but the IKE SA should be still created, and initiator can fix this by initiating new configuration payload request later. ===Done. > 2.21. Error Handling ... > A node receiving such an unprotected Notify payload MUST NOT respond > and MUST NOT change the state of any existing SAs. The message might > be a forgery or might be a response the genuine correspondent was > tricked into sending. {{ Demoted two SHOULDs }} A node should treat ^^^^^^ I think that should still be capital SHOULD. ===Not done. "...SHOULD treat as a hint..." is meaningless from an implementation standpoint. > such a message (and also a network message like ICMP destination > unreachable) as a hint that there might be problems with SAs to that > IP address and should initiate a liveness test for any such IKE_SA. > An implementation SHOULD limit the frequency of such tests to avoid > being tricked into participating in a denial of service attack. > > A node receiving a suspicious message from an IP address with which > it has an IKE_SA MAY send an IKE Notify payload in an IKE > INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The > recipient MUST NOT change the state of any SAs as a result, but may > wish to audit the event to aid in diagnosing malfunctions. A node > MUST limit the rate at which it will send messages in response to > unprotected messages. We should also extend this section and include at least following cases: - Errors happening before authentication - Errors in the IPsec SA creation on IKE_AUTH - Describe which errors are so fatal that they cause the whole IKE SA to destroyed. ===Not done. Each of these are interesting, and need to be taken up individually on the list. > 2.23. NAT Traversal ... > Opening an IPsec connection through a NAT introduces special > problems. If the connection runs in transport mode, changing the IP > addresses on packets will cause the checksums to fail and the NAT > cannot correct the checksums because they are cryptographically > protected. Even in tunnel mode, there are routing problems because > transparently translating the addresses of AH and ESP packets > requires special logic in the NAT and that logic is heuristic and > unreliable in nature. For that reason, IKEv2 can negotiate UDP ^^^^^^^^^^^^^ We do not have negotiation for UDP encapsulation, we just start using it when we detect NAT. I.e change to "will use". ===Done. > encapsulation of IKE and ESP packets. This encoding is slightly less > efficient but is easier for NATs to process. In addition, firewalls > may be configured to pass IPsec traffic over UDP but not ESP/AH or > vice versa. > > It is a common practice of NATs to translate TCP and UDP port numbers > as well as addresses and use the port numbers of inbound packets to > decide which internal node should get a given packet. For this > reason, even though IKE packets MUST be sent from and to UDP port > 500, they MUST be accepted coming from any port and responses MUST be ^ Add "or 4500". ==Done. > sent to the port from whence they came. This is because the ports > may be modified as the packets pass through NATs. Similarly, IP > addresses of the IKE endpoints are generally not included in the IKE > payloads because the payloads are cryptographically protected and > could not be transparently modified by NATs. > > Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working > through a NAT, it is generally better to pass IKE packets over port > 4500 because some older NATs handle IKE traffic on port 500 cleverly > in an attempt to transparently establish IPsec connections between > endpoints that don't handle NAT traversal themselves. Such NATs may > interfere with the straightforward NAT traversal envisioned by this > document. Everything after the first sentence in the paragraph is just misleading and should be removed. ===Not done. This was generally agreed to, I believe. > {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT > between it and its correspondent MUST send all subsequent traffic > from port 4500, which NATs should not treat specially (as they might > with port 500). > o To tunnel IKE packets over UDP port 4500, the IKE header has four > octets of zero prepended and the result immediately follows the > UDP header. To tunnel ESP packets over UDP port 4500, the ESP > header immediately follows the UDP header. Since the first four > octets of the ESP header contain the SPI, and the SPI cannot > validly be zero, it is always possible to distinguish ESP and IKE > messages. We should also list whether it is allowed to float to port 4500 even when no NAT is detected (I think the answer is yes). And even if we float to port 4500, the UDP encapsulation should not be enabled or expected unless NAT between is really detected. ===Not done. This was debated on the list at least once in the past and we came up with this wording, but I think it should be debated again now that we have much more implementation experience. > o Implementations MUST process received UDP-encapsulated ESP packets > even when no NAT was detected. > > o The original source and destination IP address required for the > transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) > are obtained from the Traffic Selectors associated with the > exchange. In the case of NAT traversal, the Traffic Selectors > MUST contain exactly one IP address, which is then used as the > original IP address. Getting original source and destination IP address from the traffic selectors do not really work currently. Especially when combined with the selectors from the packet and when responder is behind nat or similar problems. ===Not done. Specify replacement text and discuss on the mailing list. > o There are cases where a NAT box decides to remove mappings that > are still alive (for example, the keepalive interval is too long, > or the NAT box is rebooted). To recover in these cases, hosts > that are not behind a NAT SHOULD send all packets (including > retransmission packets) to the IP address and port from the last > valid authenticated packet from the other end (i.e., dynamically > update the address). A host behind a NAT SHOULD NOT do this > because it opens a DoS attack possibility. Any authenticated IKE > packet or any authenticated UDP-encapsulated ESP packet can be > used to detect that the IP address or the port has changed. This paragraph should here point out that MOBIKE changes this behivor, and point to the MOBIKE documents for more information. ===Not done, but will most likely be. Supply exact text and discuss on the mailing list. > Note that similar but probably not identical actions will likely be > needed to make IKE work with Mobile IP, but such processing is not > addressed by this document. This should most likely be removed now and add pointers to the MOBIKE and other documents. ===Done. But we still want the MOBIKE changes above. > 3.1. The IKE Header ... > o Major Version (4 bits) - Indicates the major version of the IKE > protocol in use. Implementations based on this version of IKE > MUST set the Major Version to 2. Implementations based on > previous versions of IKE and ISAKMP MUST set the Major Version to > 1. Implementations based on this version of IKE MUST reject or > ignore messages containing a version number greater than 2. Change to Implementations based on this version of IKE MUST reject or ignore messages containing a version number greater than 2 with INVALID_MAJOR_VERSION notify (see section 2.5 for more details). ===Done. > o Exchange Type (1 octet) - Indicates the type of exchange being > used. This constrains the payloads sent in each message and > orderings of messages in an exchange. ^^^^^^^^^ What does that try to say? ===Not done. It is saying that exchange types can impose orderings. > * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages > sent by the original initiator of the IKE_SA and MUST be > cleared in messages sent by the original responder. It is used > by the recipient to determine which eight octets of the SPI > were generated by the recipient. Add clarification here, that the Inititor bit does not change even if IKE SA is rekeyed (regardless who rekeys it). ===Done. > 3.3. Security Association Payload ... > The Proposal structure contains within it a Proposal # and an IPsec > protocol ID. Each structure MUST have a proposal number one (1) > greater than the previous structure. The first Proposal in the > initiator's SA payload MUST have a Proposal # of one (1). A proposal > of AH or ESP would have two proposal structures, one for AH with > Proposal #1 and one for ESP with Proposal #2. I think the last sentence should be removed, as it is bit confusing and some people might read it "AH and ESP" and interpret it as bundles. I do not really consider AH or ESP style proposal that common to require example here. Perhaps ESP with combined mode ciphers and ESP with normal ciphers + integrity algorithms would make better example. ===Not done. The current example is clearer than your proposed change because few people understand combined modes, even if the current example is far-fetched. A different, clearer example would be a good replacement for the current text. > 3.3.2. Transform Substructure ... > (*) Negotiating an integrity algorithm is mandatory for the > Encrypted payload format specified in this document. Future > documents may specify additional formats based on authenticated > encryption, in which case a separate integrity algorithm is not > negotiated. We already have the future documents ready, and they are in the rfc editor queue, so we can add reference here. ===Done. > 3.3.3. Valid Transform Types by Protocol ... > (*) Negotiating an integrity algorithm is mandatory for the > Encrypted payload format specified in this document. Future > documents may specify additional formats based on authenticated > encryption, in which case a separate integrity algorithm is not > negotiated. Same change here. ===Done. > 3.3.6. Attribute Negotiation > > During security association negotiation initiators present offers to > responders. Responders MUST select a single complete set of > parameters from the offers (or reject all offers if none are > acceptable). If there are multiple proposals, the responder MUST > choose a single proposal. If the selected proposal has multiple > Transforms with the same type, the responder MUST choose a single > one. Any attributes of a selected transform MUST be returned > unmodified. The initiator of an exchange MUST check that the > accepted offer is consistent with one of its proposals, and if not > that response MUST be rejected. One of the questions that have been out long time, is that do all of the offered proposals must have identical Diffie-Hellman group lists. What does it mean if one of the proposals have different list than some other proposal. Can the KE payload include then be from such group that only exists in one of the lists. Also do the Diffie-Hellman groups need to be repeated on every single proposal. I think we should add some text explaining that. ===Not done. Clearly, the WG needs to decide what to do here first. > 3.5. Identification Payloads ... > ID_RFC822_ADDR 3 > A fully-qualified RFC822 email address string, An example of a > ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not > contain any terminators. As there was reference added to the IDNA in the FQDN case, should we also refer here to the international email addresses specification? ===Done. > 3.6. Certificate Payload ... > Certificate Encoding Value > ---------------------------------------------------- > RESERVED 0 > PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED > PGP Certificate 2 UNSPECIFIED > DNS Signed Key 3 UNSPECIFIED > X.509 Certificate - Signature 4 > Kerberos Token 6 UNSPECIFIED > Certificate Revocation List (CRL) 7 > Authority Revocation List (ARL) 8 > SPKI Certificate 9 UNSPECIFIED > X.509 Certificate - Attribute 10 > Raw RSA Key 11 > Hash and URL of X.509 certificate 12 > Hash and URL of X.509 bundle 13 > RESERVED to IANA 14 - 200 > PRIVATE USE 201 - 255 Actually the certificate encodings 8 (Authority Revocation List (ARL)) and 10 (X.509 Certificate - Attribute) are not specified in this document at all, so either they should be put as UNSPECIFIED or documentation for them needs to be added (perhaps just sharing type 4 and 7 descriptions). ===Done (as making them unspecified). > o X.509 Certificate - Signature (4) contains a DER encoded X.509 > certificate whose public key is used to validate the sender's AUTH > payload. That certificate can also bve used as part of the chain. I.e. add or used in the validation. to the end of that paragraph. ===Not done. It already says this. > 3.7. Certificate Request Payload > > The Certificate Request Payload, denoted CERTREQ in this memo, > provides a means to request preferred certificates via IKE and can > appear in the IKE_INIT_SA response and/or the IKE_AUTH request. > Certificate Request payloads MAY be included in an exchange when the > sender needs to get the certificate of the receiver. If multiple CAs > are trusted and the cert encoding does not allow a list, then > multiple Certificate Request payloads SHOULD be transmitted. I think the "SHOULD" there could be lowercase should as this is not really a protocol issue. ===Done. > 3.13.1. Traffic Selector I think we should add here text which says that if the TS type is unknown, then the recipient will skip that traffic selector over, and ignore it, so that it will not be returned in the narrowed set (i.e. responder will narrow selection so that the unknown TS type is not part of the narrowed traffic selectors returned to initiator). This allows adding more traffic selector types without breaking things in the future. The current generic text only specifies that processing for unknown payloads, but does not say anything about the subtypes inside the different payloads (like unknown ID types, or unknown TS types). ===Done, but added to 2.9 instead. > 3.14. Encrypted Payload > > The Encrypted Payload, denoted SK{...} or E in this memo, contains > other payloads in encrypted form. The Encrypted Payload, if present > in a message, MUST be the last payload in the message. Often, it is > the only payload in the message. > > The algorithms for encryption and integrity protection are negotiated > during IKE_SA setup, and the keys are computed as specified in > Section 2.14 and Section 2.18. > > This document specifies the cryptographic processing of Encrypted > payloads using a block cipher in CBC mode and an integrity check > algorithm that computes a fixed-length checksum over a variable size > message. The design is modeled after the ESP algorithms described in As we already has document which describes how to use other ciphers in the IKE, we at least put the reference to there, or even incorporate the changes specified in there to this document. Especially as the RFCF 4307 specifies ENCR_AES_CTR as SHOULD for the IKEv2... ===Done. Well, not the way that you wanted. I will send in an errata to RFC 4307 saying that AES_CTR should not have been listed. > 3.15.1. Configuration Attributes ... > o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the > internal network, sometimes called a red node address or private > address and MAY be a private address on the Internet. {{ > Clarif-6.2}} In a request message, the address specified is a > requested address (or a zero-length address if no specific address > is requested). If a specific address is requested, it likely > indicates that a previous connection existed with this address and > the requestor would like to reuse that address. With IPv6, a > requestor MAY supply the low-order address octets it wants to use. > Multiple internal addresses MAY be requested by requesting > multiple internal address attributes. The responder MAY only send > up to the number of addresses requested. The INTERNAL_IP6_ADDRESS > is made up of two fields: the first is a 16-octet IPv6 address, > and the second is a one-octet prefix-length as defined in > [ADDRIPV6]. The requested address is valid until there are no > IKE_SAs between the peers. Perhaps move most of this explination to the 3.15.3 or at least add pointer to there. ===Done (pointer added). Also I think the text "The requested address is valid until there are no IKE_SAs between the peers." is incorrect, it most likely should say "The requested address is valid as long as this IKE SA (or its rekeyed successors) requesting the address is valid." I.e. even if another IKE SA is created between the peers that does not keep the address allocated in another IKE SA alive, unless it is also allocated in that IKE SA. This is especially the case where lets say multi user hosts do per user IKE SAs and want to allocate IP addresses separately for each user. ===Not done. This should be discussed on the mailing list. ... > o INTERNAL_IP6_NBNS - {{ Clarif-6.6 }} NetBIOS is not defined for > IPv6; therefore, INTERNAL_IP6_NBNS is also unspecified and is only > retained for compatibility with RFC 4306. I think there is no point of keeping the "compatibility with RFC 4306" for feature that cannot be used. I would simply remove the whole INTERNAL_IP6_NBNS and mark it RESERVED. ===Not done. This should be discussed on the mailing list. ... > o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- > device protects. This attribute is made up of two fields: the > first being an IP address and the second being a netmask. > Multiple sub-networks MAY be requested. The responder MAY respond > with zero or more sub-network attributes. Add pointer to 3.15.2. ===Done. ... > o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- > device protects. This attribute is made up of two fields: the > first is a 16-octet IPv6 address, and the second is a one-octet > prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY > be requested. The responder MAY respond with zero or more sub- > network attributes. Add pointer to 3.15.2. ===Done. > 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ... > For instance, if there are two subnets, 192.0.1.0/26 and > 192.0.2.0/24, and the client's request contains the following: Again here we use 192.0.1.0/26 address range which is not reserved for examples. Would suggest using 192.0.2.128/26 (192.0.2.128-191) and 192.0.2.0/25 (192.0.2.0-127) to be used instead. ===Not done. > 3.15.4. Address Assignment Failures > > {{ Added this section from Clarif-6.8 }} > > > > > Kaufman, et al. Expires August 28, 2008 [Page 101] > > Internet-Draft IKEv2bis February 2008 > > > If the responder encounters an error while attempting to assign an IP > address to the initiator during the processing of a Configuration > Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. > {{ 3.10.1-36 }} If this error is generated within an IKE_AUTH > exchange, no CHILD_SA will be created. However, there are some more > complex error cases. Add comment there, that the IKE SA is still created even if the initial child sa cannot be created. ===Done. > 3.16. Extensible Authentication Protocol (EAP) Payload ... > {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an > indication of initiator identity in message 3 of the protocol, the > responder should not send EAP Identity requests. The initiator may, > however, respond to such requests if it receives them. This is again bits on the wire protocol change if someone after this does not follow the SHOULD NOT and SHOULD written here before. I think it should be kept as it was before. ===Not done. Disagree about this being bits on the wire because the responder might have sent the request anyway. > 4. Conformance Requirements ... > Every implementation MUST be capable of doing four-message > IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, > one for ESP and/or AH). Implementations MAY be initiate-only or ^^^^^^ Change to "or". ===Done. > 5.1. Traffic selector authorization ... > For example, the PAD might be configured so that authenticated > identity "sgw23.example.com" is allowed to create IPsec SAs for > 192.0.2.0/24, meaning this security gateway is a valid > "representative" for these addresses. Host-to-host IPsec requires > similar entries, linking, for example, "fooserver4.example.com" with > 192.0.1.66/32, meaning this identity a valid "owner" or > "representative" of the address in question. Again using the non example prefix of 192.0.1.66/32. Would be better to use smaller subnets and addresses from example prefix. ===Not done. > As noted in [IPSECARCH], "It is necessary to impose these constraints > on creation of child SAs to prevent an authenticated peer from > spoofing IDs associated with other, legitimate peers." In the > example given above, a correct configuration of the PAD prevents > sgw23 from creating IPsec SAs with address 192.0.1.66, and prevents > fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24. ===Not done. (Assuming you wanted the IP addresses changed.) > Appendix C. Exchanges and Payloads ... > C.1. IKE_SA_INIT Exchange > > request --> [N(COOKIE)], > SA, KE, Ni, > [N(NAT_DETECTION_SOURCE_IP)+, > N(NAT_DETECTION_DESTINATION_IP)], > [V+] > > normal response <-- SA, KE, Nr, > (no cookie) [N(NAT_DETECTION_SOURCE_IP), > N(NAT_DETECTION_DESTINATION_IP)], > [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], > [V+] Add other versions of possible replies here too: cookie request <-- N(COOKIE) [V+] invalid ke payload <-- N(INVALID_KE_PAYLOAD) error [V+] combined cookie <-- N(COOKIE), N(INVALID_KE_PAYLOAD) request and invalid [V+] ke payload error ===Done. > C.2. IKE_AUTH Exchange without EAP > > request --> IDi, [CERT+], > [N(INITIAL_CONTACT)], > [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], > [IDr], > AUTH, > [CP(CFG_REQUEST)], > [N(IPCOMP_SUPPORTED)+], > [N(USE_TRANSPORT_MODE)], > [N(ESP_TFC_PADDING_NOT_SUPPORTED)], > [N(NON_FIRST_FRAGMENTS_ALSO)], > SA, TSi, TSr, > [V+] > > response <-- IDr, [CERT+], > AUTH, > [CP(CFG_REPLY)], > [N(IPCOMP_SUPPORTED)], > [N(USE_TRANSPORT_MODE)], > [N(ESP_TFC_PADDING_NOT_SUPPORTED)], > [N(NON_FIRST_FRAGMENTS_ALSO)], > SA, TSi, TSr, > [N(ADDITIONAL_TS_POSSIBLE)], > [V+] Same here: error in CHILD SA <-- IDr, [CERT+], creation AUTH, N(error) [V+] ===Done. > C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying CHILD_SAs > > request --> [N(REKEY_SA)], > [CP(CFG_REQUEST)], > [N(IPCOMP_SUPPORTED)+], > [N(USE_TRANSPORT_MODE)], > [N(ESP_TFC_PADDING_NOT_SUPPORTED)], > [N(NON_FIRST_FRAGMENTS_ALSO)], > SA, Ni, [KEi], TSi, TSr > > response <-- [CP(CFG_REPLY)], > [N(IPCOMP_SUPPORTED)], > [N(USE_TRANSPORT_MODE)], > [N(ESP_TFC_PADDING_NOT_SUPPORTED)], > [N(NON_FIRST_FRAGMENTS_ALSO)], > SA, Nr, [KEr], TSi, TSr, > [N(ADDITIONAL_TS_POSSIBLE)] And here: error case <-- N(error) invalid ke payload <-- N(INVALID_KE_PAYLOAD) next request with --> [N(REKEY_SA)], new ke payload using [CP(CFG_REQUEST)], group given by [N(IPCOMP_SUPPORTED)+], invalid ke payload [N(USE_TRANSPORT_MODE)], notify [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, Ni, [KEi], TSi, TSr (response would be same as in normal case). ===Done. Well, did the first two. The last is no different than the original request. I suspect you wanted to change something in it; if so, please re-submit. > Appendix D. Changes Between Internet Draft Versions I guess the sections here should mention draft numbers too, as now there is two changes from -00 to -01 draft: ===Done. > D.1. Changes from IKEv2 to draft -00 > D.2. Changes from draft -00 to draft -01 > D.3. Changes from draft -00 to draft -01 > D.4. Changes from draft -01 to draft -02 > Added Clarif-4.4 to the ned of Section 3.3.2. ^^^ Typo. ===Done. > D.5. Changes from draft -02 to draft -03 > PRF_HMAC_TIGER 3 (RFC2104) What is unspecified in tiger, does not the rfc 2104 specify how to use PRF_HMAC_TIGER? ===Not done. The base spec for TIGER is not generally available. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Sep 21 17:14:53 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605403A69E4; Sun, 21 Sep 2008 17:14: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 D595D3A6A29; Sun, 21 Sep 2008 17:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 tagged_above=-999 required=5 tests=[AWL=0.613, 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 W7hXw1VfRwZD; Sun, 21 Sep 2008 17:13:30 -0700 (PDT) Received: from mclniron01-ext.bah.com (mclniron01-ext.bah.com [156.80.1.71]) by core3.amsl.com (Postfix) with ESMTP id F40743A6996; Sun, 21 Sep 2008 17:13:29 -0700 (PDT) x-SBRS: None X-REMOTE-IP: 156.80.7.153 X-IronPort-AV: E=Sophos;i="4.32,443,1217822400"; d="scan'208";a="53202712" Received: from mclnexbh03.resource.ds.bah.com ([156.80.7.153]) by mclniron01-int.bah.com with ESMTP; 21 Sep 2008 20:13:35 -0400 Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.121]) by mclnexbh03.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 21 Sep 2008 20:13:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 21 Sep 2008 20:13:30 -0400 Message-ID: <37BDD2FAF2AEAE459C6C70FDC2892E4E03499E88@MCLNEXVS05.resource.ds.bah.com> In-Reply-To: <48D6A96E.2020403@spawar.navy.mil> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on current RoHC over IPSec draft Thread-Index: AckcJeageewAKh1vT2qbF4yYrsECAwABXW1A References: <48D6A96E.2020403@spawar.navy.mil> From: "Ertekin, Emre [USA]" To: "Robert A. Stangarone Jr." , , "Christou, Christos [USA]" , , X-OriginalArrivalTime: 22 Sep 2008 00:13:35.0216 (UTC) FILETIME=[0DD69700:01C91C48] Cc: stangarr@nkiconsulting.com, Pasi.Eronen@nokia.com, Tero Kivinen Subject: Re: [IPsec] Comments on current RoHC over IPSec draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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, Robert, Thanks for reviewing our drafts, and providing comments. Please find our responses inline: > I have the following comments on the current versions of the RoHC over > IPsec drafts: > > draft-ietf-rohc-hcoipsec-08 - > > This document refers to the use of an Integrity Check Value > (ICV) [section 6.1, Block B] to verify successful decompression of a > ROHC packet. ROHC already provides CRC fields for this function. This has been discussed in significant detail before. Please see Pasi's email below for further clarification: http://www.ietf.org/mail-archive/web/rohc/current/msg05374.html To summarize the discussion, the ROHC CRC may not be good enough to provide the levels of authentication that we need with IPsec. Having said this, I would like to note that a RoHCoIPsec implementation may choose to negotiate a value of "0" in Integrity Algorithms field (i.e., NONE, as defined in the Integrity Algorithm Transform ID registry), and instead implement the ROHC CRC as you suggest. > draft-ietf-rohc-ikev2-extensions-hcoipsec-06 - > > The authors are asserting that the ROHC Channel parameters much be > negotiated, not signaled. A simpler approach would be for the device > which will decompress traffic to signal to the device compressing the > traffic its RoHC abilities. We adopted this framework because we wanted to remain consistent with previous RFCs (e.g., RoHC/PPP defined RFC 3241) which indicates that these parameters are "negotiated". In our case, the initiator sends a Notify Payload with the ROHC parameters that the compressor supports. Based on this Notify payload, the Responder confirms the parameters that are active for the RoHC channel. > For example, from RFC 4995, section 5.1.2: > > LARGE_CIDS - Why is this even sent? The value given for MAX_CID should > allow a device to determine the value of this RoHC Channel parameter. > This parameter should not need to be negotiated, or signaled. Nowhere in the IKEv2 extensions draft do we state that the LARGE_CID parameter is sent. In our draft, we state the following: " Note: The value of LARGE_CIDS will be implicitly determined by this value (i.e. if MAX_CID is <= 15, LARGE_CIDS will be assumed to be 0)." > MAX_CID - This parameter should be signaled by the end which will > decompress the RoHC traffic. Ultimately, the decompressor's context > storage space will limit how many contexts will be used. To support > this > assertion I provide the following MAX_CID cases: > > 1) The compressor has a larger MAX_CID than the decompresor. In this > case the decompressor is the limiting factor on the MAX_CID. The > compressor's MAX_CID will never be reached, and therefore is not > important. > > 2) The compressor and decompressor have the same MAX_CID value. In this > case the compressor's MAX_CID also does not matter because it is equal > to the decompressor's MAX_CID. > > 3) The compressor has a smaller MAX_CID than the decompressor. In this > case the compressor will never have a CID that is equal to the > decompressor's MAX_CID, and therefore the decompressor does not need to > know anything about the compressor's MAX_CID. The compressor will stop > compressing flows once its MAX_CID is reached. Although I agree that the decompressor's context storage space limits how many contexts will be used, I don't think that this is a good approach. In case (3) above, without knowledge of what the compressor can support, a decompressor instance may default to supporting the maximum number of CIDs per SA (2^14-1) -- this means that for every decompressor instance that is established, the implementation may allocate resources (e.g., memory) for 2^14-1 CIDs per decompressor instance (e.g., per SA). This allocation would be wasteful if each compressor only requires a few (e.g., 1-2) CIDs per instance. This is why there is benefit for the decompressor to have some sort of knowledge about the compressor's MAX_CID. > PROFILES - This parameter should be signaled by the end which will > decompress the RoHC traffic. By doing this the end which will compress > the traffic knows what PROFILES may be used for compression. If the > compressor supports PROFILES that the decompressor does not, it will > never be able to use them with that decompressor anyway. If the > decompressor supports PROFILES the compressor does not, the compressor > will never use them either. I'm not sure if this is a good approach either. Take, for example, the following case: compressor only supports Profiles A,B,C, decompressor only supports Profiles D,E. Upon creation of the RoHC-enabled SA, the decompressor instance will be active, with profiles D,E. But the compressor neither supports D, or E. This is again a wasteful instantiation of a decompresor instance at the IPsec implementation. This is why we think there is benefit to having the decompressor know about the compressor's PROFILES (and in general, the compressor's channel parameters). > FEEBACK_FOR - This should be signaled by the end doing decompression > (and optionally sending feedback) to the end doing the decompression to > indicate for which flow the feedback is sent. This is in agreement with > the RFC. We are not negotiating this parameter. In the IKEv2 draft, we state the following: " When a pair of SAs are created (one in each direction), the RoHC channel parameter FEEDBACK_FOR is set implicitly to the other SA of the pair (i.e. the SA pointing in the reverse direction)." > MRRU - This parameter is unnecessary. The external interface of the > IPSec device should be able to determine the MTU of its link and > fragment as needed/necessary. None of the RoHCv2 PROFILES (found in RFC > 5225) allow for the use of MRRU, so why use it? Fair comment. We'll remove this parameter. > The IKEv2 Notify Message Type [section 2.1] should only be sent once by > each end during the IKE_AUTH and CREATE_CHILD_SA exchanges signaling > the > RoHC parameters. Correct. > The standard Notify Payload header fields appear to be the same as > those > specified for IKEv2, but the Next Payload field is missing for some > reason? Why? The field is not missing -- we didn't describe the field since it is consistent with the description provided in RFC 4306. To avoid confusion, we'll include an illustration of the Notify header in the next revision of the draft, and a description of all Notify header fields. > The fields specified to be included in the Notification Data field of > the Notify Payload are as follows: > > MAX_CID > > MRRU - Why include MRRU field when ROHCv2 Profiles prohibit the use of > segmentation (which is why you specify MRRU)? See MRRU comment above. > MAX_HEADER - Only used for Profiles found in RFC 2507 (IPCOMP). None of > the ROHCv2 Profiles utilize this value, why include it? Please see RFC 3241 for the reasoning behind including the MAX_HEADER field. > PROFILE_LENGTH - Why do you need 16 bits to express the number of > Profiles when the IETF has only allocated less than 20 Profile > Identifiers? You can only use one variant of > any > Profile on a ROHC > Channel per RFC 4995, section 5.1.2 (Per-Channel Parameters). Fair comment -- we can reduce this to 1 byte. > PROFILES > > INTEGRITY ALGORITHMS - Why have Integrity Algorithms to "ensure the > integrity of the decompressed packets" when you have ROHC CRCs > to verify the decompression of packets? Again, please see previous discussions on this: http://www.ietf.org/mail-archive/web/rohc/current/msg05374.html > draft-ietf-rohc-ipsec-extensions-hcoipsec-02 - > > This document specifies the inclusion of ROHC Channel parameters into > the SPD, including: MAX_CID, PROFILES, MRRU, MAX_HEADER. As ROHCv2 > Profiles cannot use ROHC Segmentation, why have a MRRU parameter? Negotiation of the MRRU parameter will be removed on the next revision of the draft. > Why > include the MAX_HEADER parameter that is not used by ROHCv2 (nor RFC > 3095) profiles? Please see our response above regarding MAX_HEADER. > An argument is made in section 4 that the integrity check algorithm > provides protection against the "...possibility of an invalidly > decompressed packet to be forwarded ... into a protected domain." > ROHCv2 > Profiles already provide CRCs to validate or verify header > decompression operations, and the ESP header provides an Authentication > Data field which contains an ICV that is necessary to authenticate the > packet. Again, please see the previous mailer discussions on why we need the integrity algorithm. Thanks, Emre _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 22 06:46:26 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04A783A6AB3; Mon, 22 Sep 2008 06:46: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 6CEDE3A6A4A for ; Mon, 22 Sep 2008 06:46:23 -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 JhT+O-hFZ++4 for ; Mon, 22 Sep 2008 06:46:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 63D483A6963 for ; Mon, 22 Sep 2008 06:46:04 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8MDjsVX025296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 16:45:54 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8MDjsmS002033; Mon, 22 Sep 2008 16:45:54 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18647.41362.197406.338097@fireball.kivinen.iki.fi> Date: Mon, 22 Sep 2008 16:45:54 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <7E894C6E-2F44-4C52-B893-B066B4DE3FC8@checkpoint.com> References: <18643.41900.851013.866168@fireball.kivinen.iki.fi> <7E894C6E-2F44-4C52-B893-B066B4DE3FC8@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 11 min X-Total-Time: 10 min Cc: ipsec@ietf.org, Stephen Bevan Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > That's a good way, but then if your email client polls the IMAP server > every 5 minutes, you'll only get a burst of activity every 5 minutes. > Even a gateway running on a commodity PC has time to reboot in 5 > minutes, and DPD will take more time than necessary (30 seconds in > your case IIRC) If you are only polling email every 5 minutes, it does not matter if one of them is delayed by 30-60 seconds more, because the other has been rebooted. It is not like the user would really notice whether the announcement of new email came exactly 5 minutes later or 6 minutes later... If the other end is up and running it will send invalid spi notifications which can be used by the client to reduce the timeout used for the DPD (i.e. instead of retransmitting dozen times during 5 minutes when no reply is received, you only retransmit half a dozen times during 60 seconds). Usually things which happens once every 5 minutes or so, are not really time critical. > We actually sync IKE SAs between gateways, although this is getting > more difficult, because IKEv2 requires the message counters to be > synched. Yes. Fortunately the IKEv2 traffic is not high volume traffic, thus that does not require too much bandwidth. > My co-authors tell me that very often, their gateways are > deployed with no back-channel sync. We are hearing more people who > want a physical separation between the gateways (like putting them in > different parts of town) and in that case synching becomes much more > difficult. Putting them on different parts of the town requires quite a lot from the other infrastructure, as it requires them to still keep the same IP-address, and use the routing protocols or similar to reroute packets from one site to another when the first site's VPN gateway goes down. I think this is again different situation than secure crash recovery (i.e. this is failover case, where the solutions are usually bit different). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 22 06:58:39 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC453A6A2B; Mon, 22 Sep 2008 06:58:39 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA9073A69DC for ; Mon, 22 Sep 2008 06:58:38 -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 MrRNBiOE44Jh for ; Mon, 22 Sep 2008 06:58:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id E6A303A677C for ; Mon, 22 Sep 2008 06:58:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8MDwFTf013861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 16:58:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8MDwEbV012760; Mon, 22 Sep 2008 16:58:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18647.42102.174395.432345@fireball.kivinen.iki.fi> Date: Mon, 22 Sep 2008 16:58:14 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <18643.41900.851013.866168@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 12 min X-Total-Time: 11 min Cc: ipsec@ietf.org, Stephen Bevan , Yoav Nir Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Scott C Moonen writes: > But the sentences immediately following this in the RFC suggest that a > liveness test should be done even when there is dead air, i.e., without > regard to whether we have been sending traffic. Yes. We do both. > Is it the intent of the RFC to do liveness checks only when there is > unreciprocated outbound traffic? No. The RFC leaves that completely to the implementations, but gives two recommendations when it would be useful to do, i.e. when the traffic has been unidirectional or when there has not been any traffic for long time. > Should the RFC allow or forbid liveness checks more broadly in the > "dead air" case where there is no traffic flowing in either > direction? There may be some value in proactively discovering the > peer's deadness in the dead-air case, but Yoav's concerns about > overutilized connections also have merit. All those depends so much about the scenario and situation where IKEv2 is used, thus those are better to leave in the implementations to take care of (or to the configuration of the implementation). In some scenarios it might be better to disable DPD completely. In some cases you want to do it very quickly and often. In mobile device cases you most likely want to do it quite quickly when the traffic changes to have only outbound traffic, but after successful DPD you should not another until you have new evidence that situation has changed, just to save battery life and link resources. > If the RFC takes an agnostic approach to the dead-air case, we may > still want to recommend that if an implementation allows for > dead-air liveness checks, it should be configurable on a > per-PAD-entry basis. I do not think the RFC needs to mandate anything like that. Some implementations are not really meant for generic use, thus they can have very limited configurability, but their implementations might have lots of hard coded support for the scenario they are used in (for example they might disable DPDs completely if they know that the phone is out of coverage from the network, as doing DPD in that situation would simply waste resources by removing the SAs even when the other end might still be up and working after the network coverage is regained etc). > Or perhaps the RFC could recommend a more conservative approach to > the dead-air case, such as backing off the interval between dead-air > liveness checks with each successful iteration. Backing off is good option in certain scenarios. It might not be good option in some other situations. I think the RFC should leave this kind of things to the implementations. The RFC should document the protocol so that both ends can implement it correctly and two implementations can talk to each other. It should not try to mandate things how implementations should use those protocols. It can give hints what kind of implementations would be useful in what kind of scenarios, but even those might be better to leave to those documents describing the scenarios (i.e. some 3GPP document might document what kind of DPD behavior works best when using IKEv2 to protect something there, as they know which behavior might be best in that scenario). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 22 07:06:15 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19AF33A6A78; Mon, 22 Sep 2008 07:06:15 -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 6DB0D3A6A78 for ; Mon, 22 Sep 2008 07:06: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 b+NYblqUa61p for ; Mon, 22 Sep 2008 07:06:12 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id D62F328C0D7 for ; Mon, 22 Sep 2008 07:06:04 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8ME63Dd015933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Sep 2008 17:06:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8ME62oM001516; Mon, 22 Sep 2008 17:06:02 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18647.42570.766912.651368@fireball.kivinen.iki.fi> Date: Mon, 22 Sep 2008 17:06:02 +0300 From: Tero Kivinen To: "Hui Deng" In-Reply-To: <1d38a3350809200459m3f9d0216k30377fb443fb51f6@mail.gmail.com> References: <18642.12494.564286.298618@fireball.kivinen.iki.fi> <1d38a3350809200459m3f9d0216k30377fb443fb51f6@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: Christian.Kaas-Petersen@tietoenator.com, ipsec@ietf.org Subject: Re: [IPsec] Use of IKE to obtain address of home agent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Hui Deng writes: > ==> I can't imagine the issue if we include two payloads even without an > transaction ID here. could you help to elaborate more, bascially, I assume > there are consecutively ordered. There is nothing in the current documents that says that the reply payloads inside the reply packet must be in same order the request payloads were in the request packet. Thus complient implementation would be allowed to reorder them if they want to. Thus the initiator receiving the reply cannot know which reply payloads was reply to which request payload. Complient recipient can also remove some of the requested attributes, and add new ones, so detecting things from the attributes might not be possible. We could add such text to IKEv2bis, but I think it is better not to add multiple configuration payloads to one packet. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 22 10:08:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A9B63A6C05; Mon, 22 Sep 2008 10:08:23 -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 6584C3A691F for ; Thu, 18 Sep 2008 20:52:10 -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 kaVBlx1zzd+p for ; Thu, 18 Sep 2008 20:52:09 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by core3.amsl.com (Postfix) with ESMTP id 7AA2E3A689F for ; Thu, 18 Sep 2008 20:52:09 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so211617rvf.49 for ; Thu, 18 Sep 2008 20:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=QRYuERo0G6LocyJD52M2YYSM0lwftaZfwSVvD/dgCHo=; b=ldh4bBCMaYOy8PPkrdBFGBQkMYbkyNu+/Juc8KJVEkURV7ZTCGstdNx/YR8OiAPiCc 7bKhSdL1ZqbmXaP2Adlrl1Is2s/djf6Lfa+jNU3tdbghPENbpWRpCMpVgmgc3bI4ZLDz S0W3T0pjvwIlxR3MYZPMiTD/6kJ9hYF8PzXlw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=vdLLIJo4kf6UOEiY7yekUe3/mr+cCuMFsB1zAE4dB4sS/r248TiEZIXyTgf9QNBYzQ huVn7vqA78PsINwIqSy1qCzXlKeQm8MaV8n40D7VtGVRdyqPTekjdk6lPS54P0cmPp92 F9DM/6yNamlRbSGbXzSNvqY5i03wcnpA/Cu9M= Received: by 10.115.73.20 with SMTP id a20mr4923409wal.32.1221796342453; Thu, 18 Sep 2008 20:52:22 -0700 (PDT) Received: by 10.114.234.17 with HTTP; Thu, 18 Sep 2008 20:52:22 -0700 (PDT) Message-ID: Date: Thu, 18 Sep 2008 20:52:22 -0700 From: "Stephen Bevan" To: ynir@checkpoint.com MIME-Version: 1.0 Content-Disposition: inline X-Mailman-Approved-At: Mon, 22 Sep 2008 10:08:22 -0700 Cc: ipsec@ietf.org Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > I sent out this email about a month ago, and the response was, well, > underwhelming. > [snip] > So we're asking the participants of this WG again for their opinion > about the two (well, three if you include birth certificates) options > for solving the de-synchronization problem. The drafts for QCD and SIR both assume that the crash, reboot and subsequent INVALID_SPI will be generated less time than DPD can detect failure. Both point at RFC 4306 section 2 suggests DPD should run for several minutes to indicate the results that can be expected from using DPD. I did not see either mention what typical/expected crash/reboot times are. The commodity PC hardware I'm typing this message on will spend at about 30 seconds in the BIOS before it even starts booting the kernel and it takes a minute or more before the IKE daemon is up and ready to send out an INVALID_SPI. Thus with either protocol the best I could hope for on this hardware would be 1 minute of traffic loss. Two ways of bringing down that time are :- 1. Get hardware the boots an order of magnitude faster. 2. Use an IKE daemon that allows me to configure the DPD settings to whatever I deem correct for my toplogy. I'd dearly love 1 but where do I get it and how much more does it cost? Thus I'm left looking at 2 which is a quality of implementation issue that requires no protocol changes. There may be other scenarios where the protocols do better than DPD with configurable timeouts in which case I suggest the introductory sections of the drafts be updated to make the case for those scenarios _much_ more strongly in order to clearly indicate why DPD is not sufficient and a new protocol is required. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 22 10:08:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D20E03A6BAB; Mon, 22 Sep 2008 10:08:23 -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 8A8723A6B37 for ; Fri, 19 Sep 2008 08:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-1.999, BAYES_00=-2.599, 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 MkKUwuUk50+1 for ; Fri, 19 Sep 2008 08:30:40 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 60C073A6B43 for ; Fri, 19 Sep 2008 08:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=gerardog@qualcomm.com; q=dns/txt; s=qcdkim; t=1221838256; x=1253374256; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Giaretta,=20Gerardo"=20 |To:=20Julien=20Laganier=20,=0D=0A=20=20=20=20=20=20=20=20"ipsec@ietf.org"=0D =0A=09|CC:=20Tero=20Kivinen=20,=0D=0A=20=20=20=20=20=20=20=20"Christian.Kaas-Peter sen@tietoenator.com"=0D=0A=09|Date:=20Fri,=2019=20Sep=202008=2008:30:54 =20-0700|Subject:=20RE:=20[IPsec]=20=20Use=20of=20IKE=20t o=20obtain=20address=20of=20home=20agent|Thread-Topic:=20 [IPsec]=20=20Use=20of=20IKE=20to=20obtain=20address=20of =20home=20agent|Thread-Index:=20AckaQV/oxfblUGuWSLujHTfTI FIk5AAKo27w|Message-ID:=20<057632CE4CE10D45A1A3D6D19206C3 A39CD979F5@NASANEXMB08.na.qualcomm.com>|References:=20=0D=0A=20<18642.12494.564286.298618@fireball.kivinen. iki.fi>=0D=0A=20<200809181317.42653.julien.laganier.IETF@ googlemail.com>|In-Reply-To:=20<200809181317.42653.julien .laganier.IETF@googlemail.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 200,2160,5387"=3B=20a=3D"8195339"; bh=BEa4yAUfC/bX8sSGA1BjDTGmdkm87SaoNFTRQK12/Yg=; b=oAs7IS00IoyKErDsvjDsAg6m4uinmZESZTDDagYyNXaRxpgdPS2Z1AZK aid4yqjloAcapExkefkqXhOXrK+eqlOTwMNFz6GKamjWnDz+i+rJ9qT+w opRvqUZRkxaqp25nklvO5iZXJcPW4fbW1khJxoHRv0LAyS5yQ2kfsU+Fk o=; X-IronPort-AV: E=McAfee;i="5200,2160,5387"; a="8195339" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Sep 2008 08:30:55 -0700 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m8JFUt5j029489 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 Sep 2008 08:30:55 -0700 Received: from nasanexhc02.na.qualcomm.com (nasanexhc02.na.qualcomm.com [172.30.33.23]) by hamtaro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m8JFUssj028502 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 19 Sep 2008 08:30:55 -0700 (PDT) Received: from nasanexhub02.na.qualcomm.com (10.46.143.120) by nasanexhc02.na.qualcomm.com (172.30.33.23) with Microsoft SMTP Server (TLS) id 8.1.291.1; Fri, 19 Sep 2008 08:30:54 -0700 Received: from NASANEXMB08.na.qualcomm.com ([192.168.73.131]) by nasanexhub02.na.qualcomm.com ([10.46.143.120]) with mapi; Fri, 19 Sep 2008 08:30:53 -0700 From: "Giaretta, Gerardo" To: Julien Laganier , "ipsec@ietf.org" Date: Fri, 19 Sep 2008 08:30:54 -0700 Thread-Topic: [IPsec] Use of IKE to obtain address of home agent Thread-Index: AckaQV/oxfblUGuWSLujHTfTIFIk5AAKo27w Message-ID: <057632CE4CE10D45A1A3D6D19206C3A39CD979F5@NASANEXMB08.na.qualcomm.com> References: <18642.12494.564286.298618@fireball.kivinen.iki.fi> <200809181317.42653.julien.laganier.IETF@googlemail.com> In-Reply-To: <200809181317.42653.julien.laganier.IETF@googlemail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 22 Sep 2008 10:08:22 -0700 Cc: "Christian.Kaas-Petersen@tietoenator.com" , Tero Kivinen Subject: Re: [IPsec] Use of IKE to obtain address of home agent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Julien, all, See a comment inline. > -----Original Message----- > From: Julien Laganier [mailto:julien.laganier.IETF@googlemail.com] > Sent: Thursday, September 18, 2008 4:18 AM > To: ipsec@ietf.org > Cc: Tero Kivinen; Christian.Kaas-Petersen@tietoenator.com > Subject: Re: [IPsec] Use of IKE to obtain address of home agent > > Christian and Tero, > > Quick follow-up on this topic: > > On Thursday 18 September 2008, Tero Kivinen wrote: > > Christian.Kaas-Petersen@tietoenator.com writes: > > > 3GPP has in document TS 24.302 (can be retrieved from > > > http://www.3gpp.org/ftp/Specs/html-info/24302.htm), section 7.2.2, > > > specified a use of IKE, where IKE sets up a secure tunnel to > > > a security gateway, denoted ePDG, and expects this security gateway > > > to return both an address to the mobile node, which normally > > > will be a care-of address, and the address(es) of the home agent. > > > The said document thinks this possible by having two Configuration > > > Payloads. IKEv2bis, and previous documents, only indicated one > > > Configuration Payload to be present, and with the recent discussion > > > in mind where the order of the payloads in an IKE packet should > > > not matter, then having two Configuration Payloads is not a viable > > > approach. It would be better to introduce two new configuration > > > attributes, for example named INTERNAL_IP4_HA and INTERNAL_IP6_HA. > > > > Yes, it would be better to have 2 new configuration options. The > > section 7.2.2. does not actually specify which configuration > > attribute type is used to negotiate Home Agent addresses. > > > > Including more than one configuration payloads in the exchange, would > > be bad idea, as the configuration payloads do not hve any kind of > > transaction id or similar, meaning there is no way to know which > > CFG_REPLY matches which CFG_REQUEST if there is multiple > > configuration payloads (of same CFG TYPE) in same exchange. > > I have a different reading of 3GPP TS 24.302; I think there's a little > mistake in the text and what it want to say is that "the UE may also > request the address(es) of a Home Agent for DSMIPv6 related signaling, > by including a corresponding _attribute_ in the CFG_REQUEST > configuration payload." > > That would be in-line with the Editor's note that follows which > state "it is FFS which type of attribute (private or assigned by IANA) > is used in the configuration payload. > Julien's understanding is correct. In 3GPP CT1 we have left still open and there was no discussion. There was some discussion of having a vendor specific attribute for this. Note that this is optional as the MN can always discover the HA via DNS > I see absolutely no reason to use two CFG_REQUEST be needed... > > Thus TS 24.302 has to be fixed. > > > Another option is to use the INTERNAL_IP{4,6}_DHCP attribute in IKEv2 > > and then get the home agent address from the DHCP server. > > The alternative of getting the HA information via DHCP is already > covered as part of 3GPP TS 24.303 "Mobility Management based on > Dual-Stack Mobile IPv6", amongst other alternatives (DNS, and GTP > Protocol Configuration Options.) > TS 23.402 (the corresponding stage2) mandates the assignment of the HA address within IKEv2 signaling. DHCP-based HA assignment is specified but for another scenario. Gerardo > --julien _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 22 10:08:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C8343A6C45; Mon, 22 Sep 2008 10:08:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6058E3A67DF for ; Fri, 19 Sep 2008 12:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 ufZ15qdFdSwr for ; Fri, 19 Sep 2008 12:40:39 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id B0F7B3A69EF for ; Fri, 19 Sep 2008 12:40:39 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k34so376918wah.25 for ; Fri, 19 Sep 2008 12:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=jYstMUOdO1110RyKX4D2Bd9G49MGa+vt5Y3AJ5x6Uik=; b=YKIRf7BPNCH3V2p5e2IYE8Qq/q/Kh6SOCKjQF4U+5BPFFIbjdNa1+Vt+wIbeM67NAE BcAZENV5anCuYWJVGdi2IUm7I/GBQoA4Ti1mBeElFNGHiMBI03npgi9KRyWEJBu+qeWn Mh3hgjcRxzq30lOod5MPKYiEcxpWBqelXV6ZY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=md1CP3+tNoZPQo9WB2AmCq5ss+dGcpsbnFBfZA2ZRXCtomq2LKpHA0+YxdWx4dm/5E Wt/s09RIIRP5TcAsnC3hgxul2c+Qlwlz9hozZ4O09s8qYQf9DK6yk0R8AsROJlrNPJ1D LN4b5/l+qbPXezh+X/jIzB39BToyvHZ/j4cmo= Received: by 10.114.57.15 with SMTP id f15mr652634waa.116.1221853253599; Fri, 19 Sep 2008 12:40:53 -0700 (PDT) Received: by 10.114.234.17 with HTTP; Fri, 19 Sep 2008 12:40:53 -0700 (PDT) Message-ID: Date: Fri, 19 Sep 2008 12:40:53 -0700 From: "Stephen Bevan" To: "Scott C Moonen" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <18643.41900.851013.866168@fireball.kivinen.iki.fi> X-Mailman-Approved-At: Mon, 22 Sep 2008 10:08:22 -0700 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Yoav Nir , Tero Kivinen Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Fri, Sep 19, 2008 at 11:56 AM, Scott C Moonen wrote: > Is it the intent of the RFC to do liveness checks only when there is > unreciprocated outbound traffic? Should the RFC allow or forbid liveness > checks more broadly in the "dead air" case where there is no traffic flowing > in either direction? There may be some value in proactively discovering the > peer's deadness in the dead-air case, but Yoav's concerns about overutilized > connections also have merit. If a user wants to detect of failure by sending a DPD probe every X seconds (regardless of traffic or not) and failing over to a different gateway if there is no response after Y tries then the user should be able to set X and Y to whatever values they are comfortable with. If the RFC is going to attempt to place restrictions on that capability for compliant systems then it needs to offer an alternative to the same problem. The Secure Crash Detection is not such an alternative since it cannot help in the situation where the problem is the failure of an intermediate node or a NIC such that the ESP never makes it to the peer IPsec host. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 22 10:08:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC8B3A6C53; Mon, 22 Sep 2008 10:08:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF21A3A6B28 for ; Fri, 19 Sep 2008 13:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, J_CHICKENPOX_35=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 xgHT0w-qslBS for ; Fri, 19 Sep 2008 13:04:33 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id EBFB13A6816 for ; Fri, 19 Sep 2008 13:04:32 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so684263wfd.31 for ; Fri, 19 Sep 2008 13:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=f2o8FWFsUjuVGvweHIW7ZrIfCMrPv0Fe0WO5DqiD/TA=; b=XaourkuHaqrKsmFLfqSif2Uvu3SMz6wy/7jh/8qTW1K6ANjaoiQ82kfV6vJSX2nNRI yPh1BYd1eRZ93L8AMIM01fcmQG2rFh2rdUXQ3NG4OMIogSL+gu6K+BPK/ivxOEM1/Sbm ElwR0/uht6CBCxNDcv+y21FlgnVh3t3Ek0Kgg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ATBdXpt4IfHTPJBtqIDJp5KSpSrmLn/OwqmVHJZp+XJAZHcVGVw/kr5h2USgGlDYzy k9MDxw2tKD/4+q3B0Ax6XTsbc6G+41eGQhoqsb5eTEdN0ZnGxu9d44snbHLWLVohVOb1 dhluIC1J8ZRiw3PhwmCVVuGIf+j8EA/jplHrc= Received: by 10.114.179.1 with SMTP id b1mr723781waf.1.1221854688186; Fri, 19 Sep 2008 13:04:48 -0700 (PDT) Received: by 10.114.234.17 with HTTP; Fri, 19 Sep 2008 13:04:48 -0700 (PDT) Message-ID: Date: Fri, 19 Sep 2008 13:04:48 -0700 From: "Stephen Bevan" To: "Yoav Nir" In-Reply-To: <7E894C6E-2F44-4C52-B893-B066B4DE3FC8@checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline References: <18643.41900.851013.866168@fireball.kivinen.iki.fi> <7E894C6E-2F44-4C52-B893-B066B4DE3FC8@checkpoint.com> X-Mailman-Approved-At: Mon, 22 Sep 2008 10:08:22 -0700 Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Fri, Sep 19, 2008 at 9:53 AM, Yoav Nir wrote: > That's a good way, but then if your email client polls the IMAP server every > 5 minutes, you'll only get a burst of activity every 5 minutes. Even a > gateway running on a commodity PC has time to reboot in 5 minutes, and DPD > will take more time than necessary (30 seconds in your case IIRC) If the poll is only being done every 5 minutes then why would the user care that the failover took 30 seconds or even a minute? That is not to say a user might not care but any argument in this direction needs to be clear about what the user's expectations are for their topology. > We actually sync IKE SAs between gateways, although this is getting more > difficult, because IKEv2 requires the message counters to be synched. My > co-authors tell me that very often, their gateways are deployed with no > back-channel sync. We are hearing more people who want a physical separation > between the gateways (like putting them in different parts of town) and in > that case synching becomes much more difficult. If the thrust of the draft is about simplifying failover then I think it needs to explicitly address the pros and cons of synching IKE&IPsec SAs and critically whether this analysis is altered if one assumes that the IPsec host is also a satefull firewall. If it is a firewall I would expect it to be syncing regardless of IKE/IPsec and thus it is not a matter of sync or no synch, but rather of what and how much is being synched. I realize that stateful firewalling is outside the scope of IKE/IPsec and so in abstract is irrelevant. However, for those vendors that do combine IKE/IPsec/firewall then the usefulness of this protocol is going to be judged in this context. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 22 10:08:25 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201923A6C70; Mon, 22 Sep 2008 10:08:25 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E85E63A6BF3; Sun, 21 Sep 2008 13:08:50 -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 jnsLRRgcdznP; Sun, 21 Sep 2008 13:08:49 -0700 (PDT) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id 2C2683A67E2; Sun, 21 Sep 2008 13:08:49 -0700 (PDT) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao106.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20080921200902.GGPU8615.fed1rmmtao106.cox.net@fed1rmimpo01.cox.net>; Sun, 21 Sep 2008 16:09:02 -0400 Received: from localhost.localdomain ([70.181.130.184]) by fed1rmimpo01.cox.net with bizsmtp id HY911a00C3yrMdA03Y92RZ; Sun, 21 Sep 2008 16:09:03 -0400 X-Authority-Analysis: v=1.0 c=1 a=MSY2I4sHyF4A:10 a=LSkncEy7-U4A:10 a=48vgC7mUAAAA:8 a=8trJ58rFvmhiPR8WvsEA:9 a=J8_XVmOgLdAbaS8yL_MA:7 a=geqoUJJlGf4zLiqLoTDRxr_neYEA:4 a=LXqhN_b7XfkA:10 a=lZB815dzVvQA:10 a=kjO27gckG74A:10 a=iNuvWefPPzUA:10 a=ACBgD4iW9t8A:10 a=b8hG5vVbyAkA:10 X-CM-Score: 0.00 Message-ID: <48D6A96E.2020403@spawar.navy.mil> Date: Sun, 21 Sep 2008 13:07:10 -0700 From: "Robert A. Stangarone Jr." User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: rohc@ietf.org, christou_chris@bah.com, ertekin_emre@bah.com, ipsec@ietf.org, rohc-owner@ietf.org References: In-Reply-To: X-Mailman-Approved-At: Mon, 22 Sep 2008 10:08:22 -0700 Cc: stangarr@nkiconsulting.com Subject: [IPsec] Comments on current RoHC over IPSec draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hello Author and working group, I have the following comments on the current versions of the RoHC over IPsec drafts: draft-ietf-rohc-hcoipsec-08 - This document refers to the use of an Integrity Check Value (ICV) [section 6.1, Block B] to verify successful decompression of a ROHC packet. ROHC already provides CRC fields for this function. draft-ietf-rohc-ikev2-extensions-hcoipsec-06 - The authors are asserting that the ROHC Channel parameters much be negotiated, not signaled. A simpler approach would be for the device which will decompress traffic to signal to the device compressing the traffic its RoHC abilities. For example, from RFC 4995, section 5.1.2: LARGE_CIDS - Why is this even sent? The value given for MAX_CID should allow a device to determine the value of this RoHC Channel parameter. This parameter should not need to be negotiated, or signaled. MAX_CID - This parameter should be signaled by the end which will decompress the RoHC traffic. Ultimately, the decompressor's context storage space will limit how many contexts will be used. To support this assertion I provide the following MAX_CID cases: 1) The compressor has a larger MAX_CID than the decompresor. In this case the decompressor is the limiting factor on the MAX_CID. The compressor's MAX_CID will never be reached, and therefore is not important. 2) The compressor and decompressor have the same MAX_CID value. In this case the compressor's MAX_CID also does not matter because it is equal to the decompressor's MAX_CID. 3) The compressor has a smaller MAX_CID than the decompressor. In this case the compressor will never have a CID that is equal to the decompressor's MAX_CID, and therefore the decompressor does not need to know anything about the compressor's MAX_CID. The compressor will stop compressing flows once its MAX_CID is reached. PROFILES - This parameter should be signaled by the end which will decompress the RoHC traffic. By doing this the end which will compress the traffic knows what PROFILES may be used for compression. If the compressor supports PROFILES that the decompressor does not, it will never be able to use them with that decompressor anyway. If the decompressor supports PROFILES the compressor does not, the compressor will never use them either. FEEBACK_FOR - This should be signaled by the end doing decompression (and optionally sending feedback) to the end doing the decompression to indicate for which flow the feedback is sent. This is in agreement with the RFC. MRRU - This parameter is unnecessary. The external interface of the IPSec device should be able to determine the MTU of its link and fragment as needed/necessary. None of the RoHCv2 PROFILES (found in RFC 5225) allow for the use of MRRU, so why use it? The IKEv2 Notify Message Type [section 2.1] should only be sent once by each end during the IKE_AUTH and CREATE_CHILD_SA exchanges signaling the RoHC parameters. The standard Notify Payload header fields appear to be the same as those specified for IKEv2, but the Next Payload field is missing for some reason? Why? The fields specified to be included in the Notification Data field of the Notify Payload are as follows: MAX_CID MRRU - Why include MRRU field when ROHCv2 Profiles prohibit the use of segmentation (which is why you specify MRRU)? See MRRU comment above. MAX_HEADER - Only used for Profiles found in RFC 2507 (IPCOMP). None of the ROHCv2 Profiles utilize this value, why include it? PROFILE_LENGTH - Why do you need 16 bits to express the number of Profiles when the IETF has only allocated less than 20 Profile Identifiers? You can only use one variant of any Profile on a ROHC Channel per RFC 4995, section 5.1.2 (Per-Channel Parameters). PROFILES INTEGRITY ALGORITHMS - Why have Integrity Algorithms to "ensure the integrity of the decompressed packets" when you have ROHC CRCs to verify the decompression of packets? draft-ietf-rohc-ipsec-extensions-hcoipsec-02 - This document specifies the inclusion of ROHC Channel parameters into the SPD, including: MAX_CID, PROFILES, MRRU, MAX_HEADER. As ROHCv2 Profiles cannot use ROHC Segmentation, why have a MRRU parameter? Why include the MAX_HEADER parameter that is not used by ROHCv2 (nor RFC 3095) profiles? The document also specifies the inclusion of Integrity Algorithms into the SPD. See comment above on why these values don't appear to be useful. The SAD parameters specified include those specified for the SPD above, and also include the FEEDBACK_FOR parameter. The HAIPE IS draft spec and the IETF draft match on their approach on this parameter in both manual and dynamic SA creation cases. An argument is made in section 4 that the integrity check algorithm provides protection against the "...possibility of an invalidly decompressed packet to be forwarded ... into a protected domain." ROHCv2 Profiles already provide CRCs to validate or verify header decompression operations, and the ESP header provides an Authentication Data field which contains an ICV that is necessary to authenticate the packet. rohc-request@ietf.org wrote: > Send Rohc mailing list submissions to > rohc@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/rohc > or, via email, send a message with subject or body 'help' to > rohc-request@ietf.org > > You can reach the person managing the list at > rohc-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Rohc digest..." > > > Today's Topics: > > 1. Re: Review of the RoHC over IPsec drafts (Ertekin, Emre [USA]) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 14 Sep 2008 23:40:53 -0400 > From: "Ertekin, Emre [USA]" > Subject: Re: [rohc] Review of the RoHC over IPsec drafts > To: "Yoav Nir" , "Christou, Christos [USA]" > , > Cc: ipsec@ietf.org, rohc@ietf.org, Yaron Sheffer > > Message-ID: > <37BDD2FAF2AEAE459C6C70FDC2892E4E03457938@MCLNEXVS05.resource.ds.bah.com> > > Content-Type: text/plain; charset="us-ascii" > > Hi, Yoav, > > Thanks for your comments and review of our drafts. Please find our > responses below. > >> The three drafts are: >> >> * draft-ietf-rohc-hcoipsec - integration of RoHC over IPsec SAs >> * draft-ietf-rohc-ikev2-extensions-hcoipsec - IKEv2 extensions to >> negotiate RoHC over IPsec >> * draft-ietf-rohc-ipsec-extensions-hcoipsec - IPsec extenstions >> >> >> >> Overall the drafts drafts seem good, and in my opinion could offer a >> substantial benefit for IPsec tunnels, especially where the bandwidth > to >> one or both endpoints is constrained. Here's my comments. > > Thanks! > >> * The IKE & IPsec drafts talk about the use of integrity > algorithms to >> verify that decompression was successful. According to section 2.1 of > the >> IKEv2 draft, these algorithms are the same algorithms (with associated >> keys) as those used in IPsec. I can't figure out why you would want > this. > > The reason for this additional integrity-check is to mitigate scenarios > where intentional (severe) packet reordering or packet loss in the > unprotected network can cause the decompressor to invalidly decompress > packet headers (incorrectly reconstruct fields of a packet header), and > forward them into the protected domain. > > To mitigate this, we add the additional integrity algorithm to verify > that the decompression operation is successful. > > Note that since we are adding an additional ICV, the overall efficiency > gain of header compression is reduced. It may be desired not to > negotiate this additional RoHC integrity algorithm for the RoHC-enabled > SA, but this comes with the risk that compressed headers may be > invalidly decompressed and forwarded into the protected domain. > >> The entire packet, compressed header and data included, is already >> integrity protected by IPsec. An attacker can't flip any bits because > of >> the ESP ICV, so the RoHC ICV is simply there to detect decompression >> errors. I don't see why we need to exceed the recommendation in RFC > 4995 >> to use CRC. Even if you have decided that you want to upgrade error- >> detection ICV to a cryptographically strong one, HMAC doesn't offer > any >> benefit that I can see - you could use straight MD5 or SHA-1 without > any >> key, but I still don't see why CRC is not good enough. > > I think that Pasi responded to this in his email. We want to be able to > ensure (potentially to the level of the cryptographic strength > negotiated for IPsec) the integrity of all bits in the decompressed > header. > > Note, however, that the values negotiated for the integrity-check are > based on Integrity Algorithms defined in the Transform Type 3 registry. > Therefore, an implementation could negotiate the value of "0" (no > integrity-algorithm), and as you mentioned, rely on the built-in RoHC > CRC. > >> * The introduction to draft-ietf-rohc-hcoipsec-08 says that > "However, >> since current specifications for RoHC detail its operation on a > hop-by-hop >> basis, it may require extensions to enable its operation over IPsec > SAs.". >> This is not explained later. An IPsec tunnel is very much like a > single >> hop (for the tunneled traffic), so I don't see why special extensions >> would be needed. > > We'll clarify the introduction based on your comment. > > What we intended to indicate was that for RoHCoIPsec, there may be > multiple physical hops between compressor and decompressor (even though > it looks like a single hop from the IPsec perspective). Therefore, > RoHCv2 profiles that are tolerant to packet reordering/loss should be > used. > > Initial profiles of RoHC did not necessarily account for significant > packet reordering scenarios, since RoHC was initially designed to > operate over a single physical hop. > >> * Section 4 of draft-ietf-rohc-hcoipsec-08 needs some rewording. > Is >> the second sentence about the TFC feature of IPsec? About the padding >> feature of RoHC? About the problem in general? You might want to add >> discussion about whether it is recommended to use RoHC padding or > IPsec >> TFC to avoid the problem. > > It's about the problem in general. The second sentence was intended to > indicate that an ESP tunnel mode SA provides partial traffic flow > confidentiality, but that tunneling incurs additional packet overhead. > > I'm inclined to leave the text as-is; let me know if you still think it > needs to be modified. > >> * Section 5.2 of draft-ietf-rohc-hcoipsec (last paragraph) has > some >> strange text about ESP-NULL, which I don't understand. Why should > ESP-NULL >> be any different than any other ESP method? > > Fair comment. We'll delete this paragraph. > >> * There is, however, something to consider about ESP-NULL. Some >> middleboxes may want to inspect traffic that is encrypted with > ESP-NULL >> (see draft-grewal-ipsec-traffic-visibility-00). It's possible that > RoHC >> will cause those middleboxes to drop all traffic that is compressed, >> because they won't be able to parse the compressed headers. > > This is more of a question of policy rather than functionality. For > example, the middlebox may have a policy to drop ESP-NULL encrypted > packets whose inner-headers cannot be parsed. On the other hand, the > middlebox could have a policy that says inspect all ESP-NULL encrypted > packets, drop packets whose inner headers cannot be parsed, except for > those packets whose the NextHeader field is set to "RoHC". > >> * Section 6.1.2 says "f the RoHC protocol requires bi-directional >> communications, two SAs must be instantiated between the IPsec >> implementations." This is a non-issue, since IKE creates SAs in pairs >> anyways. So I don't see the point in the recommendation to use only > non- >> feedback profiles. You may want to mention that the decompressor needs > to >> relay feedback to the appropriate compressor > > Agreed. Later in the paragraph, we indicate: > > " Note that the requirement > for two SAs aligns with the operation of IKE, which creates SAs in > pairs by default." > > We'll modify the last sentence of the paragraph to indicate that the > decompressor associated with an inbound SA will relay feedback to the > compressor associated with the corresponding outbound SA. > >> Regarding the IKEv2 draft, I only have several comments about section > 2.1: >> * It's common for IKEv2 drafts to have at the beginning a figure > of >> the entire payload and then explain the various fields. > > Sure, we can add a figure illustrating the Notify payload. We actually > had this illustration in the -02 version of the draft, and then removed > it since it was identical to Figure 16 of RFC 4306. But, we'll add it > back. > >> * The explanation of the "Critical" bit is incorrect. It does not >> refer to the content of the payload, only to the type of the payload, > in >> this case "Notify". The bit MUST be off for Notify payloads, because > all >> IKEv2 implementations must support it. Similarly, there's not reason > to >> define the content of the reserved bits, because they're the same as > for >> any payload. > > Agreed--we have updated the draft to indicate that this bit if off. We > also removed the definition of the content of the reserved field. > >> * Protocol ID field: According to the first paragraph of 2.1, the >> notification is only in CCSA and IKE_AUTH. So there's no case where > this >> notification is used outside of the creation of the child SA, and > there's >> no need to ever set the protocol ID. > > Agreed--this is fixed. > > Best Regards, > Emre > > > ------------------------------ > > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www.ietf.org/mailman/listinfo/rohc > > > End of Rohc Digest, Vol 53, Issue 7 > *********************************** _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 22 10:08:25 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E6E23A6C8A; Mon, 22 Sep 2008 10:08:25 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04D523A6C15 for ; Sun, 21 Sep 2008 13:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 asQEZebGQdP1 for ; Sun, 21 Sep 2008 13:45:39 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id 2A7F83A6C0E for ; Sun, 21 Sep 2008 13:45:38 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id k34so842269wah.25 for ; Sun, 21 Sep 2008 13:45:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=WBsHjyGUPHjNVo56sc3K7iNPfgPW3XCPglbNuZhWHNQ=; b=IJk5x1yaBy047GUTnQiRssVdEI/sbZu6MCTkulKXj70MW38BWUl72al4JYdCuZ9fzu 0s0qSWyQP4w3bE4sCyPeXGyHxAnaXMHLJZwlTpqnM9aqysx9dr83//eiT0X0VNZ6Cnt+ ELpyXpBUbTIAGvn6FoatMeGCBokHUrTrAMPMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rFrpS8QTfXUsprl3B1aJClusNdWvQBx49qYpkzOT/e/WVya5yccAX7P9GoYGIgPog1 fvWlj07srk+KXJOkY5Nj8lh/RrRVklTVXLFEHYvsji4rPtBx7wPL1tKRNfTTcwKWL6Jn cqrq/wH4Yu1eHUnTTsYAq0wzLxwplvqM6UH+Q= Received: by 10.115.18.1 with SMTP id v1mr3500862wai.107.1222029956760; Sun, 21 Sep 2008 13:45:56 -0700 (PDT) Received: by 10.114.234.17 with HTTP; Sun, 21 Sep 2008 13:45:56 -0700 (PDT) Message-ID: Date: Sun, 21 Sep 2008 13:45:56 -0700 From: "Stephen Bevan" To: "Yoav Nir" In-Reply-To: <7E894C6E-2F44-4C52-B893-B066B4DE3FC8@checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline References: <18643.41900.851013.866168@fireball.kivinen.iki.fi> <7E894C6E-2F44-4C52-B893-B066B4DE3FC8@checkpoint.com> X-Mailman-Approved-At: Mon, 22 Sep 2008 10:08:22 -0700 Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Secure Crash Discovery for IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Fri, Sep 19, 2008 at 9:53 AM, Yoav Nir wrote: > We actually sync IKE SAs between gateways, although this is getting more > difficult, because IKEv2 requires the message counters to be synched. My > co-authors tell me that very often, their gateways are deployed with no > back-channel sync. We are hearing more people who want a physical separation > between the gateways (like putting them in different parts of town) and in > that case synching becomes much more difficult. I didn't address the last sentence in my previous reply and it is an interesting case which I'd like to understand exactly what this scenario is and how the drafts address it since it is not mentioned in the drafts or Wiki. The following are some questions that I think either/both should address to clarify this scenario :- Are the physical separate gateways protecting the same shared network (say via a private connection) or are they protecting physically independent networks (but with the same IPs)? If the former, then at the expense of additional configuration on the client all the gateways could be up simultaneously providing load-sharing and obviating the need for either protocol (unless each physically separate gateway in reality consists of one or more gateways which are monitoring each other). If the gateways are protecting different physically separate networks are they still monitoring each other such that the backup can assume the IP of the primary on failure? If so, why is synching difficult if monitoring is being done? If there is no monitoring, by what mechanism or mechanisms does traffic from the client directed to the primary IP get delivered to the backup when the primary fails such that either protocol can be used and what is the expected time for the takeover to occur? _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 22 10:08:26 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED6773A6C72; Mon, 22 Sep 2008 10:08:25 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7033A6808; Mon, 22 Sep 2008 00:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.835 X-Spam-Level: X-Spam-Status: No, score=-3.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_SE=0.35, 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 Mxqr0dLChW3a; Mon, 22 Sep 2008 00:46:47 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4B61D3A682B; Mon, 22 Sep 2008 00:46:47 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 94A0A20EB5; Mon, 22 Sep 2008 09:46:45 +0200 (CEST) X-AuditID: c1b4fb3e-ab68abb000007a96-db-48d74d65b94e Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 6DCB220716; Mon, 22 Sep 2008 09:46:45 +0200 (CEST) Received: from esealmw105.eemea.ericsson.se ([153.88.200.68]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Sep 2008 09:46:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 22 Sep 2008 09:46:44 +0200 Message-ID: In-Reply-To: <37BDD2FAF2AEAE459C6C70FDC2892E4E03499E88@MCLNEXVS05.resource.ds.bah.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [rohc] Comments on current RoHC over IPSec draft Thread-Index: AckcJeageewAKh1vT2qbF4yYrsECAwABXW1AABbfFWA= References: <48D6A96E.2020403@spawar.navy.mil> <37BDD2FAF2AEAE459C6C70FDC2892E4E03499E88@MCLNEXVS05.resource.ds.bah.com> From: "Kristofer Sandlund" To: "Ertekin, Emre [USA]" , "Robert A. Stangarone Jr." , , "Christou, Christos [USA]" , , X-OriginalArrivalTime: 22 Sep 2008 07:46:45.0169 (UTC) FILETIME=[5C502A10:01C91C87] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Mon, 22 Sep 2008 10:08:22 -0700 Cc: stangarr@nkiconsulting.com, Pasi.Eronen@nokia.com, Tero Kivinen Subject: Re: [IPsec] [rohc] Comments on current RoHC over IPSec draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Ertekin, Emre wrote on : >> MRRU - This parameter is unnecessary. The external interface of the >> IPSec device should be able to determine the MTU of its link and >> fragment as needed/necessary. None of the RoHCv2 PROFILES (found in >> RFC 5225) allow for the use of MRRU, so why use it? > > Fair comment. We'll remove this parameter. Hi, I haven't read the drafts in question nor the entire mail I'm replying to, I'd just like to point out that the statement above is incorrect. The following is a quote from 5225: The compressor MUST NOT use ROHC segmentation (see Section 5.2.5 of [RFC4995]), i.e., the Maximum Reconstructed Reception Unit (MRRU) MUST be set to 0, if the configuration of the ROHC channel contains at least one ROHCv2 profile in the list of supported profiles (i.e., the PROFILES parameter) and if the channel cannot guarantee in-order delivery of packets between compression endpoints. Therefore, it *is* allowed to use ROHC segmentation in v2, it is only disallowed if you have a reordering channel with v2 profiles. I'm not saying that ROHC segmentation is a very useful feature or that you have to allow it, I'd just like to avoid you making decisions based on an assumption that v2 *always* disallows segmentation. /k _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 22 10:08:26 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65BF73A6CA2; Mon, 22 Sep 2008 10:08: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 CC09E3A6970 for ; Mon, 22 Sep 2008 03:49:08 -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 tp8dl6wLtp0H for ; Mon, 22 Sep 2008 03:49:07 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by core3.amsl.com (Postfix) with ESMTP id 73E6C3A69BE for ; Mon, 22 Sep 2008 03:49:07 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so1500588fkq.5 for ; Mon, 22 Sep 2008 03:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Tnmtr09WfXmSVZOJKUu0K5f/y05UtpMR69HOtCGE7DE=; b=G86J6Dv1SHGjWRDShr0hxAPiZlYeKWZJ5Dvbz/6LRhcJ41WslORwKqVn26g7m0ftBA Dk9S7qHuytK/PmAM9tlAIyFyqCVjI1iZCYZgFdNNpbIDchHqo7/eebGL1adyYKrsKmDl jWMaYCpwMb8ibe97UKQ9bCZ0M3EYpDVsLA7Dk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=xjXlcvgZhwUEianAtZ6vRwyC1qjQI4BShyK6x8Ueh5NTj4xsXnTx50XxuZ4odvMaxq HTq+ZxRw5voJ0/oEr/eWm1QavV+2zFp4ZGdqkPah6EsBzvmpxylRtgdDIv4K9Jbchu8x z2IPT+/8/nXJ4ocQZrySIxqXD35cbemE4T3qA= Received: by 10.103.193.13 with SMTP id v13mr2523955mup.7.1222080545520; Mon, 22 Sep 2008 03:49:05 -0700 (PDT) Received: by 10.103.176.4 with HTTP; Mon, 22 Sep 2008 03:49:05 -0700 (PDT) Message-ID: <895583cb0809220349j332d9382l20707a4fbdb79bba@mail.gmail.com> Date: Mon, 22 Sep 2008 12:49:05 +0200 From: "Carl Knutsson" To: "Kristofer Sandlund" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <48D6A96E.2020403@spawar.navy.mil> <37BDD2FAF2AEAE459C6C70FDC2892E4E03499E88@MCLNEXVS05.resource.ds.bah.com> X-Mailman-Approved-At: Mon, 22 Sep 2008 10:08:22 -0700 Cc: rohc@ietf.org, "Robert A. Stangarone Jr." , rohc-owner@ietf.org, Pasi.Eronen@nokia.com, "Ertekin, Emre \[USA\]" , Tero Kivinen , ipsec@ietf.org, "Christou, Christos \[USA\]" , stangarr@nkiconsulting.com Subject: Re: [IPsec] [rohc] Comments on current RoHC over IPSec draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Emre, I believe MRRU should stay. I think we should have very good reasons before we remove it. We should not make any assumptions about the link layer. For some users it may more be convenient to use the ROHC segmentation instead of fragmentation in other layers. Why would we not allow it? Both the ROHCoIPSec draft and the framework already discusses ROHC segmentation. The ROHCoIPSec drafts is quite clear about the disadvantages with ROHC segmentation. I agree with Robert that the MAX_HEADER parameter should be removed. We have agreed on a set of negotiation parameters for the ROHC framework (RFC 3095 and RFC 4995). All other parameters must be negotiated within the protocol. If the MAX_HEADER parameter is really needed, it should be included in the ROHC framework and not in ROHCoIPSec drafts. If it becomes a problem for future ROHC profiles, it could be solved by something similar to CONTEXT_MEMORY feedback option for v2. /Calle On Mon, Sep 22, 2008 at 9:46 AM, Kristofer Sandlund wrote: > > Ertekin, Emre wrote on : > >>> MRRU - This parameter is unnecessary. The external interface of the >>> IPSec device should be able to determine the MTU of its link and >>> fragment as needed/necessary. None of the RoHCv2 PROFILES (found in >>> RFC 5225) allow for the use of MRRU, so why use it? >> >> Fair comment. We'll remove this parameter. > > Hi, > > I haven't read the drafts in question nor the entire mail I'm > replying to, I'd just like to point out that the statement above is > incorrect. The following is a quote from 5225: > > The compressor MUST NOT use ROHC segmentation (see Section 5.2.5 of > [RFC4995]), i.e., the Maximum Reconstructed Reception Unit (MRRU) > MUST be set to 0, if the configuration of the ROHC channel contains > at least one ROHCv2 profile in the list of supported profiles (i.e., > the PROFILES parameter) and if the channel cannot guarantee in-order > delivery of packets between compression endpoints. > > Therefore, it *is* allowed to use ROHC segmentation in v2, it is only > disallowed if you have a reordering channel with v2 profiles. > I'm not saying that ROHC segmentation is a very useful feature or that > you have to allow it, I'd just like to avoid you making decisions > based on an assumption that v2 *always* disallows segmentation. > > /k > _______________________________________________ > Rohc mailing list > Rohc@ietf.org > https://www.ietf.org/mailman/listinfo/rohc > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 22 12:55:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8FDD3A68DE; Mon, 22 Sep 2008 12:55: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 DE4663A68DE for ; Mon, 22 Sep 2008 12:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 VSuLQfZDR5iI for ; Mon, 22 Sep 2008 12:55:21 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 054B63A6843 for ; Mon, 22 Sep 2008 12:55:21 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D66E1294005; Mon, 22 Sep 2008 22:55:13 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 9E1A4294004; Mon, 22 Sep 2008 22:55:11 +0300 (IDT) Received: from [172.31.24.222] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8MJt3P1020190; Mon, 22 Sep 2008 22:55:11 +0300 (IDT) Message-Id: From: Yoav Nir To: ipsec@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 18:16:00 +0300 X-Mailer: Apple Mail (2.929.2) Cc: Paul Hoffman , Tero Kivinen Subject: [IPsec] Issue #19: Motivation for including SPIs in the cookie X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero said: > >> where is a randomly generated secret known only to the >> responder and periodically changed and | indicates concatenation. >> should be changed whenever is >> regenerated. The cookie can be recomputed when the IKE_SA_INIT >> arrives the second time and compared to the cookie in the received >> message. If it matches, the responder knows that the cookie was >> generated since the last change to and that IPi must be >> the >> same as the source address it saw the first time. Incorporating >> SPIi >> into the calculation ensures that if multiple IKE_SAs are being >> set >> up in parallel they will all get different cookies (assuming the >> initiator chooses unique SPIi's). Incorporating Ni into the hash > > The real reason to hash the SPIs to the cookie is to make sure that > attacker cannot fetch one one cookie from the other end, and then > initiate 100 IKE_SA_INIT exchanges all with different initiator SPIs > (and perhaps port numbers) so that the for the responder it looked > like there is lots of machines behind one NAT box who are all trying > to connect. As the cookie is tied to the SPIi the attacker cannot use > cookie multiple times. In my personal opinion, I think Tero is right, and the text should be updated according to this suggestion. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 22 12:55:29 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E23128C156; Mon, 22 Sep 2008 12:55:29 -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 8025028C156 for ; Mon, 22 Sep 2008 12:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_42=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 9yOO7J4mY1Ei for ; Mon, 22 Sep 2008 12:55:26 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 5BFCE28C114 for ; Mon, 22 Sep 2008 12:55:26 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 86F07294003; Mon, 22 Sep 2008 22:55:11 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5B948294002; Mon, 22 Sep 2008 22:55:10 +0300 (IDT) Received: from [172.31.24.222] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8MJt3P0020190; Mon, 22 Sep 2008 22:55:09 +0300 (IDT) Message-Id: <58FA415B-A01D-4C26-B56C-E40A7CA66EE7@checkpoint.com> From: Yoav Nir To: ipsec@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 18:11:34 +0300 X-Mailer: Apple Mail (2.929.2) Cc: Paul Hoffman , Tero Kivinen Subject: [IPsec] Issue 18: Port in anti-DoS cookie X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1886211930==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1886211930== Content-Type: multipart/alternative; boundary=Apple-Mail-1--1024040838 --Apple-Mail-1--1024040838 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Tero said: >> A good way to do this is to set the responder cookie to be: >> >> Cookie = | Hash(Ni | IPi | SPIi | ) > > I was starting to wonder if that Cookie should also include the Port > part, especially in the NAT-T case? The attack that the cookie mechanism is supposed to foil is a DoS attack using IKE_SA_INIT packets with a spoofed source. I don't see how adding the source port to the cookie calculation helps avoid this. In the NAT-T case, two initiators behind the same NAT device will have the same IP address but different ports. If their PRNG is so bad that they both generate the same Ni and SPIi, then they will get the same cookie, but in that case, that's probably the least of their problems. It still does not increase the DoS threat to the responder, because each initiator has the "right" to use the NAT box IP address. At any rate, this is not part of the protocol, and is just a suggestion for implementers. I suggest that unless someone can describe an attack on the current version, that we leave this as is. Yoav --Apple-Mail-1--1024040838 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Tero said:
   A good way to do this is to set the = responder cookie to be:

   Cookie =3D <VersionIDofSecret> | = Hash(Ni | IPi | SPIi | <secret>)

I was starting = to wonder if that Cookie should also include the Port
part, = especially in the NAT-T case?

The attack that = the cookie mechanism is supposed to foil is a DoS attack using = IKE_SA_INIT packets with a spoofed source. I don't see how adding the = source port to the cookie calculation helps avoid = this.

In the NAT-T case, = two initiators behind the same NAT device will have the same IP address = but different ports. If their PRNG is so bad that they both generate the = same Ni and SPIi, then they will get the same cookie, but in that case, = that's probably the least of their problems. It still does not increase = the DoS threat to the responder, because each initiator has the "right" = to use the NAT box IP address.

At any rate, this = is not part of the protocol, and is just a suggestion for = implementers. 

I suggest that = unless someone can describe an attack on the current version, that we = leave this as is.

Yoav

= --Apple-Mail-1--1024040838-- --===============1886211930== 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 --===============1886211930==-- From ipsec-bounces@ietf.org Mon Sep 22 12:58:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4990028C168; Mon, 22 Sep 2008 12:58:17 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18D028C114 for ; Mon, 22 Sep 2008 12:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 3RaFnscBgjsN for ; Mon, 22 Sep 2008 12:58:15 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id CF56C28C156 for ; Mon, 22 Sep 2008 12:58:14 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D5BD2294003; Mon, 22 Sep 2008 22:57:40 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 88B99294001; Mon, 22 Sep 2008 22:55:04 +0300 (IDT) Received: from [172.31.24.222] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8MJt3Ox020190; Mon, 22 Sep 2008 22:55:03 +0300 (IDT) Message-Id: <08E45D03-6381-48CD-A839-A24A4430A0A8@checkpoint.com> From: Yoav Nir To: ipsec@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 22 Sep 2008 17:57:52 +0300 X-Mailer: Apple Mail (2.929.2) Cc: Paul Hoffman , Tero Kivinen Subject: [IPsec] Issue #15: Message ID reset to 0 after IKE SA rekey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I think this is one we can easily get out of the way. Tero said: >> 2.2. Use of Sequence Numbers for Message ID >> >> The Message ID is a 32-bit quantity, which is zero for the >> IKE_SA_INIT messages (including retries of the message due to >> responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), >> and incremented for each subsequent exchange. > > Add text: > > The Message ID is reset to zero also after IKE SA rekey for the new > IKE SA. > However, if you read section 2.2 to the end, it says: > Note that Message IDs are cryptographically protected and provide > protection against message replays. In the unlikely event that > Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be > closed. Rekeying an IKE_SA resets the sequence numbers. IMO the last sentence already says what Tero wants to add, so it's just a matter of phrasing. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 03:16:52 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 448FC3A6809; Tue, 23 Sep 2008 03:16:52 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 070EC3A6809 for ; Tue, 23 Sep 2008 03:16: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXRBbRHmlycD for ; Tue, 23 Sep 2008 03:16:50 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id EB68B3A67E5 for ; Tue, 23 Sep 2008 03:16:38 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NAGU5R000472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 13:16:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NAGRoZ001308; Tue, 23 Sep 2008 13:16:27 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.49659.793457.85853@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 13:16:27 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <58FA415B-A01D-4C26-B56C-E40A7CA66EE7@checkpoint.com> References: <58FA415B-A01D-4C26-B56C-E40A7CA66EE7@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: ipsec@ietf.org, Paul Hoffman Subject: [IPsec] Issue 18: Port in anti-DoS cookie X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > I suggest that unless someone can describe an attack on the current > version, that we leave this as is. That is ok for me. This was mostly just something that popped up to my head when reading the document, and as I didn't want to start wasting too much time thinking it at that time, I just marked it down so it will get checked down. I have not found out any working attack against the current version so it can stay as it is now. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 03:49:39 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455803A690A; Tue, 23 Sep 2008 03:49:39 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64A93A690A for ; Tue, 23 Sep 2008 03:49:38 -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 8yQbnk+wtP7D for ; Tue, 23 Sep 2008 03:49:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id B76003A67CC for ; Tue, 23 Sep 2008 03:49:25 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NAnL5R013421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 13:49:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NAnLp1026210; Tue, 23 Sep 2008 13:49:21 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.51633.237900.734643@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 13:49:21 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <08E45D03-6381-48CD-A839-A24A4430A0A8@checkpoint.com> References: <08E45D03-6381-48CD-A839-A24A4430A0A8@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 7 min X-Total-Time: 32 min Cc: ipsec@ietf.org, Paul Hoffman Subject: [IPsec] Issue #15: Message ID reset to 0 after IKE SA rekey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > I think this is one we can easily get out of the way. > > Tero said: > >> 2.2. Use of Sequence Numbers for Message ID > >> > >> The Message ID is a 32-bit quantity, which is zero for the > >> IKE_SA_INIT messages (including retries of the message due to > >> responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), > >> and incremented for each subsequent exchange. > > > > Add text: > > > > The Message ID is reset to zero also after IKE SA rekey for the new > > IKE SA. > > > > > However, if you read section 2.2 to the end, it says: > > Note that Message IDs are cryptographically protected and provide > > protection against message replays. In the unlikely event that > > Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be > > closed. Rekeying an IKE_SA resets the sequence numbers. > > IMO the last sentence already says what Tero wants to add, so it's > just a matter of phrasing. There were some implementors who missed the resetting message IDs text. I can understand why they did so, as now it is hidden at the end of section in the paragraph talking about very unlikely event of message IDs wrapping. Most implementors will just see that this talks about unlikely events, so they do not need to care about it, and don't realize that the resetting of message IDs after rekeying an IKE SA is something they do need to implement. So I want to move that text to the main part of the message ID description not to the special case description. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 03:59:37 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CC933A689A; Tue, 23 Sep 2008 03:59:37 -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 5C0CF3A6800 for ; Tue, 23 Sep 2008 03:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, 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 Hx0oNqvTZb0A for ; Tue, 23 Sep 2008 03:59:35 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6935F3A67D7 for ; Tue, 23 Sep 2008 03:59:35 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B968C294005; Tue, 23 Sep 2008 13:59:37 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 488EC294002; Tue, 23 Sep 2008 13:59:35 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8NAxYOx015438; Tue, 23 Sep 2008 13:59:34 +0300 (IDT) Message-Id: <6944AADF-9CE8-4E2D-80AF-7D077054F57F@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18648.51633.237900.734643@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 23 Sep 2008 13:59:33 +0300 References: <08E45D03-6381-48CD-A839-A24A4430A0A8@checkpoint.com> <18648.51633.237900.734643@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org, Paul Hoffman Subject: Re: [IPsec] Issue #15: Message ID reset to 0 after IKE SA rekey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Sep 23, 2008, at 1:49 PM, Tero Kivinen wrote: >> >> IMO the last sentence already says what Tero wants to add, so it's >> just a matter of phrasing. > > There were some implementors who missed the resetting message IDs > text. I can understand why they did so, as now it is hidden at the end > of section in the paragraph talking about very unlikely event of > message IDs wrapping. Most implementors will just see that this talks > about unlikely events, so they do not need to care about it, and don't > realize that the resetting of message IDs after rekeying an IKE SA is > something they do need to implement. So I want to move that text to > the main part of the message ID description not to the special case > description. I think that's a good idea, although what would they use for the initial message ID for the new IKE SA. A random value? The MsgIDs from the old SA? Paul, I think we can accept this and move that last sentence to the main part of the message ID description. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 04:16:42 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 283F93A67E5; Tue, 23 Sep 2008 04:16:42 -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 A8FCA3A67E5 for ; Tue, 23 Sep 2008 04:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4Cq2CUWD4KE for ; Tue, 23 Sep 2008 04:16:39 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 675823A67CC for ; Tue, 23 Sep 2008 04:16:27 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NBGT9k017595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2008 14:16:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NBGTYq021370; Tue, 23 Sep 2008 14:16:29 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.53261.386116.761961@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 14:16:29 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 15 min X-Total-Time: 15 min Subject: [IPsec] Issue #34 Message ID still undefined, do not mention X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 > > 1.3. The CREATE_CHILD_SA Exchange > ... > > The CREATE_CHILD_SA response for creating a new CHILD_SA is: > > > > <-- HDR, SK {SA, Nr, [KEr], > > TSi, TSr} > > > > The responder replies (using the same Message ID to respond) with the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > This is confusing, as we have not introduced message id at all at this > point. I suggest removing the "(using the same Message ID to > respond)". > > ===Not done. Disagree. It is important here. I disagree it being important here, but if you want to keep it here, it would then require moving the description of message id so it is introduced before this. If the implementors have not understood how message IDs work in general to pair up request and responses, then this text is not going to really help. It just proofs the point that we have not explained Message ID properly before this. So one way to fix it (and keep the confusing text still there), is to move some or all of the section 2.2 before this. Perhaps add some more text to Introduction section, where it talks about request and reply pairs, or at least put forward reference there. Perhaps something like this: All IKE communications consist of pairs of messages: a request and a response. The pair is called an "exchange". We call the first ... => All IKE communications consist of pairs of messages: a request and a response. The request and the corresponding response are matched up by the Message ID field in the fixed header (see section 2.2). The pair is called an "exchange". We call the first ... When I was reading the document the sudden text about something about Message ID which had not been introduced yet, just seemed like there was something missing in the document. Another posibility is to move the request / response description from the introduction section to its own section (before 1.2) and add more text about request / response and message ids there, but that would require much bigger rewrite. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 04:27:22 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42B63A682B; Tue, 23 Sep 2008 04:27: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 BECA93A67CC for ; Tue, 23 Sep 2008 04:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQcltYZLYbI8 for ; Tue, 23 Sep 2008 04:27:20 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 484E33A682B for ; Tue, 23 Sep 2008 04:27:08 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NBR81Y005332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2008 14:27:08 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NBR7LK014060; Tue, 23 Sep 2008 14:27:07 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.53899.641720.849862@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 14:27:07 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 8 min X-Total-Time: 9 min Subject: [IPsec] Issue #10 Specific Protocol ID values in REKEY_SA notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 > > 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange > ... > > {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a > > CREATE_CHILD_SA exchange if the purpose of the exchange is to replace > > an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is > > identified by the SPI field in the Notify payload; this is the SPI > > the exchange initiator would expect in inbound ESP or AH packets. > > There is no data associated with this Notify type. > > Add clarification here specifying the value of the Protocol ID field: > > The Protocol ID field of REKEY_SA notify is set accordingly to ESP > (3) or AH (2). > > ===Not done. Disagree. There may be additional protocol IDs in the future. One of the most common issues we have had in the interops has been the confusions about what protocol ID values to use in which notify fields. Most of them has where people have used protocol ID value of non-zero when zero should have been used. REKEY_SA is one of those 2 notifies which actually use non-zero Protocol ID values, and it would be very important to point that out (it is already mentioned in the section 3.10). Also the text 3.10 already says we can have only protocol IDs to indicate AH and 3 to indicate ESP. If we add new protocol IDs in the future, we are most likely not going to modify this document, but write new document, and that will then point out what protocol ID numbers are used where and when. If we are trying to keep the description of notifies in one place, then we should also copy this fact of protocol IDs here too. Before the text describing REKEY_SA and Protocol IDs was in section 3.10, but now the text about REKEY_SA is in 1.3.3, but the text describing the protocol ID use is in 3.10. If you do not want to mention the actal protocol numbers here that is ok, but just saying that "The Protocol ID field of REKEY_SA notify is set match the protocol of the SA we are rekeying.", but then implementors might use IP-protocol numbers (50, 51) instead of the correct values 2 and 3. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 04:36:25 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 470273A67D7; Tue, 23 Sep 2008 04:36:25 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 830613A6869 for ; Tue, 23 Sep 2008 04:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 0tXKUA3TdMuh for ; Tue, 23 Sep 2008 04:36:23 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 56C6F3A67CC for ; Tue, 23 Sep 2008 04:36:23 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EA824294004; Tue, 23 Sep 2008 14:36:25 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5A351294002; Tue, 23 Sep 2008 14:36:24 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8NBaOOx024224; Tue, 23 Sep 2008 14:36:24 +0300 (IDT) Message-Id: <5CA16549-5544-4114-9FAE-5C0BDFA4E060@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18648.53899.641720.849862@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 23 Sep 2008 14:36:23 +0300 References: <18648.53899.641720.849862@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #10 Specific Protocol ID values in REKEY_SA notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Sep 23, 2008, at 2:27 PM, Tero Kivinen wrote: >>> 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange >> ... >>> {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included >>> in a >>> CREATE_CHILD_SA exchange if the purpose of the exchange is to >>> replace >>> an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed >>> is >>> identified by the SPI field in the Notify payload; this is the >>> SPI >>> the exchange initiator would expect in inbound ESP or AH packets. >>> There is no data associated with this Notify type. >> >> Add clarification here specifying the value of the Protocol ID field: >> >> The Protocol ID field of REKEY_SA notify is set accordingly to >> ESP >> (3) or AH (2). >> >> ===Not done. Disagree. There may be additional protocol IDs in the >> future. > > One of the most common issues we have had in the interops has been the > confusions about what protocol ID values to use in which notify > fields. Most of them has where people have used protocol ID value of > non-zero when zero should have been used. REKEY_SA is one of those 2 > notifies which actually use non-zero Protocol ID values, and it would > be very important to point that out (it is already mentioned in the > section 3.10). > > Also the text 3.10 already says we can have only protocol IDs to > indicate AH and 3 to indicate ESP. If we add new protocol IDs in the > future, we are most likely not going to modify this document, but > write new document, and that will then point out what protocol ID > numbers are used where and when. > > If we are trying to keep the description of notifies in one place, > then we should also copy this fact of protocol IDs here too. Before > the text describing REKEY_SA and Protocol IDs was in section 3.10, but > now the text about REKEY_SA is in 1.3.3, but the text describing the > protocol ID use is in 3.10. > > If you do not want to mention the actal protocol numbers here that is > ok, but just saying that "The Protocol ID field of REKEY_SA notify is > set match the protocol of the SA we are rekeying.", but then > implementors might use IP-protocol numbers (50, 51) instead of the > correct values 2 and 3. How about: The Protocol ID field of the REKEY_SA notification is set to match the protocol of the SA we are rekeying, for example, 3 for ESP and 2 for AH. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 04:53:27 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0A583A67E5; Tue, 23 Sep 2008 04:53:27 -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 2AA8A3A67E5 for ; Tue, 23 Sep 2008 04:53:27 -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 TcWJsWpAclNy for ; Tue, 23 Sep 2008 04:53:26 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 1B1F23A67D7 for ; Tue, 23 Sep 2008 04:53:13 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NBrFBm022806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2008 14:53:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NBrFq4007003; Tue, 23 Sep 2008 14:53:15 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.55467.488299.613222@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 14:53:15 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 8 min X-Total-Time: 14 min Subject: [IPsec] Issue #20 Common use case for multiple proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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.7. Cryptographic Algorithm Negotiation > ... > > Each IPsec protocol proposal contains one or more transforms. Each > > transform contains a transform type. The accepted cryptographic > > suite MUST contain exactly one transform of each type included in the > > proposal. For example: if an ESP proposal includes transforms > > ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, > > AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one > > of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six > > combinations are acceptable. > > Perhaps we should add here paragraph explaining the most common reason > of the multiple propsoals: > > If both combined mode ciphers and normal ciphers with integrity > protection needs to be proposed, the inititor needs to use two > proposals. One of them includes all the combined mode ciphers, > without the integrity algorithms (as combined mode ciphers are not > allowed to have any other integrity algorithm than none), and the > another includes normal ciphers and the integrity algoritms for > them. > > ===Not done. This level of specificity is not needed, and we don't talk > about combined modes in the original IKEv2 doc. Lets put it this way, I myself hadn't realized that we need support for multiple proposals for this reason before we started to implement combined mode ciphers for ESP. Only other reason for supoprting multiple proposals for crypto negotiation was things like not supporting all combinations (not useful) and AH + ESP (not done this way anymore). Because of this our implementation did have very strict restrictions on the number of proposals you could have. We had to change that when we implemented combined mode ciphers, as otherwise we could not propose those ciphers with other ciphers at all. Note, that we are not talking about using combined mode ciphers in the IKEv2, but using them in the ESP, and that is already described in the ESPv3 document (RFC4303). I think it would be useful to point this out for the future implementors too, as the current RFC4306 do allow negotiation of combined mode ciphers for ESP. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 05:10:42 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B9BD3A6923; Tue, 23 Sep 2008 05:10:42 -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 15E5F3A6809 for ; Tue, 23 Sep 2008 05:10:42 -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 aqL0lY5rt76F for ; Tue, 23 Sep 2008 05:10:41 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 9ACB53A6923 for ; Tue, 23 Sep 2008 05:10:26 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NCAR1a027629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2008 15:10:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NCAR1b000657; Tue, 23 Sep 2008 15:10:27 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.56499.156864.891261@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 15:10:27 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 14 min X-Total-Time: 15 min Subject: [IPsec] Issue #23 Example IP address ranges X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 > > 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. TSr specifies the destination address of the traffic > > forwarded to (or the source address of the traffic forwarded from) > > the responder of the CHILD_SA pair. For example, if the original > > initiator requests the creation of a CHILD_SA pair, and wishes to > > tunnel all traffic from subnet 192.0.1.* on the initiator's side to > > subnet 192.0.2.* on the responder's side, the initiator would include > > a single traffic selector in each TS payload. TSi would specify the > > address range (192.0.1.0 - 192.0.1.255) and TSr would specify the > > address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was > > acceptable to the responder, it would send identical TS payloads > > back. (Note: The IP address range 192.0.2.* has been reserved for > > use in examples in RFCs and similar documents. This document needed > > two such ranges, and so also used 192.0.1.*. This should not be > > confused with any actual address.) > > I think we should use only the one example network that has been > reserved for that purpose, i.e get the rid of the 192.0.1.* address > space. As we do use ranges in all cases in the IKEv2, there is no > reason why the networks need to be /24 subnets. How about using > > 192.0.2.0/25 (i.e. 192.0.2.0 - 192.0.2.127) and > 192.0.2.128/25 (i.e. 192.0.2.128 - 192.0.2.255) instead. > > ===Not done. People really relate to /24s much better. And that is the reason we still do have implementations which cannot do ranges but only do subnets. As IKEv2 do use only IP-ranges, I think the examples should always use ranges, and should NOT use any /24 or 192.0.1.* style expression ever. If implementors do not understand how ranges work, they should learn now before starting to implement IKEv2 :-) I myself think ranges like 192.0.1.32 - 192.0.1.39 are much simplier than 192.0.1.32/29, especially when you are reading them. Writing and generating them might be bit harder, but that is done only once while writing, it is the reading part that is the more important for this document. When you need to convert subnet like 192.0.1.192/28 to range to be used in the TS it just adds one extra complication for the implementor. > > Otherwise we might want to add comment to all other places having that > 192.0.1.* network (which is actually used much more than the real > example network of 192.0.2.*). > > ===Not done. Developers reading this document understand what is going on. I think we should follow RFC 3330 and use only that network reserved for examples, especially as there is nothing in the IKEv2 that actually requires using any subnets. We could use 192.0.2.0-192.0.2.99 and 192.0.2.150-192.0.2.249 also if we just felt like it, and I do not really think it would make our examples harder to understand. In the configuration payloads case we do still need to restrict ourself to some kind of subnets as INTERNAL_IP4_NETMASK and INTERNAL_IP4_SUBNET attributes do not use ranges, but even there is nothing that requires using /24 networks (and some of the examples already use /26 network there). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 05:20:13 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6A53A68FE; Tue, 23 Sep 2008 05:20: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 448173A689A for ; Tue, 23 Sep 2008 05:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLjnFUG+g0or for ; Tue, 23 Sep 2008 05:20:11 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 99F473A696C for ; Tue, 23 Sep 2008 05:20:00 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NCK2QE019056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2008 15:20:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NCK2OA008002; Tue, 23 Sep 2008 15:20:02 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.57073.992710.756960@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 15:20:01 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 5 min X-Total-Time: 5 min Subject: [IPsec] Issue #27 Motivation for using port 4500 vs. 500 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 > > sent to the port from whence they came. This is because the ports > > may be modified as the packets pass through NATs. Similarly, IP > > addresses of the IKE endpoints are generally not included in the IKE > > payloads because the payloads are cryptographically protected and > > could not be transparently modified by NATs. > > > > Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working > > through a NAT, it is generally better to pass IKE packets over port > > 4500 because some older NATs handle IKE traffic on port 500 cleverly > > in an attempt to transparently establish IPsec connections between > > endpoints that don't handle NAT traversal themselves. Such NATs may > > interfere with the straightforward NAT traversal envisioned by this > > document. > > Everything after the first sentence in the paragraph is just > misleading and should be removed. > > ===Not done. This was generally agreed to, I believe. The text in sense is true, but it is not really relevant with the current IKEv2. It was relevant in the case where people still tried to run the same kind of NAT-T protocols over port 500. In the current document I think it is just much better to say that you MUST use port 4500 if NAT is detected. This is already said here: The IKE initiator MUST check these payloads if present and if they do not match the addresses in the outer packet MUST tunnel all future IKE and ESP packets associated with this IKE_SA over UDP port 4500. So as current conforming IKEv2 implementations cannot use port 500 when NAT is detected, I think it is bit misleading to explain something that it is better to do xxx if you are anyways required to do xxx. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 05:28:56 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5EA23A694A; Tue, 23 Sep 2008 05:28:56 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B194C3A69D8 for ; Tue, 23 Sep 2008 05:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eDmE-ITh6TG for ; Tue, 23 Sep 2008 05:28:54 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 79F223A6923 for ; Tue, 23 Sep 2008 05:28:43 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NCSiX0028290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2008 15:28:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NCSivX015694; Tue, 23 Sep 2008 15:28:44 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.57596.1776.816224@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 15:28:44 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 7 min X-Total-Time: 6 min Subject: [IPsec] Issue #41 Interaction of MOBIKE with 'simple' IKE mobility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 > > o There are cases where a NAT box decides to remove mappings that > > are still alive (for example, the keepalive interval is too long, > > or the NAT box is rebooted). To recover in these cases, hosts > > that are not behind a NAT SHOULD send all packets (including > > retransmission packets) to the IP address and port from the last > > valid authenticated packet from the other end (i.e., dynamically > > update the address). A host behind a NAT SHOULD NOT do this > > because it opens a DoS attack possibility. Any authenticated IKE > > packet or any authenticated UDP-encapsulated ESP packet can be > > used to detect that the IP address or the port has changed. > > This paragraph should here point out that MOBIKE changes this behivor, > and point to the MOBIKE documents for more information. > > ===Not done, but will most likely be. Supply exact text and discuss on > the mailing list. New text: o There are cases where a NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover in these cases, hosts that do not support other methods of recover (i.e. MOBIKE), and that are not behind a NAT SHOULD send all packets (including retransmission packets) to the IP address and port from the last valid authenticated packet from the other end (i.e., dynamically update the address). A host behind a NAT SHOULD NOT do this because it opens a DoS attack possibility. Any authenticated IKE packet or any authenticated UDP-encapsulated ESP packet can be used to detect that the IP address or the port has changed. When IKEv2 is used with MOBIKE, the dynamically updating the addresses described above, interfares with the MOBIKE's way of the recovering from the same situation, so this method MUST NOT be used when MOBIKE is used. See MOBIKE (RFC4555) section 3.8 for more information. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 05:35:30 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0BAD28C1DF; Tue, 23 Sep 2008 05:35:30 -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 209EB3A69CD for ; Tue, 23 Sep 2008 05:35: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn4VdBQ3+PBu for ; Tue, 23 Sep 2008 05:35:29 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id DEFD03A6923 for ; Tue, 23 Sep 2008 05:35:20 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NCZLt5025580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2008 15:35:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NCZLYc013111; Tue, 23 Sep 2008 15:35:21 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.57993.707815.94580@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 15:35:21 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 6 min X-Total-Time: 5 min Subject: [IPsec] Issue #29 Need to clarify Exchange Type field X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 > > o Exchange Type (1 octet) - Indicates the type of exchange being > > used. This constrains the payloads sent in each message and > > orderings of messages in an exchange. > ^^^^^^^^^ > > What does that try to say? > > ===Not done. It is saying that exchange types can impose orderings. Then I think it is not really true. Each exchange consists of request and reply pair, and exchanges can follow each other in certain order, but as there is only 2 messages in an exchange (one request and one reply), I do not think exchange type can really constraint order of the messages in an exchange (ok, I think it is implictly understood that request comes before reply, and you are not allowed to respond with a reply to request, before the request is sent, but I still think the word there is just confusing and not helping at all). Section 1 explains exchange to be: All IKE communications consist of pairs of messages: a request and a response. The pair is called an "exchange". So no exchange can have more than 2 messages. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 05:52:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA7A13A6809; Tue, 23 Sep 2008 05:52:23 -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 3DB823A6829 for ; Tue, 23 Sep 2008 05:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3OD473ZwOLG for ; Tue, 23 Sep 2008 05:52:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id C7B1E3A67F2 for ; Tue, 23 Sep 2008 05:52:09 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NCqBaH028708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2008 15:52:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NCqBGY025753; Tue, 23 Sep 2008 15:52:11 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.59003.22895.803651@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 15:52:11 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 12 min X-Total-Time: 16 min Subject: [IPsec] Issue #42 Improve example of multiple proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 > > 3.3. Security Association Payload > ... > > The Proposal structure contains within it a Proposal # and an IPsec > > protocol ID. Each structure MUST have a proposal number one (1) > > greater than the previous structure. The first Proposal in the > > initiator's SA payload MUST have a Proposal # of one (1). A proposal > > of AH or ESP would have two proposal structures, one for AH with > > Proposal #1 and one for ESP with Proposal #2. > > I think the last sentence should be removed, as it is bit confusing > and some people might read it "AH and ESP" and interpret it as > bundles. I do not really consider AH or ESP style proposal that > common to require example here. Perhaps ESP with combined mode ciphers > and ESP with normal ciphers + integrity algorithms would make better > example. > > ===Not done. The current example is clearer than your proposed change > because few people understand combined modes, even if the current > example is far-fetched. A different, clearer example would be a good > replacement for the current text. The problem is that currently there is only ONE good reason to use multiple proposals. This is combined mode ciphers. Because of this I think it is the one that should be used as an example. I do not think using combined modes in ESP is that complicated. Replacement text could be something like this: The Proposal structure contains within it a Proposal # and an IPsec protocol ID. Each structure MUST have a proposal number one (1) greater than the previous structure. The first Proposal in the initiator's SA payload MUST have a Proposal # of one (1). A common reason to use multiple proposals is when used with combined mode ciphers. Combined mode ciphers include both integrity and encryption in single encryption algorithm. Because of this it is not allowed to have combined mode ciphers with an another integrity algorithm, thus proposal must not have any integrity algorithms (other than NONE). If initiator want to propose both combine mode ciphers and normal ciphers, it must include two proposals. One will have all combined mode ciphers, and no integrity algorithm. The other will have all non-combined mode ciphers and all allowed integrity algorithms with them. For example such proposal would have two proposal structures, one for ESP with ENCR_AES-CCM_8, ENCR_AES-CCM_12, and ENCR_AES-CCM_16 as Proposal #1 and one for ESP with ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and AUTH_HMAC_SHA1_96 as Proposal #2. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 06:00:54 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282493A6998; Tue, 23 Sep 2008 06:00: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 8017E3A69F0 for ; Tue, 23 Sep 2008 06:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3U7j0PCMj-Q for ; Tue, 23 Sep 2008 06:00:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 413843A67F2 for ; Tue, 23 Sep 2008 06:00:36 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8ND0cbv027595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2008 16:00:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8ND0bOv011948; Tue, 23 Sep 2008 16:00:37 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.59509.962691.554343@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 16:00:37 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 7 min X-Total-Time: 6 min Subject: [IPsec] Issue #31 Clarification re: Cert Signature payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 > > o X.509 Certificate - Signature (4) contains a DER encoded X.509 > > certificate whose public key is used to validate the sender's AUTH > > payload. > > That certificate can also bve used as part of the chain. I.e. add > > or used in the validation. > > to the end of that paragraph. > > ===Not done. It already says this. I bit disagree with this, as certificate that is used to sign the end users certificate are not directly "used to validate the sender's AUTH payload". It is used to validate the certificate used to validate sender's AUTH payload, but it depends how strictly you interpret the "sender's AUTH payload" part. But anyways this is not really that important case, I just tought it would make it easier to understand that there can be other certificates from the chain in sent inside the IKEv2 CERT payloads too, than just the one used to validate the sender's AUTH payload (there is text about this already at the end of 3.6 where it says the first CERT payload must be the one that whose public key is used to sign the AUTH payload). I remember that I have seen at least several IKEv1 implementations who didn't like any extra certificates sent to them. Don't remember if any of those bugs were really present in IKEv2 implementations. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 06:42:48 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87FCB3A693D; Tue, 23 Sep 2008 06:42:48 -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 940D03A68C8 for ; Tue, 23 Sep 2008 06:42:46 -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 C2tabob81g-C for ; Tue, 23 Sep 2008 06:42:42 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 6037328C0F1 for ; Tue, 23 Sep 2008 06:42:27 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NDgSYp025198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2008 16:42:28 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NDgSbS009203; Tue, 23 Sep 2008 16:42:28 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.62020.138458.908262@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 16:42:28 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 16 min X-Total-Time: 40 min Subject: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 > > 3.14. Encrypted Payload > > > > The Encrypted Payload, denoted SK{...} or E in this memo, contains > > other payloads in encrypted form. The Encrypted Payload, if present > > in a message, MUST be the last payload in the message. Often, it is > > the only payload in the message. > > > > The algorithms for encryption and integrity protection are negotiated > > during IKE_SA setup, and the keys are computed as specified in > > Section 2.14 and Section 2.18. > > > > This document specifies the cryptographic processing of Encrypted > > payloads using a block cipher in CBC mode and an integrity check > > algorithm that computes a fixed-length checksum over a variable size > > message. The design is modeled after the ESP algorithms described in > > As we already has document which describes how to use other ciphers in > the IKE, we at least put the reference to there, or even incorporate > the changes specified in there to this document. Especially as the > RFCF 4307 specifies ENCR_AES_CTR as SHOULD for the IKEv2... > > ===Done. Well, not the way that you wanted. I will send in an errata to > RFC 4307 saying that AES_CTR should not have been listed. I think the AES_CTR can be used to protect the IKEv2 SA without any problems. The RFC3686 already describes evertything that is needed to use it. The only difference to the CBC mode is, is the way how IV for the AES_CTR is generated. The RFC4306 only points to "Recommendation for Block Cipher Modes of Operation" document for advises for IV generation. Only think that would not really be needed for IV selection is the text in the RFC4306 which says that IV must be unpredictable. The counter mode ciphers do not require unpredictability but they do require uniqueness. Anyways RFC3686 already describes the way how the IV should be generated for AES_CTR, and I do not see any reason why the the text which previously allowed CTR now needs to forbid CTR modes and only allow CBC modes. This is again protocol change that will change bits on the wire (i.e making CTR mode in IKEv2 SA to be unspecified even when it was previously specified). Note, that RFC5282 "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol" do NOT include AES-CTR description there. It only includes combined modes, which were unspecified in IKEv2 SAs before. Couldn't find issue number for this from the tracker, so could not put reference to it. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 06:58:52 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E203A6B12; Tue, 23 Sep 2008 06:58:52 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C705C3A6A51 for ; Tue, 23 Sep 2008 06:58: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NvgwTzW+INr for ; Tue, 23 Sep 2008 06:58:51 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 789AA3A6A62 for ; Tue, 23 Sep 2008 06:58:42 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NDwio6008163 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2008 16:58:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NDwiNu017448; Tue, 23 Sep 2008 16:58:44 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.62996.136882.689426@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 16:58:44 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 12 min X-Total-Time: 13 min Subject: [IPsec] Issue #32 Demoted SHOULD: EAP Identity Request X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 > > 3.16. Extensible Authentication Protocol (EAP) Payload > ... > > {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an > > indication of initiator identity in message 3 of the protocol, the > > responder should not send EAP Identity requests. The initiator may, > > however, respond to such requests if it receives them. > > This is again bits on the wire protocol change if someone after this > does not follow the SHOULD NOT and SHOULD written here before. I think > it should be kept as it was before. > > ===Not done. Disagree about this being bits on the wire because the responder > might have sent the request anyway. I do think it is protocol change if responder is changed from not sending identity request to sending them. The reason this was not MUST was that it might have been impossible to implement the EAP identity request skipping in some EAP libraries. The clear intention was that EAP Identity requests and replies SHOULD NOT be used. And the SHOULD there meant exactly what "SHOULD" means, i.e. "that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." I.e. the valid reason for not skipping identity request would have been that it is impossible because the EAP library does them automatically and they cannot be disabled. The bad thing about doing EAP identity request is that the policy lookups for the entity are NOT done based on them, but based on the ID payloads in the IKEv2. If the identity payloads mismatch (i.e. EAP payloads claim I am kivinen@iki.fi, but the ID payload claims I am paul.hoffman@vpnc.org), the authentication might still succeed as EAP library just uses the EAP identity payload to verify the credentials, but IKE library uses the ID sent in the IKE, and nobody matches that those two matches. BTW, I think we need to add some text that says those identities must match or at least you MUST use the EAP identity for access control and policy lookups, and also add some text to security considerations section. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 07:04:00 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C5B3A6BAB; Tue, 23 Sep 2008 07:04:00 -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 3E1D03A6C96 for ; Tue, 23 Sep 2008 07:03:59 -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 BaJWVMoVidm5 for ; Tue, 23 Sep 2008 07:03:58 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 8DCE33A6A47 for ; Tue, 23 Sep 2008 07:03:45 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NE3lWY016102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2008 17:03:47 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NE3lmi006902; Tue, 23 Sep 2008 17:03:47 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.63299.421119.516135@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 17:03:47 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 2 min X-Total-Time: 2 min Subject: [IPsec] INVALID_KE_PAYLOAD reply example X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 > > C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying CHILD_SAs > > > > request --> [N(REKEY_SA)], > > [CP(CFG_REQUEST)], > > [N(IPCOMP_SUPPORTED)+], > > [N(USE_TRANSPORT_MODE)], > > [N(ESP_TFC_PADDING_NOT_SUPPORTED)], > > [N(NON_FIRST_FRAGMENTS_ALSO)], > > SA, Ni, [KEi], TSi, TSr > > > > response <-- [CP(CFG_REPLY)], > > [N(IPCOMP_SUPPORTED)], > > [N(USE_TRANSPORT_MODE)], > > [N(ESP_TFC_PADDING_NOT_SUPPORTED)], > > [N(NON_FIRST_FRAGMENTS_ALSO)], > > SA, Nr, [KEr], TSi, TSr, > > [N(ADDITIONAL_TS_POSSIBLE)] > > And here: > > error case <-- N(error) > > > > invalid ke payload <-- N(INVALID_KE_PAYLOAD) > > next request with --> [N(REKEY_SA)], > new ke payload using [CP(CFG_REQUEST)], > group given by [N(IPCOMP_SUPPORTED)+], > invalid ke payload [N(USE_TRANSPORT_MODE)], > notify [N(ESP_TFC_PADDING_NOT_SUPPORTED)], > [N(NON_FIRST_FRAGMENTS_ALSO)], > SA, Ni, [KEi], TSi, TSr > (response would be same as in normal case). > > ===Done. Well, did the first two. The last is no different than > the original request. I suspect you wanted to change something > in it; if so, please re-submit. In the last example the actual payloads were same, only difference was the text which said "next request with new KE payload using group given by INVALID_KE_PAYLOAD notify", i.e. after INVALID_KE_PAYLOAD request you retry using exactly same payloads as before, but select different group for KE packet. Perhaps my description for the request was not clear enough. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 07:15:40 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 600B728C206; Tue, 23 Sep 2008 07:15: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 6AE4E28C206 for ; Tue, 23 Sep 2008 07:15:39 -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 7-PNRRngspti for ; Tue, 23 Sep 2008 07:15:32 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id E398828C1FE for ; Tue, 23 Sep 2008 07:15:24 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NEFQZN017844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 23 Sep 2008 17:15:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NEFQFY003910; Tue, 23 Sep 2008 17:15:26 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.63998.191263.660948@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 17:15:26 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 5 min X-Total-Time: 9 min Subject: [IPsec] Issue #33 Is TIGER specified? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1913875993==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1913875993== Content-Type: text/plain; charset=unknown Content-Transfer-Encoding: 7bit > > D.5. Changes from draft -02 to draft -03 > > PRF_HMAC_TIGER 3 (RFC2104) > > What is unspecified in tiger, does not the rfc 2104 specify how to use > PRF_HMAC_TIGER? > > ===Not done. The base spec for TIGER is not generally available. Wikipedia lists following reference: ---------------------------------------------------------------------- Ross Anderson and Eli Biham, Tiger ? A Fast New Hash Function, proceedings of Fast Software Encryption 3, Cambridge, 1996 http://www.cs.technion.ac.il/~biham/Reports/Tiger/tiger/tiger.html ---------------------------------------------------------------------- I think that should be generally available enough. -- kivinen@safenet-inc.com --===============1913875993== 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 --===============1913875993==-- From ipsec-bounces@ietf.org Tue Sep 23 07:21:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CBB228C21F; Tue, 23 Sep 2008 07:21:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B7028C222 for ; Tue, 23 Sep 2008 07:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUAnbru2-rIF for ; Tue, 23 Sep 2008 07:21:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 33AD328C21C for ; Tue, 23 Sep 2008 07:21:11 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NEL8Jo024735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 17:21:08 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NEL8V1002690; Tue, 23 Sep 2008 17:21:08 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.64340.108935.551146@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 17:21:08 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <6944AADF-9CE8-4E2D-80AF-7D077054F57F@checkpoint.com> References: <08E45D03-6381-48CD-A839-A24A4430A0A8@checkpoint.com> <18648.51633.237900.734643@fireball.kivinen.iki.fi> <6944AADF-9CE8-4E2D-80AF-7D077054F57F@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 3 min X-Total-Time: 5 min Cc: ipsec@ietf.org, Paul Hoffman Subject: Re: [IPsec] Issue #15: Message ID reset to 0 after IKE SA rekey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > I think that's a good idea, although what would they use for the > initial message ID for the new IKE SA. A random value? The MsgIDs > from the old SA? They used the message id from old SA. Some also misread the "The IKE_SA initial setup messages will always be number 0 and 1." to mean that no other messages can be with message id 0 or 1 than those IKE SA setup messages (i.e. they had special handling for message id 0 packets). > Paul, I think we can accept this and move that last sentence to the > main part of the message ID description. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 07:25:13 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A787F3A6959; Tue, 23 Sep 2008 07:25: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 70A8D3A6C8A for ; Tue, 23 Sep 2008 07:25:12 -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 jTG-YHPvQXIH for ; Tue, 23 Sep 2008 07:25:10 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 827F93A6B48 for ; Tue, 23 Sep 2008 07:24:48 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8NEOl3T023967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 17:24:47 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8NEOlfh007816; Tue, 23 Sep 2008 17:24:47 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18648.64559.897740.691521@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 17:24:47 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <5CA16549-5544-4114-9FAE-5C0BDFA4E060@checkpoint.com> References: <18648.53899.641720.849862@fireball.kivinen.iki.fi> <5CA16549-5544-4114-9FAE-5C0BDFA4E060@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #10 Specific Protocol ID values in REKEY_SA notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > How about: > The Protocol ID field of the REKEY_SA notification is > set to match the protocol of the SA we are rekeying, for > example, 3 for ESP and 2 for AH. That would be perfect for me. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 07:39:21 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745DB3A6998; Tue, 23 Sep 2008 07:39: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 003453A6998 for ; Tue, 23 Sep 2008 07:39:20 -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 XzNuW1dMYMlP for ; Tue, 23 Sep 2008 07:39:14 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 7811C3A67AF for ; Tue, 23 Sep 2008 07:39:14 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Ki92m-0000MP-UE; Tue, 23 Sep 2008 16:39:13 +0200 From: arno@natisbad.org (Arnaud Ebalard) To: Tero Kivinen References: <18648.57596.1776.816224@fireball.kivinen.iki.fi> X-PGP-Key-URL: http://natisbad.org/arno@natisbad.org.asc X-Fingerprint: 47EB 85FE B99A AB85 FD09 46F3 0255 957C 047A 5026 X-Hashcash: 1:20:080923:kivinen@iki.fi::OKFIgmg7ydDvyQN2:0000sW9 X-Hashcash: 1:20:080923:ipsec@ietf.org::gqWTV+5a2aX7sDZv:000106Q Date: Tue, 23 Sep 2008 16:37:34 +0200 In-Reply-To: <18648.57596.1776.816224@fireball.kivinen.iki.fi> (Tero Kivinen's message of "Tue, 23 Sep 2008 15:28:44 +0300") Message-ID: <87ej3blyhd.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #41 Interaction of MOBIKE with 'simple' IKE mobility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Tero Kivinen writes: >> > o There are cases where a NAT box decides to remove mappings that >> > are still alive (for example, the keepalive interval is too long, >> > or the NAT box is rebooted). To recover in these cases, hosts >> > that are not behind a NAT SHOULD send all packets (including >> > retransmission packets) to the IP address and port from the last >> > valid authenticated packet from the other end (i.e., dynamically >> > update the address). A host behind a NAT SHOULD NOT do this >> > because it opens a DoS attack possibility. Any authenticated IKE >> > packet or any authenticated UDP-encapsulated ESP packet can be >> > used to detect that the IP address or the port has changed. >> >> This paragraph should here point out that MOBIKE changes this behivor, >> and point to the MOBIKE documents for more information. >> >> ===Not done, but will most likely be. Supply exact text and discuss on >> the mailing list. > > New text: > > o There are cases where a NAT box decides to remove mappings that > are still alive (for example, the keepalive interval is too > long, or the NAT box is rebooted). To recover in these cases, > hosts that do not support other methods of recover (i.e. > MOBIKE), and that are not behind a NAT SHOULD send all packets > (including retransmission packets) to the IP address and port > from the last valid authenticated packet from the other end > (i.e., dynamically update the address). A host behind a NAT > SHOULD NOT do this because it opens a DoS attack possibility. > Any authenticated IKE packet or any authenticated > UDP-encapsulated ESP packet can be used to detect that the IP > address or the port has changed. When IKEv2 is used with MOBIKE, > the dynamically updating the addresses described above, > interfares with the MOBIKE's way of the recovering from the same ^^^^^^^^^^ ^^^ interfer? to be removed? > situation, so this method MUST NOT be used when MOBIKE is used. > See MOBIKE (RFC4555) section 3.8 for more information. Cheers, a+ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 08:02:49 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B627F3A6A5D; Tue, 23 Sep 2008 08:02:49 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB283A6A5D for ; Tue, 23 Sep 2008 08:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je4f5aX+Yi43 for ; Tue, 23 Sep 2008 08:02:48 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id A423B3A6B8F for ; Tue, 23 Sep 2008 08:02:47 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so704962eyd.31 for ; Tue, 23 Sep 2008 08:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=pjRBuM1pf2mo3AqnsQO8K8+ukgqOy8x5zxqO6ACLHc4=; b=PwIFE8CVMaaKerlI6Skh48CYEMtxYUcWExSDhaG2kSnahkWICA+KH4EKj6oLP82uKf ArEQhQoIoLj5zNpk1lODlYj6JT2GTe2Lgd1esnpnCLE2LyjUCYZ8CrpRrxQqFHjz3Ubo J2mgxpsY4eMO1xkDPkQWoVUO1wzodYeFNgR6c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=iZ/EKiKlm7qdpU7QU0x+YnsJF39d+f21c7Owkmzb3Ho8Dg7MUcxpLirzShuS7PoG1/ AMVhHMJV+qWbpWlGINcFhnalj8XT42J/41PsUYzd6rXF7Mjc7xi7B7D8D1J0rH3k3RCc Ov3m/JffOcqArJPvB0Fh9BtcLVmFdUEyYv8hU= Received: by 10.210.133.2 with SMTP id g2mr6784679ebd.68.1222182169319; Tue, 23 Sep 2008 08:02:49 -0700 (PDT) Received: by 10.210.115.8 with HTTP; Tue, 23 Sep 2008 08:02:49 -0700 (PDT) Message-ID: <1d38a3350809230802x3eef360am6a75f898d8efe7f6@mail.gmail.com> Date: Tue, 23 Sep 2008 23:02:49 +0800 From: "Hui Deng" To: "Tero Kivinen" In-Reply-To: <18647.42570.766912.651368@fireball.kivinen.iki.fi> MIME-Version: 1.0 References: <18642.12494.564286.298618@fireball.kivinen.iki.fi> <1d38a3350809200459m3f9d0216k30377fb443fb51f6@mail.gmail.com> <18647.42570.766912.651368@fireball.kivinen.iki.fi> Cc: Christian.Kaas-Petersen@tietoenator.com, ipsec@ietf.org Subject: Re: [IPsec] Use of IKE to obtain address of home agent X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0359725274==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0359725274== Content-Type: multipart/alternative; boundary="----=_Part_82748_6368746.1222182169307" ------=_Part_82748_6368746.1222182169307 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline thanks for your kind help to make it clarified. -Hui 2008/9/22 Tero Kivinen > Hui Deng writes: > > ==> I can't imagine the issue if we include two payloads even without an > > transaction ID here. could you help to elaborate more, bascially, I > assume > > there are consecutively ordered. > > There is nothing in the current documents that says that the reply > payloads inside the reply packet must be in same order the request > payloads were in the request packet. Thus complient implementation > would be allowed to reorder them if they want to. Thus the initiator > receiving the reply cannot know which reply payloads was reply to > which request payload. Complient recipient can also remove some of the > requested attributes, and add new ones, so detecting things from the > attributes might not be possible. We could add such text to IKEv2bis, > but I think it is better not to add multiple configuration payloads to > one packet. > -- > kivinen@safenet-inc.com > ------=_Part_82748_6368746.1222182169307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
thanks for your kind help to make it clarified.
 
-Hui

2008/9/22 Tero Kivinen <kivinen@iki.fi>
Hui Deng writes:
> ==> I can't imagine the issue if we include two payloads even without an
> transaction ID here. could you help to elaborate more, bascially, I assume
> there are consecutively ordered.

There is nothing in the current documents that says that the reply
payloads inside the reply packet must be in same order the request
payloads were in the request packet. Thus complient implementation
would be allowed to reorder them if they want to. Thus the initiator
receiving the reply cannot know which reply payloads was reply to
which request payload. Complient recipient can also remove some of the
requested attributes, and add new ones, so detecting things from the
attributes might not be possible. We could add such text to IKEv2bis,
but I think it is better not to add multiple configuration payloads to
one packet.
--
kivinen@safenet-inc.com

------=_Part_82748_6368746.1222182169307-- --===============0359725274== 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 --===============0359725274==-- From ipsec-bounces@ietf.org Tue Sep 23 08:32:36 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5AD3A6A05; Tue, 23 Sep 2008 08:32:35 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27FE73A6A05 for ; Tue, 23 Sep 2008 08:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJTN5Md4gZB2 for ; Tue, 23 Sep 2008 08:32:27 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 73E823A69E6 for ; Tue, 23 Sep 2008 08:32:26 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 544F1294002; Tue, 23 Sep 2008 18:32:29 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2CBEE294001 for ; Tue, 23 Sep 2008 18:32:28 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8NFWROx007019 for ; Tue, 23 Sep 2008 18:32:27 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 23 Sep 2008 18:32:27 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Tue, 23 Sep 2008 18:32:25 +0300 Thread-Topic: Issue Tracker (was RE: [IPsec] Issue #15: Message ID reset to 0 after IKE SA rekey) Thread-Index: Ackdh68FtekSPQd4T1Wezk/EgWX4HQACKoTA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E66E3@il-ex01.ad.checkpoint.com> References: <08E45D03-6381-48CD-A839-A24A4430A0A8@checkpoint.com> <18648.51633.237900.734643@fireball.kivinen.iki.fi> <6944AADF-9CE8-4E2D-80AF-7D077054F57F@checkpoint.com> <18648.64340.108935.551146@fireball.kivinen.iki.fi> In-Reply-To: <18648.64340.108935.551146@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] Issue Tracker (was RE: Issue #15: Message ID reset to 0 after IKE SA rekey) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2029519898==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2029519898== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001B_01C91DAA.B98903E0" ------=_NextPart_000_001B_01C91DAA.B98903E0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001C_01C91DAA.B98903E0" ------=_NextPart_001_001C_01C91DAA.B98903E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In case you were wondering, the ipsecme Issue Tracker is available at: http://trac.tools.ietf.org/wg/ipsecme/trac/report Right now all we have is Tero's comments on IKEv2-bis. But there are more coming. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Tuesday, September 23, 2008 17:21 To: Yoav Nir Cc: ipsec@ietf.org; Paul Hoffman Subject: Re: [IPsec] Issue #15: Message ID reset to 0 after IKE SA rekey Yoav Nir writes: > I think that's a good idea, although what would they use for the > initial message ID for the new IKE SA. A random value? The MsgIDs > from the old SA? They used the message id from old SA. Some also misread the "The IKE_SA initial setup messages will always be number 0 and 1." to mean that no other messages can be with message id 0 or 1 than those IKE SA setup messages (i.e. they had special handling for message id 0 packets). > Paul, I think we can accept this and move that last sentence to the > main part of the message ID description. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ------=_NextPart_001_001C_01C91DAA.B98903E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In case you were wondering, the ipsecme Issue Tracker is = available at: http://trac.to= ols.ietf.org/wg/ipsecme/trac/report

 

Right now all we have is Tero’s comments on IKEv2-bis. But = there are more coming.

 

Thanks,

      = Yaron

 

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Tero Kivinen
Sent: Tuesday, September 23, 2008 17:21
To: Yoav Nir
Cc: ipsec@ietf.org; Paul Hoffman
Subject: Re: [IPsec] Issue #15: Message ID reset to 0 after IKE SA = rekey

 

Yoav Nir = writes:

> I think that's a good idea, although what would they use = for the

> initial message ID for the new IKE SA.  A random = value?  The MsgIDs

> from the old SA?

 

They used the message id from old = SA.

 

Some also misread the "The IKE_SA initial setup messages = will always

be number 0 and 1." to mean that no other messages can be = with message

id 0 or 1 than those IKE SA setup messages (i.e. they had = special

handling for message id 0 packets).

 

> Paul, I think we can accept this and move that last = sentence to the

> main part of the message ID = description.

--

kivinen@safenet-inc.com

_______________________________________________=

IPsec mailing list

IPsec@ietf.org

https://www.ietf.org/mailman/listinfo/ipsec

 

Scanned by Check Point Total Security = Gateway.

------=_NextPart_001_001C_01C91DAA.B98903E0-- ------=_NextPart_000_001B_01C91DAA.B98903E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDkyMzE1MzIyNVowIwYJKoZIhvcNAQkEMRYEFCCMc9r9ALRa qh1pzAU0PsILcXy6MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA UecfhsTnb0ixefXTdv/5MIMB/Mvhn4xKwR8rPjREPQ6qiaiwMOk3TdY66/AShqyAjTtG68SVcnqn x1fhmTQ0ZzFZRZnVzatRIGpCMKgztKTywamvUOklFqaiy4Fnazm6/VP9ImJZ5M5grb2FTrXxcPVc HidbJWCqjGoAzJnxMW0WqhVbMWkTjo1W1dgK7Rr+46t92XOn7aX+0r+fLec4149EHXVSDS4KKsPB UgqKAa5zO+pVRWg3oLUQWFSOHLuGhlwWec1yUZHUQuKJrHvkF8vrose99+mUgsWulGA01NrJoA0D uN02ns9ZPHP7nSAcfYiTivzerJHbfusVpS4zAgAAAAAAAA== ------=_NextPart_000_001B_01C91DAA.B98903E0-- --===============2029519898== 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 --===============2029519898==-- From ipsec-bounces@ietf.org Tue Sep 23 08:34:53 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BF7B3A6AF7; Tue, 23 Sep 2008 08:34: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 B34BC3A6C1D for ; Tue, 23 Sep 2008 08:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 hRLxZpQFtcmd for ; Tue, 23 Sep 2008 08:34:50 -0700 (PDT) Received: from mailgate-internal4.sri.com (mailgate-internal4.SRI.COM [128.18.84.114]) by core3.amsl.com (Postfix) with SMTP id 8E1A33A6CF3 for ; Tue, 23 Sep 2008 08:34:30 -0700 (PDT) Received: from smssmtp-internal2.sri.com (128.18.84.116) by mailgate-internal4.sri.com with SMTP; 23 Sep 2008 15:34:33 -0000 X-AuditID: 80125474-aa995bb000000a40-38-48d90c89864d Received: from srimail1.sri.com (srimail1.SRI.COM [128.18.30.11]) by smssmtp-internal2.sri.com (Symantec Mail Security) with ESMTP id 22D7921AF2E for ; Tue, 23 Sep 2008 08:34:33 -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 <0K7N0047ON9KSVT4@mail.sri.com> for ipsec@ietf.org; Tue, 23 Sep 2008 08:34:33 -0700 (PDT) Date: Tue, 23 Sep 2008 11:34:36 -0400 From: Ed Jankiewicz To: ipsec@ietf.org Message-id: <48D90C8C.5000207@sri.com> MIME-version: 1.0 User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) X-Brightmail-Tracker: AAAAAA== Subject: [IPsec] OSPFv3 Authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I am not an active follower of current IPsec work, but have a question for this list. Please reply off-list unless your response would be generally interesting or trigger relevant discussion on the list. What (if any) current initiatives are there that would support automated key exchange for OSFPv3 authentication? RFC 4552 relies upon pre-shared secret keys for generating message digest, but some of my constituents have issues with manual generation, distribution and configuration of keys in their IPv6 network deployment. Is any of the current work on IKE revisions applicable, or is someone looking at OSPF specific solution? Thanks. -- 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 Sep 23 09:03:27 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC233A6B0D; Tue, 23 Sep 2008 09:03:27 -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 3A05F3A689A for ; Tue, 23 Sep 2008 09:03:26 -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 wsIl9Bya7WBe for ; Tue, 23 Sep 2008 09:03:25 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 013E93A6A2D for ; Tue, 23 Sep 2008 09:03:11 -0700 (PDT) Received: from [10.20.30.152] (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 m8NG39TE074344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 09:03:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18648.64340.108935.551146@fireball.kivinen.iki.fi> References: <08E45D03-6381-48CD-A839-A24A4430A0A8@checkpoint.com> <18648.51633.237900.734643@fireball.kivinen.iki.fi> <6944AADF-9CE8-4E2D-80AF-7D077054F57F@checkpoint.com> <18648.64340.108935.551146@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 09:03:08 -0700 To: Tero Kivinen , Yoav Nir From: Paul Hoffman Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #15: Message ID reset to 0 after IKE SA rekey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I'm fine with moving the current sentence up to the place where it is more useful. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 09:12:36 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFD0E28C225; Tue, 23 Sep 2008 09:12:35 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137CF28C20D for ; Tue, 23 Sep 2008 09:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHcQPmlkWG4t for ; Tue, 23 Sep 2008 09:12:33 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7DF083A6D0F for ; Tue, 23 Sep 2008 09:09:34 -0700 (PDT) Received: from [10.20.30.152] (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 m8NG9XKD074888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 09:09:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18648.49659.793457.85853@fireball.kivinen.iki.fi> References: <58FA415B-A01D-4C26-B56C-E40A7CA66EE7@checkpoint.com> <18648.49659.793457.85853@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 09:09:31 -0700 To: Tero Kivinen , Yoav Nir From: Paul Hoffman Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue 18: Port in anti-DoS cookie X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 1:16 PM +0300 9/23/08, Tero Kivinen wrote: >Yoav Nir writes: >> I suggest that unless someone can describe an attack on the current >> version, that we leave this as is. > >That is ok for me. > >This was mostly just something that popped up to my head when reading >the document, and as I didn't want to start wasting too much time >thinking it at that time, I just marked it down so it will get checked >down. I have not found out any working attack against the current >version so it can stay as it is now. OK, then we can close this one off. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 09:16:33 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91D223A6975; Tue, 23 Sep 2008 09:16: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 690963A6975 for ; Tue, 23 Sep 2008 09:16: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 Vc0IWAuQeM40 for ; Tue, 23 Sep 2008 09:16:31 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 670803A67CC for ; Tue, 23 Sep 2008 09:16:31 -0700 (PDT) Received: from [10.20.30.152] (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 m8NGGU7l075735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 09:16:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18648.64559.897740.691521@fireball.kivinen.iki.fi> References: <18648.53899.641720.849862@fireball.kivinen.iki.fi> <5CA16549-5544-4114-9FAE-5C0BDFA4E060@checkpoint.com> <18648.64559.897740.691521@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 09:13:35 -0700 To: Tero Kivinen , Yoav Nir From: Paul Hoffman Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #10 Specific Protocol ID values in REKEY_SA notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 5:24 PM +0300 9/23/08, Tero Kivinen wrote: >Yoav Nir writes: >> How about: >> The Protocol ID field of the REKEY_SA notification is >> set to match the protocol of the SA we are rekeying, for >> example, 3 for ESP and 2 for AH. > >That would be perfect for me. That works for me too. I thought Tero was trying to limit it to 2 and 3, not use them as examples. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 09:18:54 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B5C3A6B26; Tue, 23 Sep 2008 09:18: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 858353A6B26 for ; Tue, 23 Sep 2008 09:18: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAKcHu8J9Fx9 for ; Tue, 23 Sep 2008 09:18:49 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2115A3A6936 for ; Tue, 23 Sep 2008 09:18:48 -0700 (PDT) Received: from [10.20.30.152] (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 m8NGIoxV075925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 09:18:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18648.55467.488299.613222@fireball.kivinen.iki.fi> References: <18648.55467.488299.613222@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 09:18:47 -0700 To: Tero Kivinen , ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] Issue #20 Common use case for multiple proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 2:53 PM +0300 9/23/08, Tero Kivinen wrote: >Lets put it this way, I myself hadn't realized that we need support >for multiple proposals for this reason before we started to implement >combined mode ciphers for ESP. An implementer not getting this is good enough reason to put it in. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 09:32:32 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382903A6CE0; Tue, 23 Sep 2008 09:32: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 6353B3A6CE4 for ; Tue, 23 Sep 2008 09:32: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 pDHi6o6pmzJj for ; Tue, 23 Sep 2008 09:32:29 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 421793A6CE0 for ; Tue, 23 Sep 2008 09:32:29 -0700 (PDT) Received: from [10.20.30.152] (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 m8NGWS0S077396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 09:32:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18648.63299.421119.516135@fireball.kivinen.iki.fi> References: <18648.63299.421119.516135@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 09:32:27 -0700 To: Tero Kivinen , ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] INVALID_KE_PAYLOAD reply example X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 5:03 PM +0300 9/23/08, Tero Kivinen wrote: > > > C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying CHILD_SAs >> > >> > request --> [N(REKEY_SA)], >> > [CP(CFG_REQUEST)], >> > [N(IPCOMP_SUPPORTED)+], >> > [N(USE_TRANSPORT_MODE)], >> > [N(ESP_TFC_PADDING_NOT_SUPPORTED)], >> > [N(NON_FIRST_FRAGMENTS_ALSO)], >> > SA, Ni, [KEi], TSi, TSr >> > >> > response <-- [CP(CFG_REPLY)], >> > [N(IPCOMP_SUPPORTED)], >> > [N(USE_TRANSPORT_MODE)], >> > [N(ESP_TFC_PADDING_NOT_SUPPORTED)], >> > [N(NON_FIRST_FRAGMENTS_ALSO)], >> > SA, Nr, [KEr], TSi, TSr, >> > [N(ADDITIONAL_TS_POSSIBLE)] >> >> And here: >> >> error case <-- N(error) >> >> >> >> invalid ke payload <-- N(INVALID_KE_PAYLOAD) >> >> next request with --> [N(REKEY_SA)], >> new ke payload using [CP(CFG_REQUEST)], >> group given by [N(IPCOMP_SUPPORTED)+], >> invalid ke payload [N(USE_TRANSPORT_MODE)], >> notify [N(ESP_TFC_PADDING_NOT_SUPPORTED)], >> [N(NON_FIRST_FRAGMENTS_ALSO)], >> SA, Ni, [KEi], TSi, TSr >> (response would be same as in normal case). >> >> ===Done. Well, did the first two. The last is no different than >> the original request. I suspect you wanted to change something >> in it; if so, please re-submit. > >In the last example the actual payloads were same, only difference was >the text which said "next request with new KE payload using group >given by INVALID_KE_PAYLOAD notify", i.e. after INVALID_KE_PAYLOAD >request you retry using exactly same payloads as before, but select >different group for KE packet. Perhaps my description for the request >was not clear enough. If the format is the same, I don't see value in repeating it in this appendix. If it is not clear in the body that you send the normal format, we can add words there about it. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 09:32:33 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99D228C1FE; Tue, 23 Sep 2008 09:32: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 A4B5428C1FE for ; Tue, 23 Sep 2008 09:32: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qb1IxJa68iD for ; Tue, 23 Sep 2008 09:32:28 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 46E4B3A6C1D for ; Tue, 23 Sep 2008 09:32:28 -0700 (PDT) Received: from [10.20.30.152] (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 m8NGWS0Q077396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 09:32:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18648.59509.962691.554343@fireball.kivinen.iki.fi> References: <18648.59509.962691.554343@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 09:30:27 -0700 To: Tero Kivinen , ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] Issue #31 Clarification re: Cert Signature payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 4:00 PM +0300 9/23/08, Tero Kivinen wrote: > > > o X.509 Certificate - Signature (4) contains a DER encoded X.509 >> > certificate whose public key is used to validate the sender's AUTH >> > payload. >> >> That certificate can also bve used as part of the chain. I.e. add >> >> or used in the validation. >> >> to the end of that paragraph. >> >> ===Not done. It already says this. > >I bit disagree with this, as certificate that is used to sign the end >users certificate are not directly "used to validate the sender's AUTH >payload". It is used to validate the certificate used to validate >sender's AUTH payload, but it depends how strictly you interpret the >"sender's AUTH payload" part. That is a tortured view of validating. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 09:33:58 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8369F3A6C1D; Tue, 23 Sep 2008 09:33: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 92BD13A6A36 for ; Tue, 23 Sep 2008 09:33: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whToEBXK2FV2 for ; Tue, 23 Sep 2008 09:33:49 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 02AFF3A6C1D for ; Tue, 23 Sep 2008 09:33:46 -0700 (PDT) Received: from [10.20.30.152] (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 m8NGXlAO077752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 09:33:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18648.63998.191263.660948@fireball.kivinen.iki.fi> References: <18648.63998.191263.660948@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 09:33:46 -0700 To: Tero Kivinen , ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] Issue #33 Is TIGER specified? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 5:15 PM +0300 9/23/08, Tero Kivinen wrote: > > > D.5. Changes from draft -02 to draft -03 >> > PRF_HMAC_TIGER 3 (RFC2104) >> >> What is unspecified in tiger, does not the rfc 2104 specify how to use >> PRF_HMAC_TIGER? >> >> ===Not done. The base spec for TIGER is not generally available. > >Wikipedia lists following reference: >---------------------------------------------------------------------- >Ross Anderson and Eli Biham, Tiger ? A Fast New Hash Function, >proceedings of Fast Software Encryption 3, Cambridge, 1996 > >http://www.cs.technion.ac.il/~biham/Reports/Tiger/tiger/tiger.html >---------------------------------------------------------------------- >I think that should be generally available enough. Assuming that academic paper in someone's personal directory at their current or past employer will always be there, and won't change content, is maybe a bit silly. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 10:55:53 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51A0628C0E9; Tue, 23 Sep 2008 10:55: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 8B5EA3A6929 for ; Tue, 23 Sep 2008 10:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, 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 z8kSIX5h70w0 for ; Tue, 23 Sep 2008 10:55:51 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id EE5133A68D2 for ; Tue, 23 Sep 2008 10:55:50 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 326B1294003; Tue, 23 Sep 2008 20:55:54 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 41031294001; Tue, 23 Sep 2008 20:55:53 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8NHtqOx012187; Tue, 23 Sep 2008 20:55:52 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 23 Sep 2008 20:55:52 +0300 From: Yaron Sheffer To: Paul Hoffman , Tero Kivinen , "ipsec@ietf.org" Date: Tue, 23 Sep 2008 20:55:50 +0300 Thread-Topic: [IPsec] Issue #33 Is TIGER specified? Thread-Index: Ackdmjx+zKtVy5TIQauwROGRfcYgcwACzc0Q Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E670B@il-ex01.ad.checkpoint.com> References: <18648.63998.191263.660948@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] Issue #33 Is TIGER specified? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1719661400==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1719661400== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0031_01C91DBE.C2A0CE40" ------=_NextPart_000_0031_01C91DBE.C2A0CE40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Here's a "proper" reference, from a real book printed on real paper: Ross Anderson, Eli Biham, Tiger: A Fast New Hash Function, Fast Software Encryption 3, 1996, LNCS 1039 Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Tuesday, September 23, 2008 19:34 To: Tero Kivinen; ipsec@ietf.org Subject: Re: [IPsec] Issue #33 Is TIGER specified? At 5:15 PM +0300 9/23/08, Tero Kivinen wrote: > > > D.5. Changes from draft -02 to draft -03 >> > PRF_HMAC_TIGER 3 (RFC2104) >> >> What is unspecified in tiger, does not the rfc 2104 specify how to use >> PRF_HMAC_TIGER? >> >> ===Not done. The base spec for TIGER is not generally available. > >Wikipedia lists following reference: >---------------------------------------------------------------------- >Ross Anderson and Eli Biham, Tiger ? A Fast New Hash Function, >proceedings of Fast Software Encryption 3, Cambridge, 1996 > >http://www.cs.technion.ac.il/~biham/Reports/Tiger/tiger/tiger.html >---------------------------------------------------------------------- >I think that should be generally available enough. Assuming that academic paper in someone's personal directory at their current or past employer will always be there, and won't change content, is maybe a bit silly. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0031_01C91DBE.C2A0CE40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDkyMzE3NTU1MFowIwYJKoZIhvcNAQkEMRYEFK10pkwPwzVz zboq2R93nXQ6RMYVMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA QWhBcuGv8+97Xl9OrlM7crkpyomscpiWh529fmb7pHee+QbZKsK14YB5YVSjIgk9UfXnfKZU2ICN NTNhaM6z2fuL59pmUHhP8ZUbP0BPWJtlf81LfFoW1BkpglBrFdHignlcUTBLlEum6FLUhN8bHQ/n ClHKUbIU2OlbDqBMHk2easxZpEByHIlo3ZGHhvGyue0OabsnoKUDxEgiQci3FajRJ74TCvy3NcUA /TvIM3ZFbBSzmsJzYWCQztGSXUNF5/cTk+7Q7OlueFhTtWYHwRmVVdR5jsd9xwuEmzsZQAS/ZYmg d0qZ+hDuHl9edDNnq3kxtg4psGHh3+2TZ8uWVwAAAAAAAA== ------=_NextPart_000_0031_01C91DBE.C2A0CE40-- --===============1719661400== 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 --===============1719661400==-- From ipsec-bounces@ietf.org Tue Sep 23 11:32:37 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA1B03A68A6; Tue, 23 Sep 2008 11:32:37 -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 BA4273A6975 for ; Tue, 23 Sep 2008 11:32:36 -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 xTa5bhB5cLUz for ; Tue, 23 Sep 2008 11:32:36 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id B38BC3A68A6 for ; Tue, 23 Sep 2008 11:32:35 -0700 (PDT) Received: from [10.20.30.152] (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 m8NIWYWh088095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 11:32:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E670B@il-ex01.ad.checkpoint.com> References: <18648.63998.191263.660948@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E670B@il-ex01.ad.checkpoint.com> Date: Tue, 23 Sep 2008 11:32:32 -0700 To: Yaron Sheffer , Tero Kivinen , "ipsec@ietf.org" From: Paul Hoffman Subject: Re: [IPsec] Issue #33 Is TIGER specified? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 8:55 PM +0300 9/23/08, Yaron Sheffer wrote: >Here's a "proper" reference, from a real book printed on real paper: > >Ross Anderson, Eli Biham, >Tiger: A Fast New Hash Function, >Fast Software Encryption 3, 1996, LNCS 1039 The IPsec WG consciously decided to not move TIGER to IKEv2 partially because nearly no one had implemented it in IKEv1. Part of the reason that few implemented it in IKEv1 is that the spec was hard to get; part of the reason was that it was unclear what the advantage was. Have either of those changed? Is the book readily available? Is there any advantage over the current hash functions that outweigh the fact that TIGER has gone virtually unstudied in the crypto community relative to the hashes we are using? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 11:43:26 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09BA33A6B4F; Tue, 23 Sep 2008 11:43: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 2C63B3A69EF for ; Tue, 23 Sep 2008 11:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJgDww+ETFWS for ; Tue, 23 Sep 2008 11:43:20 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 282203A6B4F for ; Tue, 23 Sep 2008 11:43:20 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B6080294003; Tue, 23 Sep 2008 21:43:21 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A8F71294001; Tue, 23 Sep 2008 21:43:20 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8NIhJdr023729; Tue, 23 Sep 2008 21:43:19 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 23 Sep 2008 21:43:19 +0300 From: Yaron Sheffer To: Paul Hoffman , Tero Kivinen , "ipsec@ietf.org" Date: Tue, 23 Sep 2008 21:43:17 +0300 Thread-Topic: [IPsec] Issue #33 Is TIGER specified? Thread-Index: AckdqsIVkqgdbT4ITYm7EEwx7xZWZAAARiew Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E670E@il-ex01.ad.checkpoint.com> References: <18648.63998.191263.660948@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E670B@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] Issue #33 Is TIGER specified? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1236289664==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1236289664== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0036_01C91DC5.6386A0E0" ------=_NextPart_000_0036_01C91DC5.6386A0E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Paul, I don't understand. TIGER is in RFC 4306. The debate is only whether it is specified or not (which it clearly is, the Springer LNCS series is widely available), not whether it is secure, well-analyzed or anything else. Yaron -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Tuesday, September 23, 2008 21:33 To: Yaron Sheffer; Tero Kivinen; ipsec@ietf.org Subject: RE: [IPsec] Issue #33 Is TIGER specified? At 8:55 PM +0300 9/23/08, Yaron Sheffer wrote: >Here's a "proper" reference, from a real book printed on real paper: > >Ross Anderson, Eli Biham, >Tiger: A Fast New Hash Function, >Fast Software Encryption 3, 1996, LNCS 1039 The IPsec WG consciously decided to not move TIGER to IKEv2 partially because nearly no one had implemented it in IKEv1. Part of the reason that few implemented it in IKEv1 is that the spec was hard to get; part of the reason was that it was unclear what the advantage was. Have either of those changed? Is the book readily available? Is there any advantage over the current hash functions that outweigh the fact that TIGER has gone virtually unstudied in the crypto community relative to the hashes we are using? --Paul Hoffman, Director --VPN Consortium Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0036_01C91DC5.6386A0E0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDkyMzE4NDMxN1owIwYJKoZIhvcNAQkEMRYEFLzOMtsVZpGi 5AnmfXv6HV34ki2kMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA o80z50ufhv5sawj1Q8UWP2+W98FawK6rOdi0oWKJvEXLEtac6WvKnDRommcDxtWXtqnGBxp4Homu llgwSjlAAuKhV92jT7pxJ/nWSPQ/1a35RlEYd67EM8RW9Z2VYMrR+DqOUtohb5y6Ppb7VvIivBYY C0Ej2h9DuRLpnWp0SZUxgruqzRizLH1GAfm7wHbo0yqSSDLF+kNw0WHDWUJo3Otdec7PiBB5KpoK vheYOU21DEOlCqIu71eM3SA1iVtm0SYcRK8MG3KSIHjyWuhyMuannPWKLn9I45Fvo9CXQ8BWzUPt je+U84lcTL3dMbzNB+nrd30ZOtMg+z/GOMTJJQAAAAAAAA== ------=_NextPart_000_0036_01C91DC5.6386A0E0-- --===============1236289664== 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 --===============1236289664==-- From ipsec-bounces@ietf.org Tue Sep 23 12:01:57 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD8A28C248; Tue, 23 Sep 2008 12:01: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 68A1928C261 for ; Tue, 23 Sep 2008 12:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 j3XRFUUr1+oR for ; Tue, 23 Sep 2008 12:01:50 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) by core3.amsl.com (Postfix) with ESMTP id C417028C247 for ; Tue, 23 Sep 2008 12:01:23 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-MimeOLE:Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: In-Reply-To:X-MS-Has-Attach:X-MS-TNEF-Correlator: Thread-Topic:Thread-Index:References:From:To:Return-Path: X-OriginalArrivalTime; b=px9i8pTz5fVEVQh6/Kg2WoPoxUBFtLyeka7F8UH3vaTjclYlFrRQB3Yx Aj3ZTd5UbZzowzun0C/fe4gPNGCSMUSXnzKfz9bK2PPgDf5/VCCkHGOVX M8z23pd7N7RB1TA; X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 23 Sep 2008 14:01:09 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Issue #33 Is TIGER specified? Thread-Index: AckdqsgHiFMtn/2CRdiWXyF7+LfnRQAA1qRQ References: <18648.63998.191263.660948@fireball.kivinen.iki.fi><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E670B@il-ex01.ad.checkpoint.com> From: To: , , , X-OriginalArrivalTime: 23 Sep 2008 19:01:20.0755 (UTC) FILETIME=[C40E3430:01C91DAE] Subject: Re: [IPsec] Issue #33 Is TIGER specified? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 8:55 PM +0300 9/23/08, Yaron Sheffer wrote: >>Here's a "proper" reference, from a real book printed on real paper: >> >>Ross Anderson, Eli Biham, >>Tiger: A Fast New Hash Function, >>Fast Software Encryption 3, 1996, LNCS 1039 > >The IPsec WG consciously decided to not move TIGER to IKEv2 partially >because nearly no one had implemented it in IKEv1. Part of the reason >that few implemented it in IKEv1 is that the spec was hard to get; >part of the reason was that it was unclear what the advantage was. > >Have either of those changed? Is the book readily available? Is there >any advantage over the current hash functions that outweigh the fact >that TIGER has gone virtually unstudied in the crypto community >relative to the hashes we are using? I think those are crucial questions. Crypto doesn't benefit from having lots of choices; it benefits from having a very small number of very well understood choices. AES and DES, SHA and MD5 -- those are functions that fit this test. There are a whole bunch of ciphers and hashes in the "probably ok" and "not well known" category. Having those in the spec isn't doing anyone any favors; there is no reason to believe that doing so improves the security of the system, and significant reason to worry that it might hurt. Certainly the authors of Tiger are highly qualified cryptographers, and that is a fine start, but it's only a start, and until / unless the additional work happens, I don't see that it has met the threshold for being included in IKE. paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 12:08:49 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFBEF3A695E; Tue, 23 Sep 2008 12:08:49 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AC983A695E for ; Tue, 23 Sep 2008 12:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TQRNbYex-Jw for ; Tue, 23 Sep 2008 12:08:42 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 954A03A690B for ; Tue, 23 Sep 2008 12:08:41 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 50301294002; Tue, 23 Sep 2008 22:08:32 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 413A3294001; Tue, 23 Sep 2008 22:08:31 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8NJ8U5d001581; Tue, 23 Sep 2008 22:08:30 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 23 Sep 2008 22:08:30 +0300 From: Yaron Sheffer To: "Paul_Koning@Dell.com" , "paul.hoffman@vpnc.org" , "kivinen@iki.fi" , "ipsec@ietf.org" Date: Tue, 23 Sep 2008 22:08:27 +0300 Thread-Topic: [IPsec] Issue #33 Is TIGER specified? Thread-Index: AckdqsgHiFMtn/2CRdiWXyF7+LfnRQAA1qRQAAAubpA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E6712@il-ex01.ad.checkpoint.com> References: <18648.63998.191263.660948@fireball.kivinen.iki.fi><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E670B@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] Issue #33 Is TIGER specified? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0468939146==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0468939146== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003B_01C91DC8.E7E24440" ------=_NextPart_000_003B_01C91DC8.E7E24440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We are not changing IKE in IKEv2-bis. Only clarifying it. So we need an *extremely* good reason to reopen decisions made in RFC 4306, including decisions related to the choice of algorithms. Yaron -----Original Message----- From: Paul_Koning@Dell.com [mailto:Paul_Koning@Dell.com] Sent: Tuesday, September 23, 2008 22:01 To: paul.hoffman@vpnc.org; Yaron Sheffer; kivinen@iki.fi; ipsec@ietf.org Subject: RE: [IPsec] Issue #33 Is TIGER specified? >At 8:55 PM +0300 9/23/08, Yaron Sheffer wrote: >>Here's a "proper" reference, from a real book printed on real paper: >> >>Ross Anderson, Eli Biham, >>Tiger: A Fast New Hash Function, >>Fast Software Encryption 3, 1996, LNCS 1039 > >The IPsec WG consciously decided to not move TIGER to IKEv2 partially >because nearly no one had implemented it in IKEv1. Part of the reason >that few implemented it in IKEv1 is that the spec was hard to get; >part of the reason was that it was unclear what the advantage was. > >Have either of those changed? Is the book readily available? Is there >any advantage over the current hash functions that outweigh the fact >that TIGER has gone virtually unstudied in the crypto community >relative to the hashes we are using? I think those are crucial questions. Crypto doesn't benefit from having lots of choices; it benefits from having a very small number of very well understood choices. AES and DES, SHA and MD5 -- those are functions that fit this test. There are a whole bunch of ciphers and hashes in the "probably ok" and "not well known" category. Having those in the spec isn't doing anyone any favors; there is no reason to believe that doing so improves the security of the system, and significant reason to worry that it might hurt. Certainly the authors of Tiger are highly qualified cryptographers, and that is a fine start, but it's only a start, and until / unless the additional work happens, I don't see that it has met the threshold for being included in IKE. paul ------=_NextPart_000_003B_01C91DC8.E7E24440 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDkyMzE5MDgyN1owIwYJKoZIhvcNAQkEMRYEFOxR0mVHgiDi nn2+r822wa791r1SMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA QUbrdtwia55z/Pc5nRgeMDh62TepIPX9moLImmFgJ+0+G1ZiNuznPd9wTOdSWIhNiIUuIG877viw lpwdSueR0l5pBUvk8g/sMMBXs8EyV6lhuv80mk3rV2n75xHkM0RcHwuykx6St/APIZ/Xyvv1wFbY yYPKIrMr/m7eoknwnZDz1+OV2REmQck+U7V5cLn3IWcOgYxncPM2F6+hhjRODkSzgdjZh+TPzCqB rqh3j8nPAtZcRZk48HnrS0kFaT96aSrUowpTh5yOt+2BCcPqC0mGr4qvxW9jljgjpqKvCS/lSQoJ wwFYvPmtCOkiIv0NW2kt7KXdR3A65g/2OYbpMQAAAAAAAA== ------=_NextPart_000_003B_01C91DC8.E7E24440-- --===============0468939146== 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 --===============0468939146==-- From ipsec-bounces@ietf.org Tue Sep 23 12:40:11 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FAA928C25E; Tue, 23 Sep 2008 12:40:11 -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 36E9428C255 for ; Tue, 23 Sep 2008 12:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yidhYovdKZMM for ; Tue, 23 Sep 2008 12:40:08 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 2731128C25D for ; Tue, 23 Sep 2008 12:40:07 -0700 (PDT) Received: from [10.20.30.152] (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 m8NJe2jC093506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 12:40:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E6712@il-ex01.ad.checkpoint.com> References: <18648.63998.191263.660948@fireball.kivinen.iki.fi><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E670B@il-ex01.ad.chec kpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E6712@il-ex01.ad.checkpoint.com> Date: Tue, 23 Sep 2008 12:40:01 -0700 To: Yaron Sheffer , "Paul_Koning@Dell.com" , "kivinen@iki.fi" , "ipsec@ietf.org" From: Paul Hoffman Subject: Re: [IPsec] Issue #33 Is TIGER specified? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 10:08 PM +0300 9/23/08, Yaron Sheffer wrote: >We are not changing IKE in IKEv2-bis. Only clarifying it. So we need an >*extremely* good reason to reopen decisions made in RFC 4306, including >decisions related to the choice of algorithms. My apologies. I got two issues mixed up. RFC 4306 points to RFC 2104 for the definition of PRF_HMAC_TIGER. However, RFC 2104 doesn't mention Tiger, that is why I took off the pointer in IKEv2bis. I now see that I should have left it there because RFC 2104 says that it works with any interative hash function. We discussed in the IPsec WG getting rid of Tiger *as a hash function*, and I think there was agreement to do so. But that's irrelevant to this discussion. I'll revert the reference in the next version of the draft. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 12:56:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E79D3A6CD0; Tue, 23 Sep 2008 12:56: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 B43B128C231 for ; Tue, 23 Sep 2008 12:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4DfNduifF+vU for ; Tue, 23 Sep 2008 12:56:48 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id 8652D28C24F for ; Tue, 23 Sep 2008 12:56:47 -0700 (PDT) Received: from d03relay05 (d03relay05.boulder.ibm.com [9.17.195.107]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8NJuo55031590 for ; Tue, 23 Sep 2008 15:56:50 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay05 (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8NJujAg124408 for ; Tue, 23 Sep 2008 13:56:45 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8O1ujKm021058 for ; Tue, 23 Sep 2008 19:56:45 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8O1ujUV021050 for ; Tue, 23 Sep 2008 19:56:45 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 09/23/2008 12:56:45 PM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 09/23/2008 12:56:45 PM, Serialize complete at 09/23/2008 12:56:45 PM, S/MIME Sign failed at 09/23/2008 12:56:45 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_M2_08202008HFIGS1|August 20, 2008) at 09/23/2008 13:56:44, Serialize complete at 09/23/2008 13:56:44 Message-ID: Date: Tue, 23 Sep 2008 12:56:44 -0700 Subject: [IPsec] INVALID_IKE_SPI questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0532295976==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0532295976== Content-Type: multipart/alternative; boundary="=_alternative 006D9105882574CD_=" This is a multipart message in MIME format. --=_alternative 006D9105882574CD_= Content-Type: text/plain; charset="US-ASCII" For the one-way INVALID_IKE_SPI notification described in RFC 4306 section 1.5, it is unclear to me what the Exchange Type should be in the IKE header. Should it be 37 (INFORMATIONAL) or should it be copied from the request that contained the unrecognized SPI? Keith Welter IBM Enterprise Networking Solutions 1-415-545-2694 (T/L: 473-2694) --=_alternative 006D9105882574CD_= Content-Type: text/html; charset="US-ASCII"
For the one-way INVALID_IKE_SPI notification described in RFC 4306 section 1.5, it is unclear to me what the Exchange Type should be in the IKE header.  Should it be 37 (INFORMATIONAL) or should it be copied from the request that contained the unrecognized SPI?  

Keith Welter
IBM Enterprise Networking Solutions
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 006D9105882574CD_=-- --===============0532295976== 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 --===============0532295976==-- From ipsec-bounces@ietf.org Tue Sep 23 14:51:15 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CE0228C26C; Tue, 23 Sep 2008 14:51:15 -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 B74EF28C26C for ; Tue, 23 Sep 2008 14:51: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 cKSgD0zyMiMg for ; Tue, 23 Sep 2008 14:51:12 -0700 (PDT) Received: from cavuit01.kulnet.kuleuven.be (cavuit01.kulnet.kuleuven.be [134.58.240.43]) by core3.amsl.com (Postfix) with ESMTP id 932BC28C245 for ; Tue, 23 Sep 2008 14:51:12 -0700 (PDT) Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be [134.58.240.74]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id A76D77B8047; Tue, 23 Sep 2008 23:51:14 +0200 (CEST) Received: from smtps01.kuleuven.be (localhost [127.0.0.1]) by smtps01.kuleuven.be (Postfix) with ESMTP id 5A14631E705; Tue, 23 Sep 2008 23:51:14 +0200 (CEST) Received: from bezout.esat.kuleuven.be (bezout.esat.kuleuven.be [134.58.189.101]) by smtps01.kuleuven.be (Postfix) with ESMTP id 4657431E704; Tue, 23 Sep 2008 23:51:14 +0200 (CEST) Date: Tue, 23 Sep 2008 23:51:14 +0200 (CEST) X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Bart Preneel X-X-Sender: preneel@bezout To: Paul_Koning@Dell.com In-Reply-To: Message-ID: References: <18648.63998.191263.660948@fireball.kivinen.iki.fi><7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E670B@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 X-KULeuven-Information: Katholieke Universiteit Leuven X-KULeuven-Scanned: Found to be clean X-KULeuven-Envelope-From: bart.preneel@esat.kuleuven.be Cc: ipsec@ietf.org, paul.hoffman@vpnc.org, kivinen@iki.fi Subject: Re: [IPsec] Issue #33 Is TIGER specified? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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, 23 Sep 2008 Paul_Koning@Dell.com wrote: > I think those are crucial questions. Crypto doesn't benefit from having lots of choices; it benefits from having a very small number of very well understood choices. AES and DES, SHA and MD5 -- those are functions that fit this test. There are a whole bunch of ciphers and hashes in the "probably ok" and "not well known" category. Having those in the spec isn't doing anyone any favors; there is no reason to believe that doing so improves the security of the system, and significant reason to worry that it might hurt. > > Certainly the authors of Tiger are highly qualified cryptographers, and that is a fine start, but it's only a start, and until / unless the additional work happens, I don't see that it has met the threshold for being included in IKE. > > paul Tiger (designed in 1996) was intended to offer a security level against collision attacks that is substantially higher than SHA-1 and RIPEMD-160 (2**96 rather than 2**80). While there is no shortcut collision attack on Tiger today, there exist certificational attacks that suggest that the security margin of the Tiger design is small (details below); a collision attack in 2**80 seems within reach but would require more research (remember the progress that has been made in attacking MD4 and MD5 over a decade). However, there will be little interest in the cryptanalytic community to try to improve the current attacks on Tiger given that NIST's AHS competition will break loose 6 weeks from now. --Bart ------------------------------------------------------------------------- Florian Mendel, Vincent Rijmen: Cryptanalysis of the Tiger Hash Function. ASIACRYPT 2007: 536-550 Abstract. Tiger is a cryptographic hash function with a 192-bit hash value. It was proposed by Anderson and Biham in 1996. Recently, weaknesses have been shown in round-reduced variants of the Tiger hash function. First, at FSE 2006, Kelsey and Lucks presented a collision attack on Tiger reduced to 16 and 17 (out of 24) rounds with a complexity of about 2**44 and a pseudo-near-collision for Tiger reduced to 20 rounds. Later, Mendel et al. extended this attack to a collision attack on Tiger reduced to 19 rounds with a complexity of about 2**62. Furthermore, they show a pseudo-near-collision for Tiger reduced to 22 rounds with a complexity of about 244. No attack is known for the full Tiger hash function. In this article, we show a pseudo-near-collision for the full Tiger hash function with a complexity of about 2**47 hash computations and a pseudocollision (free-start-collision) for Tiger reduced to 23 rounds with the same complexity. ------------------------------------------------------------------------- Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 15:46:13 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEE4028C276; Tue, 23 Sep 2008 15:46: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 3EAAD28C276 for ; Tue, 23 Sep 2008 15:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z8kR5RCq3Hx for ; Tue, 23 Sep 2008 15:46:11 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 29F9328C266 for ; Tue, 23 Sep 2008 15:46:10 -0700 (PDT) Received: from [10.20.30.152] (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 m8NMkCbx008251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 15:46:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18648.59003.22895.803651@fireball.kivinen.iki.fi> References: <18648.59003.22895.803651@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 15:46:10 -0700 To: Tero Kivinen , ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] Issue #42 Improve example of multiple proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:52 PM +0300 9/23/08, Tero Kivinen wrote: > The Proposal structure contains within it a Proposal # and an IPsec > protocol ID. Each structure MUST have a proposal number one (1) > greater than the previous structure. The first Proposal in the > initiator's SA payload MUST have a Proposal # of one (1). A common > reason to use multiple proposals is when used with combined mode > ciphers. Combined mode ciphers include both integrity and > encryption in single encryption algorithm. Because of this it is > not allowed to have combined mode ciphers with an another integrity > algorithm, thus proposal must not have any integrity algorithms > (other than NONE). If initiator want to propose both combine mode > ciphers and normal ciphers, it must include two proposals. One will > have all combined mode ciphers, and no integrity algorithm. The > other will have all non-combined mode ciphers and all allowed > integrity algorithms with them. For example such proposal would > have two proposal structures, one for ESP with ENCR_AES-CCM_8, > ENCR_AES-CCM_12, and ENCR_AES-CCM_16 as Proposal #1 and one for ESP > with ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and > AUTH_HMAC_SHA1_96 as Proposal #2. I'm coming around on us having to talk about combined-mode ciphers where they are needed here. The above text (with a bit of editorial change) is a good example of why we would have multiple proposals. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 15:56:14 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BAE33A68FF; Tue, 23 Sep 2008 15:56: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 A54773A68FF for ; Tue, 23 Sep 2008 15:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpzHwP2zfyMf for ; Tue, 23 Sep 2008 15:56:12 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 9BA813A67ED for ; Tue, 23 Sep 2008 15:56:11 -0700 (PDT) Received: from [10.20.30.152] (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 m8NMuD89009121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 15:56:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18648.57993.707815.94580@fireball.kivinen.iki.fi> References: <18648.57993.707815.94580@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 15:56:00 -0700 To: Tero Kivinen , ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] Issue #29 Need to clarify Exchange Type field X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:35 PM +0300 9/23/08, Tero Kivinen wrote: > > > o Exchange Type (1 octet) - Indicates the type of exchange being >> > used. This constrains the payloads sent in each message and >> > orderings of messages in an exchange. >> ^^^^^^^^^ >> >> What does that try to say? >> >> ===Not done. It is saying that exchange types can impose orderings. > >Then I think it is not really true. Each exchange consists of request >and reply pair, and exchanges can follow each other in certain order, >but as there is only 2 messages in an exchange (one request and one >reply), I do not think exchange type can really constraint order of >the messages in an exchange (ok, I think it is implictly understood >that request comes before reply, and you are not allowed to respond >with a reply to request, before the request is sent, but I still think >the word there is just confusing and not helping at all). > >Section 1 explains exchange to be: > > All IKE communications consist of pairs of messages: a request and a > response. The pair is called an "exchange". > >So no exchange can have more than 2 messages. My mistake. I thought EAP authentication was done in "an exchange", I have made the above change, and have replaced "EAP exchange" in the security considerations with better language. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 16:02:44 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2F828C289; Tue, 23 Sep 2008 16:02:44 -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 6265D28C289 for ; Tue, 23 Sep 2008 16:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqt4k6r-CVpE for ; Tue, 23 Sep 2008 16:02:42 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 25F7828C27F for ; Tue, 23 Sep 2008 16:02:41 -0700 (PDT) Received: from [10.20.30.152] (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 m8NN2hX2009547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 16:02:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18648.62020.138458.908262@fireball.kivinen.iki.fi> References: <18648.62020.138458.908262@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 16:02:41 -0700 To: Tero Kivinen , ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 4:42 PM +0300 9/23/08, Tero Kivinen wrote: > > > 3.14. Encrypted Payload >> > >> > The Encrypted Payload, denoted SK{...} or E in this memo, contains >> > other payloads in encrypted form. The Encrypted Payload, if present >> > in a message, MUST be the last payload in the message. Often, it is >> > the only payload in the message. >> > >> > The algorithms for encryption and integrity protection are negotiated >> > during IKE_SA setup, and the keys are computed as specified in >> > Section 2.14 and Section 2.18. >> > >> > This document specifies the cryptographic processing of Encrypted >> > payloads using a block cipher in CBC mode and an integrity check >> > algorithm that computes a fixed-length checksum over a variable size >> > message. The design is modeled after the ESP algorithms described in >> >> As we already has document which describes how to use other ciphers in >> the IKE, we at least put the reference to there, or even incorporate >> the changes specified in there to this document. Especially as the >> RFCF 4307 specifies ENCR_AES_CTR as SHOULD for the IKEv2... >> >> ===Done. Well, not the way that you wanted. I will send in an errata to >> RFC 4307 saying that AES_CTR should not have been listed. > >I think the AES_CTR can be used to protect the IKEv2 SA without any >problems. The RFC3686 already describes evertything that is needed to >use it. ...except how to do so in IKEv2. RFC 3686 is, obviously, for IKEv1 only. >The only difference to the CBC mode is, is the way how IV for >the AES_CTR is generated. The RFC4306 only points to "Recommendation >for Block Cipher Modes of Operation" document for advises for IV >generation. Only think that would not really be needed for IV >selection is the text in the RFC4306 which says that IV must be >unpredictable. The counter mode ciphers do not require >unpredictability but they do require uniqueness. And this will help bits-on-the-wire interoperability in what way? :-) >Anyways RFC3686 already describes the way how the IV should be >generated for AES_CTR, and I do not see any reason why the the text >which previously allowed CTR now needs to forbid CTR modes and only >allow CBC modes. That's not what I am saying: I'm saying that it was a mistake to list ENCR_AES_CTR as RFC3686 unless that RFC describes how to use it in IKEv2, which it doesn't. There is nothing stopping someone from writing a revision to RFC 3686 to describe this. >This is again protocol change that will change bits >on the wire (i.e making CTR mode in IKEv2 SA to be unspecified even >when it was previously specified). Unless I am missing something, it is not specified: it is unspecified but you could try to guess from RFC 3686. >Note, that RFC5282 "Using Authenticated Encryption Algorithms with the >Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) >Protocol" do NOT include AES-CTR description there. It only includes >combined modes, which were unspecified in IKEv2 SAs before. ...but are fully specified there. >Couldn't find issue number for this from the tracker, so could not put >reference to it. I don't see it either. Yaron, can you add this one as "open"? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 16:05:02 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75EBA28C291; Tue, 23 Sep 2008 16:05:02 -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 BE9CC28C28C for ; Tue, 23 Sep 2008 16:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IO-9R2QuPaiS for ; Tue, 23 Sep 2008 16:05:00 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 96CEB28C27F for ; Tue, 23 Sep 2008 16:04:59 -0700 (PDT) Received: from [10.20.30.152] (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 m8NN516M009740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 16:05:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18648.57596.1776.816224@fireball.kivinen.iki.fi> References: <18648.57596.1776.816224@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 16:04:59 -0700 To: Tero Kivinen , ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] Issue #41 Interaction of MOBIKE with 'simple' IKE mobility X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:28 PM +0300 9/23/08, Tero Kivinen wrote: > > > o There are cases where a NAT box decides to remove mappings that >> > are still alive (for example, the keepalive interval is too long, >> > or the NAT box is rebooted). To recover in these cases, hosts >> > that are not behind a NAT SHOULD send all packets (including >> > retransmission packets) to the IP address and port from the last >> > valid authenticated packet from the other end (i.e., dynamically >> > update the address). A host behind a NAT SHOULD NOT do this >> > because it opens a DoS attack possibility. Any authenticated IKE >> > packet or any authenticated UDP-encapsulated ESP packet can be >> > used to detect that the IP address or the port has changed. >> >> This paragraph should here point out that MOBIKE changes this behivor, >> and point to the MOBIKE documents for more information. >> >> ===Not done, but will most likely be. Supply exact text and discuss on >> the mailing list. > >New text: > > o There are cases where a NAT box decides to remove mappings that > are still alive (for example, the keepalive interval is too > long, or the NAT box is rebooted). To recover in these cases, > hosts that do not support other methods of recover (i.e. > MOBIKE), and that are not behind a NAT SHOULD send all packets > (including retransmission packets) to the IP address and port > from the last valid authenticated packet from the other end > (i.e., dynamically update the address). A host behind a NAT > SHOULD NOT do this because it opens a DoS attack possibility. > Any authenticated IKE packet or any authenticated > UDP-encapsulated ESP packet can be used to detect that the IP > address or the port has changed. When IKEv2 is used with MOBIKE, > the dynamically updating the addresses described above, > interfares with the MOBIKE's way of the recovering from the same > situation, so this method MUST NOT be used when MOBIKE is used. > See MOBIKE (RFC4555) section 3.8 for more information. >-- This works for me. How do other MOBIKE folks feel? --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 16:15:46 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC693A6CCD; Tue, 23 Sep 2008 16:15: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 431B53A6CCD for ; Tue, 23 Sep 2008 16:15:46 -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 Vh4SiJaFYI5G for ; Tue, 23 Sep 2008 16:15:45 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1CB803A69C1 for ; Tue, 23 Sep 2008 16:15:44 -0700 (PDT) Received: from [10.20.30.152] (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 m8NNFkME010667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Sep 2008 16:15:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18648.57073.992710.756960@fireball.kivinen.iki.fi> References: <18648.57073.992710.756960@fireball.kivinen.iki.fi> Date: Tue, 23 Sep 2008 16:15:44 -0700 To: Tero Kivinen , ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] Issue #27 Motivation for using port 4500 vs. 500 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:20 PM +0300 9/23/08, Tero Kivinen wrote: > > > sent to the port from whence they came. This is because the ports >> > may be modified as the packets pass through NATs. Similarly, IP >> > addresses of the IKE endpoints are generally not included in the IKE >> > payloads because the payloads are cryptographically protected and >> > could not be transparently modified by NATs. >> > >> > Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working >> > through a NAT, it is generally better to pass IKE packets over port >> > 4500 because some older NATs handle IKE traffic on port 500 cleverly >> > in an attempt to transparently establish IPsec connections between >> > endpoints that don't handle NAT traversal themselves. Such NATs may >> > interfere with the straightforward NAT traversal envisioned by this >> > document. >> >> Everything after the first sentence in the paragraph is just >> misleading and should be removed. >> >> ===Not done. This was generally agreed to, I believe. > >The text in sense is true, but it is not really relevant with the >current IKEv2. It was relevant in the case where people still tried to >run the same kind of NAT-T protocols over port 500. In the current >document I think it is just much better to say that you MUST use port >4500 if NAT is detected. This is already said here: > > The IKE initiator MUST check these payloads if present and if they > do not match the addresses in the outer packet MUST tunnel all > future IKE and ESP packets associated with this IKE_SA over UDP > port 4500. > >So as current conforming IKEv2 implementations cannot use port 500 >when NAT is detected, I think it is bit misleading to explain >something that it is better to do xxx if you are anyways required to >do xxx. OK I see that now. The text you want removed is *above* the text below, outside of the optional NAT-traversal requirements. (And, yes, I did mean to use "optional" and "requirements" in that sentence.) But I can see that the supposedly-helpful text could actually lead to a developer using 500 anyway for some bad reason. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 23 23:41:30 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29FFD3A6D39; Tue, 23 Sep 2008 23:41:30 -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 1136A3A6D39 for ; Tue, 23 Sep 2008 23:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.116, 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 cYseuvXK2Fgn for ; Tue, 23 Sep 2008 23:41:28 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D45B13A6D2A for ; Tue, 23 Sep 2008 23:41:27 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 26A8F294002; Wed, 24 Sep 2008 09:41:32 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3697D294001; Wed, 24 Sep 2008 09:41:31 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8O6fUSJ001838; Wed, 24 Sep 2008 09:41:30 +0300 (IDT) Message-Id: From: Yoav Nir To: Paul Hoffman In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 24 Sep 2008 08:42:40 +0300 References: <18648.57993.707815.94580@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Issue #29 Need to clarify Exchange Type field X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Sep 24, 2008, at 1:56 AM, Paul Hoffman wrote: >> >> Then I think it is not really true. Each exchange consists of request >> and reply pair, and exchanges can follow each other in certain order, >> but as there is only 2 messages in an exchange (one request and one >> reply), I do not think exchange type can really constraint order of >> the messages in an exchange (ok, I think it is implictly understood >> that request comes before reply, and you are not allowed to respond >> with a reply to request, before the request is sent, but I still >> think >> the word there is just confusing and not helping at all). >> >> Section 1 explains exchange to be: >> >> All IKE communications consist of pairs of messages: a request >> and a >> response. The pair is called an "exchange". >> >> So no exchange can have more than 2 messages. > > My mistake. I thought EAP authentication was done in "an exchange", > > I have made the above change, and have replaced "EAP exchange" in > the security considerations with better language. I understood it the same way as Paul. This makes the term "exchange" much less useful. For example, in the EAP case traffic selectors are proposed in one exchange, while the reply with the final selectors comes in a totally different exchange. This doesn't make much sense. The several request-reply pairs there are all related in that they negotiate the same thing, and up to now, I thought the term for this was "exchange". I would rather re-define "exchange" so that all the IKE_AUTH round- trips are one exchange rather than having to invent a new concept (maybe revive the term "mode") to define the state machine for authentication. Obviously that state machine can't reach a final state after the first response. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 24 01:57:57 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB35D3A6D71; Wed, 24 Sep 2008 01:57: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 D76703A6D44 for ; Wed, 24 Sep 2008 01:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.956 X-Spam-Level: X-Spam-Status: No, score=-5.956 tagged_above=-999 required=5 tests=[AWL=0.643, 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 fQLOzJKuue-v for ; Wed, 24 Sep 2008 01:57:56 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id DE58F3A6D71 for ; Wed, 24 Sep 2008 01:57:55 -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 m8O8vekd031485; Wed, 24 Sep 2008 11:57:46 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Sep 2008 11:56:44 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Sep 2008 11:56:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 24 Sep 2008 11:56:42 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB7201B3F91B@vaebe104.NOE.Nokia.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E670B@il-ex01.ad.checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Issue #33 Is TIGER specified? Thread-Index: Ackdmjx+zKtVy5TIQauwROGRfcYgcwACzc0QAB8707A= References: <18648.63998.191263.660948@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E670B@il-ex01.ad.checkpoint.com> From: To: , , , X-OriginalArrivalTime: 24 Sep 2008 08:56:44.0311 (UTC) FILETIME=[7805E270:01C91E23] X-Nokia-AV: Clean Subject: Re: [IPsec] Issue #33 Is TIGER specified? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yaron Sheffer wrote: > Here's a "proper" reference, from a real book printed on real paper: > > Ross Anderson, Eli Biham, > Tiger: A Fast New Hash Function, > Fast Software Encryption 3, 1996, LNCS 1039 This reference does *not* actually include enough details to implemented Tiger (it omits the "S box tables" t1/t2/t3/t4); AFAIK these are only available on the author's home page. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 24 02:13:33 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B17928C0E0; Wed, 24 Sep 2008 02:13: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 239453A6D25 for ; Wed, 24 Sep 2008 02:13: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWj9FuWdn4Jm for ; Wed, 24 Sep 2008 02:13:30 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 4074F3A6A71 for ; Wed, 24 Sep 2008 02:13:18 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8O9DJXb020865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 12:13:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8O9DJxM025878; Wed, 24 Sep 2008 12:13:19 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18650.1199.278703.925480@fireball.kivinen.iki.fi> Date: Wed, 24 Sep 2008 12:13:19 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <18648.63998.191263.660948@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 13 min X-Total-Time: 16 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #33 Is TIGER specified? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1411460458==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1411460458== Content-Type: text/plain; charset=unknown Content-Transfer-Encoding: 7bit Paul Hoffman writes: > Assuming that academic paper in someone's personal directory at their > current or past employer will always be there, and won't change > content, is maybe a bit silly. Maybe, but it is much more likely to be there, than in any commercial companies www-servers. At least there most likely will not be complete change of the web site just to provide new look and feel as is very common in the company environments. It is also available in other places, but that was just the easiest to read and find. For example http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.44.3445 offers downloading pdf and ps versions of the actual paper, and it is of course available in the printed proceedings too. Here is a refence to the printed proceedings: Ross J. Anderson and Eli Biham. TIGER: A Fast New Hash Function. In Dieter Gollmann, editor, Fast Software Encryption, Third International Workshop Proceedings, volume 1039 of Lecture Notes in Computer Science, pages 89?97. Springer, February 1996. ISBN: 3-540-60865-6 -- kivinen@safenet-inc.com --===============1411460458== 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 --===============1411460458==-- From ipsec-bounces@ietf.org Wed Sep 24 02:24:54 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE9EC3A68B3; Wed, 24 Sep 2008 02:24: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 62D2E3A68B3 for ; Wed, 24 Sep 2008 02:24: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 7wW99qWrq28U for ; Wed, 24 Sep 2008 02:24:52 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 350663A67A4 for ; Wed, 24 Sep 2008 02:24:37 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8O9OaK7001071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 12:24:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8O9OaHO025034; Wed, 24 Sep 2008 12:24:36 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18650.1876.373506.395837@fireball.kivinen.iki.fi> Date: Wed, 24 Sep 2008 12:24:36 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <18648.63998.191263.660948@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E670B@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Issue #33 Is TIGER specified? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Paul Hoffman writes: > At 8:55 PM +0300 9/23/08, Yaron Sheffer wrote: > >Here's a "proper" reference, from a real book printed on real paper: > > > >Ross Anderson, Eli Biham, > >Tiger: A Fast New Hash Function, > >Fast Software Encryption 3, 1996, LNCS 1039 > > The IPsec WG consciously decided to not move TIGER to IKEv2 partially > because nearly no one had implemented it in IKEv1. Part of the reason > that few implemented it in IKEv1 is that the spec was hard to get; > part of the reason was that it was unclear what the advantage was. We have had tiger implemented for both IKEv1 and IKEv2 for long time. It has not really been that much in use, as there has not been that many others to implement it and currently I think it is disabled from all our distributions. > Have either of those changed? Is the book readily available? I wanted to get the paper reference information for the paper, so I called Tatu and he could find that preceedings from his library within the minute and he gave me the reference information for the paper. I would guess those proceedings should be in computer science libraries around the world, or at least in those which are interested in cryptography. > Is there any advantage over the current hash functions that outweigh > the fact that TIGER has gone virtually unstudied in the crypto > community relative to the hashes we are using? I donot know about that, but at it is yet another hash function and can be used as backup hash function for SHA1/2 family (in addition to the PRF_AES128_CBC, and PRF_AES128_CMAC). It is already defined in the IKEv2 document and numbers are in the IANA registry, so I see no point of removing it. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 24 03:42:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4331C28C240; Wed, 24 Sep 2008 03:42: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 BD1B128C240 for ; Wed, 24 Sep 2008 03:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CB3I-HHKVXYH for ; Wed, 24 Sep 2008 03:42:15 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 1DFC628C214 for ; Wed, 24 Sep 2008 03:42:03 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8OAg6jw009645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 13:42:06 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8OAg54J012674; Wed, 24 Sep 2008 13:42:05 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18650.6525.154879.851858@fireball.kivinen.iki.fi> Date: Wed, 24 Sep 2008 13:42:05 +0300 From: Tero Kivinen To: Keith Welter In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: ipsec@ietf.org Subject: [IPsec] INVALID_IKE_SPI questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Keith Welter writes: > For the one-way INVALID_IKE_SPI notification described in RFC 4306 section > 1.5, it is unclear to me what the Exchange Type should be in the IKE > header. Should it be 37 (INFORMATIONAL) or should it be copied from the > request that contained the unrecognized SPI? >From RFC 4306 section 2.21: If a node receives a message on UDP port 500 or 4500 outside the context of an IKE_SA known to it (and not a request to start one), it may be the result of a recent crash of the node. If the message is marked as a response, the node MAY audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node MAY audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain a Notify payload indicating INVALID_IKE_SPI. As the text says you copy IKE SPIs and Message ID, I would interpret that response being normal error response, meaning that the exchange type is also copied. Perhaps this should be clarified in the IKEv2bis? -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 24 03:54:35 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A590428C2E2; Wed, 24 Sep 2008 03:54:35 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D661628C235 for ; Wed, 24 Sep 2008 03:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 OIi8l6-FYR6V for ; Wed, 24 Sep 2008 03:54:30 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E01493A689C for ; Wed, 24 Sep 2008 03:54:29 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id CC3F4294003; Wed, 24 Sep 2008 13:54:34 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C1725294001; Wed, 24 Sep 2008 13:54:33 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8OAsXSJ002047; Wed, 24 Sep 2008 13:54:33 +0300 (IDT) Message-Id: <73EC141C-02C8-41AE-B1E7-53E728948BF6@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18650.6525.154879.851858@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 24 Sep 2008 13:54:32 +0300 References: <18650.6525.154879.851858@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org, Keith Welter Subject: Re: [IPsec] INVALID_IKE_SPI questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Sep 24, 2008, at 1:42 PM, Tero Kivinen wrote: > Keith Welter writes: >> For the one-way INVALID_IKE_SPI notification described in RFC 4306 >> section >> 1.5, it is unclear to me what the Exchange Type should be in the IKE >> header. Should it be 37 (INFORMATIONAL) or should it be copied >> from the >> request that contained the unrecognized SPI? > > From RFC 4306 section 2.21: > > If a node receives a message on UDP port 500 or 4500 outside the > context of an IKE_SA known to it (and not a request to start one), > it > may be the result of a recent crash of the node. If the message is > marked as a response, the node MAY audit the suspicious event but > MUST NOT respond. If the message is marked as a request, the node > MAY audit the suspicious event and MAY send a response. If a > response is sent, the response MUST be sent to the IP address and > port from whence it came with the same IKE SPIs and the Message ID > copied. The response MUST NOT be cryptographically protected and > MUST contain a Notify payload indicating INVALID_IKE_SPI. > > As the text says you copy IKE SPIs and Message ID, I would interpret > that response being normal error response, meaning that the exchange > type is also copied. Perhaps this should be clarified in the IKEv2bis? I took it to be 37 (INFORMATIONAL) because it's an error message sent outside the context of an IKE SA, which CCSA should not be. It's also more similar to INVALID_SPI like this, but that's probably not a good argument. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 24 04:03:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C478928C2ED; Wed, 24 Sep 2008 04:03: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 D7D2228C2F1 for ; Wed, 24 Sep 2008 04:03: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 BSMFAYulIr5g for ; Wed, 24 Sep 2008 04:03:49 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 0CFCA28C301 for ; Wed, 24 Sep 2008 04:03:30 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8OB3Zno029130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 14:03:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8OB3YOC003333; Wed, 24 Sep 2008 14:03:34 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18650.7814.808443.474300@fireball.kivinen.iki.fi> Date: Wed, 24 Sep 2008 14:03:34 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <18648.62020.138458.908262@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 15 min X-Total-Time: 18 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Counter mode ciphers in IKEv2 to protect IKE SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Paul Hoffman writes: > >I think the AES_CTR can be used to protect the IKEv2 SA without any > >problems. The RFC3686 already describes evertything that is needed to > >use it. > > ...except how to do so in IKEv2. RFC 3686 is, obviously, for IKEv1 only. So is RFC2451 and RFC3602 (AES_CBC). So we cannot use AES_CBC or 3DES either if using the same logic. > >The only difference to the CBC mode is, is the way how IV for > >the AES_CTR is generated. The RFC4306 only points to "Recommendation > >for Block Cipher Modes of Operation" document for advises for IV > >generation. Only think that would not really be needed for IV > >selection is the text in the RFC4306 which says that IV must be > >unpredictable. The counter mode ciphers do not require > >unpredictability but they do require uniqueness. > > And this will help bits-on-the-wire interoperability in what way? :-) Responder takes IV field from the packet a generates the real IV given to the AES CTR by concatenating nonce (which is from keying material generated by IKEv2), IV field, and block number (0). Responder does not care how the IV was generated, and it does not need to care. Responder will be interoperable with the other end regardless how the initiator generates IVs. > >Anyways RFC3686 already describes the way how the IV should be > >generated for AES_CTR, and I do not see any reason why the the text > >which previously allowed CTR now needs to forbid CTR modes and only > >allow CBC modes. > > That's not what I am saying: I'm saying that it was a mistake to list > ENCR_AES_CTR as RFC3686 unless that RFC describes how to use it in > IKEv2, which it doesn't. There is nothing stopping someone from > writing a revision to RFC 3686 to describe this. Same applies to the RFC3602 (AES_CBC), and RFC 2451 (3DES, RC5, IDEA, Cast, Blowfish, 3IDEA). None of those describe anything how those ciphers are used in the IKEv2, they only describe how they are used in the ESP (or IKEv1). 3DES, AES-CBC, AES-CTR are all in exactly same situation here. > >This is again protocol change that will change bits > >on the wire (i.e making CTR mode in IKEv2 SA to be unspecified even > >when it was previously specified). > > Unless I am missing something, it is not specified: it is unspecified > but you could try to guess from RFC 3686. And same applies to the AES-CBC. It is unspecified, but you can try to guess from RFC 3602 and try to apply that ESP and IKEv1 processing to IKEv2. When the RFC 3686 was being specified, I required it to be changed so it does not use IKEv2 ONLY way of describing how to generate keying material, but uses words that can be use for BOTH IKEv1 and IKEv2: http://www.sandelman.ottawa.on.ca/ipsec/2003/06/msg00197.html BTW Could not use the www.ietf.org ipsec-list mail archive as it only starts from 2004. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 24 04:08:40 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27ED3A69FD; Wed, 24 Sep 2008 04:08: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 14BA53A69FD for ; Wed, 24 Sep 2008 04:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGZm6HG0gaIa for ; Wed, 24 Sep 2008 04:08:38 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id B7A1028C300 for ; Wed, 24 Sep 2008 04:08:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8OB8Qf5002722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 14:08:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8OB8QfZ010669; Wed, 24 Sep 2008 14:08:26 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18650.8106.416900.250299@fireball.kivinen.iki.fi> Date: Wed, 24 Sep 2008 14:08:26 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <18648.57073.992710.756960@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #27 Motivation for using port 4500 vs. 500 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Paul Hoffman writes: > OK I see that now. The text you want removed is *above* the text > below, outside of the optional NAT-traversal requirements. (And, yes, > I did mean to use "optional" and "requirements" in that sentence.) > But I can see that the supposedly-helpful text could actually lead to > a developer using 500 anyway for some bad reason. Yes, I wanted to modify Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working through a NAT, it is generally better to pass IKE packets over port 4500 because some older NATs handle IKE traffic on port 500 cleverly in an attempt to transparently establish IPsec connections between endpoints that don't handle NAT traversal themselves. Such NATs may interfere with the straightforward NAT traversal envisioned by this document. {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT between it and its correspondent MUST send all subsequent traffic from port 4500, which NATs should not treat specially (as they might with port 500). to Port 4500 is reserved for UDP-encapsulated ESP and IKE. {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT between it and its correspondent MUST send all subsequent traffic from port 4500, which NATs should not treat specially (as they might with port 500). Sorry, for not being clear enough. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 24 04:33:02 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28F763A6B00; Wed, 24 Sep 2008 04:33:02 -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 8BB6F3A6B00; Wed, 24 Sep 2008 04:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 L-JRGMCjC58n; Wed, 24 Sep 2008 04:32:53 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id 8B1E53A6B07; Wed, 24 Sep 2008 04:32:53 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8OBWwwC020474; Wed, 24 Sep 2008 07:32:58 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8OBWwVT162406; Wed, 24 Sep 2008 05:32:58 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8OBWvQd026529; Wed, 24 Sep 2008 05:32:58 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8OBWvm2026518; Wed, 24 Sep 2008 05:32:57 -0600 In-Reply-To: References: <18648.59003.22895.803651@fireball.kivinen.iki.fi> MIME-Version: 1.0 X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 09/24/2008 07:31:41 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 09/24/2008 07:31:41 AM, Serialize complete at 09/24/2008 07:31:41 AM, S/MIME Sign failed at 09/24/2008 07:31:41 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_M2_08202008HFIGS1|August 20, 2008) at 09/24/2008 05:32:57, Serialize complete at 09/24/2008 05:32:57 To: Paul Hoffman X-KeepSent: B5418099:338E1623-852574CE:003ED3DD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen Message-ID: Date: Wed, 24 Sep 2008 07:32:56 -0400 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Tero Kivinen Subject: Re: [IPsec] Issue #42 Improve example of multiple proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0757416595==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0757416595== Content-Type: multipart/alternative; boundary="=_alternative 003F5783852574CE_=" This is a multipart message in MIME format. --=_alternative 003F5783852574CE_= Content-Type: text/plain; charset="US-ASCII" > I'm coming around on us having to talk about combined-mode > ciphers where they are needed here. The above text (with a bit of > editorial change) is a good example of why we would have multiple > proposals. The reason we would mention combined-mode as an example is because it is not supported on all implementations, and therefore an implementation that supported it would be advised to propose both combined-mode and otherwise. However, there may be better examples. It is also the case that AH support is not required of an implementation, correct? So we could use this as an example case. If the user wants to perform authentication only, and prefers to use AH, but is willing to use ESP in the hypothetical case of interoperating with a peer that supports ESP only, then that is also a good example of requiring multiple proposals. The same goes for more advanced cryptographic algorithms. For example, if a user wants to use AES-256 but is willing to use AES-128 if that is the strongest algorithm supported by a particular partner, then both may be proposed. Use of ESN is another example. Implementations that support ESN would not want for a negotiation to fail simply because the peer does not support ESN. Such implementations would be advised to send proposals both with and without ESN. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Paul Hoffman To: Tero Kivinen , ipsec@ietf.org Date: 09/23/2008 06:47 PM Subject: Re: [IPsec] Issue #42 Improve example of multiple proposals At 3:52 PM +0300 9/23/08, Tero Kivinen wrote: > The Proposal structure contains within it a Proposal # and an IPsec > protocol ID. Each structure MUST have a proposal number one (1) > greater than the previous structure. The first Proposal in the > initiator's SA payload MUST have a Proposal # of one (1). A common > reason to use multiple proposals is when used with combined mode > ciphers. Combined mode ciphers include both integrity and > encryption in single encryption algorithm. Because of this it is > not allowed to have combined mode ciphers with an another integrity > algorithm, thus proposal must not have any integrity algorithms > (other than NONE). If initiator want to propose both combine mode > ciphers and normal ciphers, it must include two proposals. One will > have all combined mode ciphers, and no integrity algorithm. The > other will have all non-combined mode ciphers and all allowed > integrity algorithms with them. For example such proposal would > have two proposal structures, one for ESP with ENCR_AES-CCM_8, > ENCR_AES-CCM_12, and ENCR_AES-CCM_16 as Proposal #1 and one for ESP > with ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and > AUTH_HMAC_SHA1_96 as Proposal #2. I'm coming around on us having to talk about combined-mode ciphers where they are needed here. The above text (with a bit of editorial change) is a good example of why we would have multiple proposals. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 003F5783852574CE_= Content-Type: text/html; charset="US-ASCII"
> <sigh> I'm coming around on us having to talk about combined-mode
> ciphers where they are needed here. The above text (with a bit of
> editorial change) is a good example of why we would have multiple
> proposals.

The reason we would mention combined-mode as an example is because it is not supported on all implementations, and therefore an implementation that supported it would be advised to propose both combined-mode and otherwise.  However, there may be better examples.

It is also the case that AH support is not required of an implementation, correct?  So we could use this as an example case.  If the user wants to perform authentication only, and prefers to use AH, but is willing to use ESP in the hypothetical case of interoperating with a peer that supports ESP only, then that is also a good example of requiring multiple proposals.

The same goes for more advanced cryptographic algorithms.  For example, if a user wants to use AES-256 but is willing to use AES-128 if that is the strongest algorithm supported by a particular partner, then both may be proposed.

Use of ESN is another example.  Implementations that support ESN would not want for a negotiation to fail simply because the peer does not support ESN.  Such implementations would be advised to send proposals both with and without ESN.


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


From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Tero Kivinen <kivinen@iki.fi>, ipsec@ietf.org
Date: 09/23/2008 06:47 PM
Subject: Re: [IPsec] Issue #42 Improve example of multiple proposals




At 3:52 PM +0300 9/23/08, Tero Kivinen wrote:
>    The Proposal structure contains within it a Proposal # and an IPsec
>    protocol ID. Each structure MUST have a proposal number one (1)
>    greater than the previous structure. The first Proposal in the
>    initiator's SA payload MUST have a Proposal # of one (1). A common
>    reason to use multiple proposals is when used with combined mode
>    ciphers. Combined mode ciphers include both integrity and
>    encryption in single encryption algorithm. Because of this it is
>    not allowed to have combined mode ciphers with an another integrity
>    algorithm, thus proposal must not have any integrity algorithms
>    (other than NONE). If initiator want to propose both combine mode
>    ciphers and normal ciphers, it must include two proposals. One will
>    have all combined mode ciphers, and no integrity algorithm. The
>    other will have all non-combined mode ciphers and all allowed
>    integrity algorithms with them. For example such proposal would
>    have two proposal structures, one for ESP with ENCR_AES-CCM_8,
>    ENCR_AES-CCM_12, and ENCR_AES-CCM_16 as Proposal #1 and one for ESP
>    with ENCR_AES_CBC, ENCR_3DES, AUTH_AES_XCBC_96, and
>    AUTH_HMAC_SHA1_96 as Proposal #2.

<sigh> I'm coming around on us having to talk about combined-mode
ciphers where they are needed here. The above text (with a bit of
editorial change) is a good example of why we would have multiple
proposals.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 003F5783852574CE_=-- --===============0757416595== 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 --===============0757416595==-- From ipsec-bounces@ietf.org Wed Sep 24 05:10:06 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECFB628C314; Wed, 24 Sep 2008 05:10:05 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 624EF28C30E; Wed, 24 Sep 2008 05:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 0lw3NJxK2-3Q; Wed, 24 Sep 2008 05:10:03 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 2490A28C309; Wed, 24 Sep 2008 05:10:03 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E7222294007; Wed, 24 Sep 2008 15:09:40 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 92E00294001; Wed, 24 Sep 2008 15:06:45 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8OC6iSJ029750; Wed, 24 Sep 2008 15:06:44 +0300 (IDT) Message-Id: <61C767AD-5A90-490C-8BD1-730FE35929A6@checkpoint.com> From: Yoav Nir To: Scott C Moonen In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 24 Sep 2008 15:06:43 +0300 References: <18648.59003.22895.803651@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Paul Hoffman , Tero Kivinen Subject: Re: [IPsec] Issue #42 Improve example of multiple proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Sep 24, 2008, at 2:32 PM, Scott C Moonen wrote: > > > I'm coming around on us having to talk about combined-mode > > ciphers where they are needed here. The above text (with a bit of > > editorial change) is a good example of why we would have multiple > > proposals. > > The reason we would mention combined-mode as an example is because > it is not supported on all implementations, and therefore an > implementation that supported it would be advised to propose both > combined-mode and otherwise. However, there may be better examples. > > It is also the case that AH support is not required of an > implementation, correct? So we could use this as an example case. > If the user wants to perform authentication only, and prefers to use > AH, but is willing to use ESP in the hypothetical case of > interoperating with a peer that supports ESP only, then that is also > a good example of requiring multiple proposals. That's different, because ESP and AH are different protocols, so it makes sense that they be separated to different proposals. AES-GCM and AES-CBC+HMAC-SHA1 are valid alternatives for accomplishing the same things. Using them in separate proposals is a finer point. > The same goes for more advanced cryptographic algorithms. For > example, if a user wants to use AES-256 but is willing to use > AES-128 if that is the strongest algorithm supported by a particular > partner, then both may be proposed. Yes, but both can be proposed in a single proposal - they're just different ENCR transforms. > Use of ESN is another example. Implementations that support ESN > would not want for a negotiation to fail simply because the peer > does not support ESN. Such implementations would be advised to send > proposals both with and without ESN. Again ESN-yes and ESN-no can both be proposed in a single proposal. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 24 05:27:24 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74AF228C31F; Wed, 24 Sep 2008 05:27:24 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 603D428C31F for ; Wed, 24 Sep 2008 05:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oK7dyjHdUAG for ; Wed, 24 Sep 2008 05:27:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 6C71E28C31E for ; Wed, 24 Sep 2008 05:27:10 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8OCRD2I001152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 15:27:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8OCRDOa022807; Wed, 24 Sep 2008 15:27:13 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18650.12833.315741.149701@fireball.kivinen.iki.fi> Date: Wed, 24 Sep 2008 15:27:13 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <18648.59003.22895.803651@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 14 min X-Total-Time: 17 min Cc: ipsec@ietf.org, Paul Hoffman Subject: Re: [IPsec] Issue #42 Improve example of multiple proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Scott C Moonen writes: > It is also the case that AH support is not required of an implementation, > correct? So we could use this as an example case. If the user wants to > perform authentication only, and prefers to use AH, but is willing to use > ESP in the hypothetical case of interoperating with a peer that supports > ESP only, then that is also a good example of requiring multiple > proposals. The reason I do not like to use "AH or ESP" as example is that it is very easy for the IKEv1 implementor to read that as "AH and ESP" as was possible with IKEv1, but which is no longer possible with IKEv2. Just to avoid confusion about this I think it would be good idea to avoid "AH or ESP" in the example. > The same goes for more advanced cryptographic algorithms. For example, if > a user wants to use AES-256 but is willing to use AES-128 if that is the > strongest algorithm supported by a particular partner, then both may be > proposed. But that does not require multiple proposals, they can all be proposed in one proposal, which contains all ciphers which implementation is willing to accept. The responder will then select exactly one cipher from the list given by the initiator. > Use of ESN is another example. Implementations that support ESN would not > want for a negotiation to fail simply because the peer does not support > ESN. Such implementations would be advised to send proposals both with > and without ESN. No. Implementations should send ONE proposal having both "No Extended Sequence Numbers" and "Extended Sequence Numbers" in their proposal i.e. 2 transform type 5 (Extended Sequence Numbers) transform attributes, with transform IDs of both 0 and 1. As implementations MUST understand ESN transform attributes they must be able to pick the one which they support from such proposal. In most cases you can go with just ONE proposal having multiple transforms inside, including multiple transforms having same trasform ID but different transform attributes. This does not work with combined mode ciphers, as you are not allowed to use any other Integrity Algorithm with them than NONE, thus you cannot propose one proposal having: Transform Type Transform Attribute 1 Encryption Algorithm 12 ENCR_AES_CBC 1 Encryption Algorithm 16 ENCR_AES-CCM_16 1 Encryption Algorithm 3 ENCR_3DES 1 Encryption Algorithm 20 AES-GCM with a 16 octet ICV 2 Integrity Algorithm 0 NONE 2 Integrity Algorithm 2 AUTH_HMAC_SHA1_96 5 Extended Sequence Numbers 0 No Extended Sequence Numbers 5 Extended Sequence Numbers 1 Extended Sequence Numbers As now the responder could select ENCR_AES-CCM_16 with AUTH_HMAC_SHA1_96 which is not allowed, or it could also pick ENCR_3DES with NONE integrity algorithm, which is something you would not want to allow. Because of this you need to give 2 proposals: Proposal #1 Transform Type Transform Attribute 1 Encryption Algorithm 12 ENCR_AES_CBC 1 Encryption Algorithm 3 ENCR_3DES 2 Integrity Algorithm 2 AUTH_HMAC_SHA1_96 5 Extended Sequence Numbers 0 No Extended Sequence Numbers 5 Extended Sequence Numbers 1 Extended Sequence Numbers Proposal #2 Transform Type Transform Attribute 1 Encryption Algorithm 16 ENCR_AES-CCM_16 1 Encryption Algorithm 20 AES-GCM with a 16 octet ICV 2 Integrity Algorithm 0 NONE 5 Extended Sequence Numbers 0 No Extended Sequence Numbers 5 Extended Sequence Numbers 1 Extended Sequence Numbers -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 24 07:48:04 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED493A6B5D; Wed, 24 Sep 2008 07:48:04 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 605B73A6ADC for ; Wed, 24 Sep 2008 07:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrQ02K-jcfL1 for ; Wed, 24 Sep 2008 07:48:02 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 45A2D3A69D9 for ; Wed, 24 Sep 2008 07:48:02 -0700 (PDT) Received: from [10.20.30.152] (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 m8OEm1C1098756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Sep 2008 07:48:04 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18650.12833.315741.149701@fireball.kivinen.iki.fi> References: <18648.59003.22895.803651@fireball.kivinen.iki.fi> <18650.12833.315741.149701@fireball.kivinen.iki.fi> Date: Wed, 24 Sep 2008 07:37:57 -0700 To: ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] Issue #42 Improve example of multiple proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:27 PM +0300 9/24/08, Tero Kivinen wrote: >The reason I do not like to use "AH or ESP" as example is that it is >very easy for the IKEv1 implementor to read that as "AH and ESP" as >was possible with IKEv1, but which is no longer possible with IKEv2. >Just to avoid confusion about this I think it would be good idea to >avoid "AH or ESP" in the example. I agree with this. >No. Implementations should send ONE proposal having both "No Extended >Sequence Numbers" and "Extended Sequence Numbers" in their proposal >i.e. 2 transform type 5 (Extended Sequence Numbers) transform >attributes, with transform IDs of both 0 and 1. As implementations >MUST understand ESN transform attributes they must be able to pick the >one which they support from such proposal. Tero: please write up some text for the document about using one proposal instead of multiple proposals that could be represented as one proposal. If the WG can agree to it, it would be a good addition to the document. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 24 07:48:10 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C2328C33F; Wed, 24 Sep 2008 07:48: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 7FE4428C327 for ; Wed, 24 Sep 2008 07:48:09 -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 8CzbFr479mBH for ; Wed, 24 Sep 2008 07:48:05 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 56EBE28C2DB for ; Wed, 24 Sep 2008 07:48:05 -0700 (PDT) Received: from [10.20.30.152] (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 m8OEm1C3098756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 07:48:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <73EC141C-02C8-41AE-B1E7-53E728948BF6@checkpoint.com> References: <18650.6525.154879.851858@fireball.kivinen.iki.fi> <73EC141C-02C8-41AE-B1E7-53E728948BF6@checkpoint.com> Date: Wed, 24 Sep 2008 07:47:38 -0700 To: Yoav Nir , Tero Kivinen From: Paul Hoffman Cc: ipsec@ietf.org, Keith Welter Subject: Re: [IPsec] INVALID_IKE_SPI questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I have opened this as issue #46. Clearly, it is a good question and there is disagreement about the answer. More responses are needed. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 24 07:48:11 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEDCB28C2F7; Wed, 24 Sep 2008 07:48:11 -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 DDFB128C34E for ; Wed, 24 Sep 2008 07:48:10 -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 FBg+Eg-m2RBF for ; Wed, 24 Sep 2008 07:48:05 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 5A9C028C2F7 for ; Wed, 24 Sep 2008 07:48:05 -0700 (PDT) Received: from [10.20.30.152] (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 m8OEm1Bx098756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2008 07:48:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <18648.57993.707815.94580@fireball.kivinen.iki.fi> Date: Wed, 24 Sep 2008 07:30:03 -0700 To: Yoav Nir From: Paul Hoffman Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Issue #29 Need to clarify Exchange Type field X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 8:42 AM +0300 9/24/08, Yoav Nir wrote: >On Sep 24, 2008, at 1:56 AM, Paul Hoffman wrote: > >>> >>>Then I think it is not really true. Each exchange consists of request >>>and reply pair, and exchanges can follow each other in certain order, >>>but as there is only 2 messages in an exchange (one request and one >>>reply), I do not think exchange type can really constraint order of >>>the messages in an exchange (ok, I think it is implictly understood >>>that request comes before reply, and you are not allowed to respond >>>with a reply to request, before the request is sent, but I still think >>>the word there is just confusing and not helping at all). >>> >>>Section 1 explains exchange to be: >>> >>> All IKE communications consist of pairs of messages: a request and a >>> response. The pair is called an "exchange". >>> >>>So no exchange can have more than 2 messages. >> >>My mistake. I thought EAP authentication was done in "an exchange", >> >>I have made the above change, and have replaced "EAP exchange" in >>the security considerations with better language. > >I understood it the same way as Paul. This makes the term "exchange" >much less useful. For example, in the EAP case traffic selectors are >proposed in one exchange, while the reply with the final selectors >comes in a totally different exchange. This doesn't make much sense. >The several request-reply pairs there are all related in that they >negotiate the same thing, and up to now, I thought the term for this >was "exchange". > >I would rather re-define "exchange" so that all the IKE_AUTH >round-trips are one exchange rather than having to invent a new >concept (maybe revive the term "mode") to define the state machine >for authentication. Obviously that state machine can't reach a >final state after the first response. Actually, "EAP exchange" was only used twice, both times in the security considerations section. We got it right in the main EAP section. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 24 17:25:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0940D28C0E2; Wed, 24 Sep 2008 17:25:20 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF74828C0CE for ; Wed, 24 Sep 2008 17:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 AiE1b5o7KE3R for ; Wed, 24 Sep 2008 17:25:10 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 56B0B3A6AB7 for ; Wed, 24 Sep 2008 17:25:10 -0700 (PDT) Received: from d03relay04 (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8P0PDqN003969 for ; Wed, 24 Sep 2008 20:25:13 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04 (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8P0PDEM189678 for ; Wed, 24 Sep 2008 18:25:13 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8P0PCnQ009602 for ; Wed, 24 Sep 2008 18:25:13 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8P0PCcS009598 for ; Wed, 24 Sep 2008 18:25:12 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 09/24/2008 05:25:09 PM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 09/24/2008 05:25:09 PM, Serialize complete at 09/24/2008 05:25:09 PM, S/MIME Sign failed at 09/24/2008 05:25:09 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_M2_08202008HFIGS1|August 20, 2008) at 09/24/2008 18:25:12, Serialize complete at 09/24/2008 18:25:12 Message-ID: Date: Wed, 24 Sep 2008 17:25:12 -0700 Subject: [IPsec] Comment on "suspicious message" handling in RFC 4306 2.21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0622134947==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0622134947== Content-Type: multipart/alternative; boundary="=_alternative 00024D98882574CF_=" This is a multipart message in MIME format. --=_alternative 00024D98882574CF_= Content-Type: text/plain; charset="US-ASCII" >From RFC 4306 Section 2.21 A node receiving a suspicious message from an IP address with which it has an IKE_SA MAY send an IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. The recipient MUST NOT change the state of any SA's as a result but SHOULD audit the event to aid in diagnosing malfunctions. A node MUST limit the rate at which it will send messages in response to unprotected messages. I assume "suspicious message" means the sort of message the would result in the recipient sending INVALID_SPI or INVALID_IKE_SPI. I'm wondering how much value is added by sending the notification using an existing IKE_SA as opposed to using the unprotected one-way notification. In the case of INVALID_IKE_SPI, the unprotected notification actually has the advantage of carrying the unrecognized SPIs in the IKE header whereas the protected notification would not. Furthermore, if INITIAL_CONTACT is working properly it seems that the case of having an existing IKE_SA with which to send the notification should not even occur. The only advantage I can see to sending the protected notification is that the recipient should not start a liveness exchange. If the value of the MAY in the excerpt above is indeed small, perhaps it should be striken for the sake of simplicity. Keith Welter IBM Enterprise Networking Solutions 1-415-545-2694 (T/L: 473-2694) --=_alternative 00024D98882574CF_= Content-Type: text/html; charset="US-ASCII"
From RFC 4306 Section 2.21
   A node receiving a suspicious message from an IP address with which
  it has an IKE_SA MAY send an IKE Notify payload in an IKE
  INFORMATIONAL exchange over that SA.  The recipient MUST NOT change
  the state of any SA's as a result but SHOULD audit the event to aid
  in diagnosing malfunctions.  A node MUST limit the rate at which it
  will send messages in response to unprotected messages.
I assume "suspicious message" means the sort of message the would result in the recipient sending INVALID_SPI or INVALID_IKE_SPI.  I'm wondering how much value is added by sending the notification using an existing IKE_SA as opposed to using the unprotected one-way notification.  In the case of INVALID_IKE_SPI, the unprotected notification actually has the advantage of carrying the unrecognized SPIs in the IKE header whereas the protected notification would not.  Furthermore, if INITIAL_CONTACT is working properly it seems that the case of having an existing IKE_SA with which to send the notification should not even occur.  The only advantage I can see to sending the protected notification is that the recipient should not start a liveness exchange.  If the value of the MAY in the excerpt above is indeed small, perhaps it should be striken for the sake of simplicity.

Keith Welter
IBM Enterprise Networking Solutions
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 00024D98882574CF_=-- --===============0622134947== 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 --===============0622134947==-- From ipsec-bounces@ietf.org Wed Sep 24 23:45:12 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF9303A680C; Wed, 24 Sep 2008 23:45:11 -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 ADAE33A680C for ; Wed, 24 Sep 2008 23:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kF5IJtEi1ZU for ; Wed, 24 Sep 2008 23:45:09 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 426583A67A6 for ; Wed, 24 Sep 2008 23:45:06 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 610F7294003; Thu, 25 Sep 2008 09:43:45 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 04FD1294002; Thu, 25 Sep 2008 09:43:44 +0300 (IDT) Received: from RnD-Test.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8P6hhSJ009552; Thu, 25 Sep 2008 09:43:43 +0300 (IDT) Message-Id: From: Yoav Nir To: ipsec@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Thu, 25 Sep 2008 09:43:42 +0300 References: <18574.24516.764629.590327@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: Paul Hoffman , Tero Kivinen Subject: [IPsec] Issue #14: Bounding the retransmit time X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1078574892==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1078574892== Content-Type: multipart/alternative; boundary=Apple-Mail-1--795313650 --Apple-Mail-1--795313650 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > >> 2.1. Use of Retransmission Timers > ... >> For every pair of IKE messages, the initiator is responsible for >> retransmission in the event of a timeout. The responder MUST >> never >> retransmit a response unless it receives a retransmission of the >> request. In that event, the responder MUST ignore the >> retransmitted >> request except insofar as it triggers a retransmission of the >> response. The initiator MUST remember each request until it >> receives >> the corresponding response. The responder MUST remember each >> response until it receives a request whose sequence number is >> larger >> than or equal to the sequence number in the response plus its >> window >> size (see Section 2.3). > > One of the problems here is that if we are using large window size, we > have to keep that many messages for ever. It would be nice, we the > responder of the request, could forget the response packet after lets > say 10 minutes after it sent it out to requestor. There is no reason > why the other end should be allowed to resend his request 4 hours > later and expect that other end can still resend reply back. So > suggest adding: > > Responder are allowed to forget response after long timeout for the > memory saving purposes. The timeout must be longer than several > minutes that could be used for the retransmission timers of the > other end. > > ===Not done. This is a change to the protocol. The WG might want it, > but it will have to be an explicit decision from the WG. The easy answer for this concern is not to use large window sizes. For example, with a window size of 1, you only save 1 response. I really don't see the value is large window sizes, as a pair of peers will usually only have a handful of SAs and those are maintained for a long period of time. Unless you are benchmarking tunnel setup rates, or have an extreme latency problem (as in you peer is on Mars, not when your peer is in China) a window size of 1 is usually good enough. Given that implementations will use window sizes greater than 1, and that keeping even one packet indefinitely is not good engineering, there may be value in allowing the responder to forget the response. This should IMO be aligned with a requirement by the initiator to stop transmitting. So we should decide on some X (3 minutes?) and say something like this: Responders MAY forget responses X minutes after first generating them, as retransmissions of the requests are expected to be done by then. Responders SHOULD ignore all subsequent retransmissions of the request. Initiators MUST cease retransmitting requests if no response has been received within X minutes. In such a case, the Initiator MUST deem the IKE SA to have failed. --Apple-Mail-1--795313650 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

2.1.  Use of = Retransmission Timers
...
   For every pair of IKE messages, the = initiator is responsible for
   retransmission in the event of a = timeout.  The responder MUST = never
   retransmit = a response unless it receives a retransmission of = the
   request. =  In that event, the responder MUST ignore the = retransmitted
   request = except insofar as it triggers a retransmission of = the
   response. =  The initiator MUST remember each request until it = receives
   the = corresponding response.  The responder MUST remember = each
   response = until it receives a request whose sequence number is = larger
   than or = equal to the sequence number in the response plus its = window
   size (see = Section 2.3).

One of the problems here is = that if we are using large window size, we
have to keep that many = messages for ever. It would be nice, we the
responder of the request, = could forget the response packet after lets
say 10 minutes after it = sent it out to requestor. There is no reason
why the other end should = be allowed to resend his request 4 hours
later and expect that other = end can still resend reply back. So
suggest = adding:

   Responder are allowed to forget = response after long timeout for the
   memory saving = purposes. The timeout must be longer than = several
   minutes that could be used for the = retransmission timers of the
   other = end.

=3D=3D=3DNot done. This is a change to the protocol. The WG = might want it,
but it will have to be an explicit decision from the = WG.

The easy answer for this concern is not to = use large window sizes. For example, with a window size of 1, you only = save 1 response. I really don't see the value is large window sizes, as = a pair of peers will usually only have a handful of SAs and those are = maintained for a long period of time. Unless you are benchmarking tunnel = setup rates, or have an extreme latency problem (as in you peer is on = Mars, not when your peer is in China) a window size of 1 is usually good = enough.

Given that implementations will use = window sizes greater than 1, and that keeping even one packet = indefinitely is not good engineering, there may be value in allowing the = responder to forget the response. This should IMO be aligned with a = requirement by the initiator to stop transmitting. So we should decide = on some X (3 minutes?) and say something like = this:

   Responders MAY forget = responses X minutes after first generating
   them, = as retransmissions of the requests are expected to be = done
   by then. Responders SHOULD ignore all = subsequent retransmissions
   of the request. = Initiators MUST cease retransmitting requests if
   = no response has been received within X minutes. In such a = case,
   the Initiator MUST deem the IKE SA to have = failed.
= --Apple-Mail-1--795313650-- --===============1078574892== 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 --===============1078574892==-- From ipsec-bounces@ietf.org Thu Sep 25 05:40:46 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC0AA3A68A2; Thu, 25 Sep 2008 05:40: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 F380B3A6890 for ; Thu, 25 Sep 2008 05:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sKZNCC-20a9 for ; Thu, 25 Sep 2008 05:40:44 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 4284D3A68A2 for ; Thu, 25 Sep 2008 05:40:21 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8PCeEK7007003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 15:40:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8PCeEim007783; Thu, 25 Sep 2008 15:40:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18651.34478.270296.9535@fireball.kivinen.iki.fi> Date: Thu, 25 Sep 2008 15:40:14 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: <18648.59003.22895.803651@fireball.kivinen.iki.fi> <18650.12833.315741.149701@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 45 min X-Total-Time: 44 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Issue #42 Improve example of multiple proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Paul Hoffman writes: > Tero: please write up some text for the document about using one > proposal instead of multiple proposals that could be represented as > one proposal. If the WG can agree to it, it would be a good addition > to the document. The section 3.3. has already paragraph explaining those, but I think what we should do is to add examples of both cases (just like rfc2409 had). Here is the paragraph explaining the multiple transforms: If there are multiple transforms with the same Transform Type, the proposal is an OR of those transforms. If there are multiple Transforms with different Transform Types, the proposal is an AND of the different groups. For example, to propose ESP with (3DES or AES- CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and two Transform Type 3 candidates (one for HMAC_MD5 and one for HMAC_SHA). This effectively proposes four combinations of algorithms. If the initiator wanted to propose only a subset of those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that as multiple transforms within a single Proposal. Instead, the initiator would have to construct two different Proposals, each with two transforms. So we could add following sections: ---------------------------------------------------------------------- 3.3.7. Example of SA Payload with One Proposal In normal case there is only need to include just one proposal to the SA payload. This one proposal will list all the supported (non-combined mode) algorithms and responder will pick the one set of those algorithms to be used. Multiple proposals (most commonly two) is needed in some more complex cases like proposing both combined mode ciphers and non-combined mode ciphers. This example here offers one proposal payload inside the SA payload and proposes all commonly used encryption algorithms (3DES, AES_CBC, AES_CTR), integrity algorithsm (MD5, SHA1, AES_XCBC_96), and extended sequence numbers. It also includes 3 key lengths for the AES algorithms. This proposal is one to be used when creating child SA without doing another Diffie-Hellman. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | SA Payload Length=136 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) | RESERVED | Proposal Proposal Length=132 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposal #=1 | Protocol ID=3 | SPI Size=4 |# of Transf.=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI (4 bytes) = 0x58293233 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (not last) | RESERVED | Transform Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transf. Type=1 | RESERVED | Transf. ID = 3 ENCR_3DES | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (not last) | RESERVED | Transform Length=12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transf. Type=1 | RESERVED | Transf. ID = 12 ENCR_AES_CBC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Attribute Type=14 Key Length| Attribute Value = 128 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (not last) | RESERVED | Transform Length=12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transf. Type=1 | RESERVED | Transf. ID = 12 ENCR_AES_CBC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Attribute Type=14 Key Length| Attribute Value = 192 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (not last) | RESERVED | Transform Length=12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transf. Type=1 | RESERVED | Transf. ID = 12 ENCR_AES_CBC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Attribute Type=14 Key Length| Attribute Value = 256 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (not last) | RESERVED | Transform Length=12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transf. Type=1 | RESERVED | Transf. ID = 13 ENCR_AES_CTR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Attribute Type=14 Key Length| Attribute Value = 128 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (not last) | RESERVED | Transform Length=12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transf. Type=1 | RESERVED | Transf. ID = 13 ENCR_AES_CTR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Attribute Type=14 Key Length| Attribute Value = 192 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (not last) | RESERVED | Transform Length=12 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transf. Type=1 | RESERVED | Transf. ID = 13 ENCR_AES_CTR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| Attribute Type=14 Key Length| Attribute Value = 256 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (not last) | RESERVED | Transform Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transf. Type=3 | RESERVED | Transf. ID=1 AUTH_HMAC_MD5_96 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (not last) | RESERVED | Transform Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transf. Type=3 | RESERVED | Transf. ID=2 AUTH_HMAC_SHA1_96| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (not last) | RESERVED | Transform Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transf. Type=3 | RESERVED | Transf. ID=5 AUTH_AES_XCBC_96 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 (not last) | RESERVED | Transform Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transf. Type=5 | RESERVED | Transf. ID=0 No ESN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (last) | RESERVED | Transform Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Transf. Type=5 | RESERVED | Transf. ID=1 ESN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In short this payload format can be expressed as: Proposal #1: Protocol ID = 3 (ESP), SPI Size = 4, SPI = 0x58293233 Transform: Type = 1 (Encryption Algorithm), ID = 3 ENCR_3DES Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC Attribute: Type = 14 (Key Length), Value = 128 Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC Attribute: Type = 14 (Key Length), Value = 192 Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC Attribute: Type = 14 (Key Length), Value = 256 Transform: Type = 1 (Encryption Algorithm), ID = 13 ENCR_AES_CTR Attribute: Type = 14 (Key Length), Value = 128 Transform: Type = 1 (Encryption Algorithm), ID = 13 ENCR_AES_CTR Attribute: Type = 14 (Key Length), Value = 192 Transform: Type = 1 (Encryption Algorithm), ID = 13 ENCR_AES_CTR Attribute: Type = 14 (Key Length), Value = 256 Transform: Type = 2 (Integrity Algorithm), ID = 1 AUTH_HMAC_MD5_96 Transform: Type = 2 (Integrity Algorithm), ID = 2 AUTH_HMAC_SHA1_96 Transform: Type = 2 (Integrity Algorithm), ID = 5 AUTH_AES_XCBC_96 Transform: Type = 5 (Extended Sequence Numbers), ID = 0 No ESN Transform: Type = 5 (Extended Sequence Numbers), ID = 1 ESN This same shorter format is used in the next section when describing more complex proposals. The return packet from the responder will contain SA payload having contents something like this (provided it selected AES_CBC with 256 bit keys, AES_XCBC and ESN): Proposal #1: Protocol ID = 3 (ESP), SPI Size = 4, SPI = 0x58293233 Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC Attribute: Type = 14 (Key Length), Value = 256 Transform: Type = 2 (Integrity Algorithm), ID = 5 AUTH_AES_XCBC_96 Transform: Type = 5 (Extended Sequence Numbers), ID = 1 ESN 3.3.8. Example of SA Payload with Combined Mode Ciphers Combined mode ciphers gives one more complication when proposal structures are concenrned, as it is forbidden to propose integrity algorithms with them. This means that you cannot include normal non-combined mode ciphers and intergrity protection in the same proposal where you propose combined mode ciphers. This means you need two proposals if you want to propose both. This example has two proposals one proposing ENCR_AES_CCM_16 (with 3 different key lengths). Second proposes ENCR_AES_CBC (with 3 different key lengths) and AUTH_HMAC_SHA1_96 or AUTH_AES_XCBC_96. Here we also want to do another Diffie-Hellman using group 1536, 2048 or 3072 bit MODP-group. Here is the proposals in the short format: Proposal #1: Protocol ID = 3 (ESP), SPI Size = 4, SPI = 0x58293233 Transform: Type = 1 (Encryption Algorithm), ID = 16 ENCR_AES_CCM_16 Attribute: Type = 14 (Key Length), Value = 128 Transform: Type = 1 (Encryption Algorithm), ID = 16 ENCR_AES_CCM_16 Attribute: Type = 14 (Key Length), Value = 192 Transform: Type = 1 (Encryption Algorithm), ID = 16 ENCR_AES_CCM_16 Attribute: Type = 14 (Key Length), Value = 256 Transform: Type = 5 (Extended Sequence Numbers), ID = 0 No ESN Transform: Type = 5 (Extended Sequence Numbers), ID = 1 ESN Transform: Type = 4 (Diffie-Hellman Group), ID = 5 1535-bit MODP Transform: Type = 4 (Diffie-Hellman Group), ID = 14 2048-bit MODP Transform: Type = 4 (Diffie-Hellman Group), ID = 15 3076-bit MODP Proposal #2: Protocol ID = 3 (ESP), SPI Size = 4, SPI = 0x58293233 Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC Attribute: Type = 14 (Key Length), Value = 128 Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC Attribute: Type = 14 (Key Length), Value = 192 Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC Attribute: Type = 14 (Key Length), Value = 256 Transform: Type = 2 (Integrity Algorithm), ID = 2 AUTH_HMAC_SHA1_96 Transform: Type = 2 (Integrity Algorithm), ID = 5 AUTH_AES_XCBC_96 Transform: Type = 5 (Extended Sequence Numbers), ID = 0 No ESN Transform: Type = 5 (Extended Sequence Numbers), ID = 1 ESN Transform: Type = 4 (Diffie-Hellman Group), ID = 5 1535-bit MODP Transform: Type = 4 (Diffie-Hellman Group), ID = 14 2048-bit MODP Transform: Type = 4 (Diffie-Hellman Group), ID = 15 3076-bit MODP Note, how the ESN and Diffie-Hellman groups are included in both proposals. For ESN that would not be mandatory, as it would be possible for example to support ESN only with combined mode ciphers, and non-combined mode ciphers would always say No ESN. For Diffie-Hellman Groups the situation is different, as the KE payload is shared with both proposals, meaning the Diffie-Hellman group used in KE payload group must be something that is proposed in both proposals. The return packet from the responder selecting combined mode ciphers could have following proposal: Proposal #1: Protocol ID = 3 (ESP), SPI Size = 4, SPI = 0x58293233 Transform: Type = 1 (Encryption Algorithm), ID = 16 ENCR_AES_CCM_16 Attribute: Type = 14 (Key Length), Value = 192 Transform: Type = 5 (Extended Sequence Numbers), ID = 1 ESN Transform: Type = 4 (Diffie-Hellman Group), ID = 14 2048-bit MODP The return packet from the responder selecting AES_CBC could have following proposal: Proposal #2: Protocol ID = 3 (ESP), SPI Size = 4, SPI = 0x58293233 Transform: Type = 1 (Encryption Algorithm), ID = 12 ENCR_AES_CBC Attribute: Type = 14 (Key Length), Value = 128 Transform: Type = 2 (Integrity Algorithm), ID = 2 AUTH_HMAC_SHA1_96 Transform: Type = 5 (Extended Sequence Numbers), ID = 1 ESN Transform: Type = 4 (Diffie-Hellman Group), ID = 5 1535-bit MODP ---------------------------------------------------------------------- If we add such sections, then we might want to remove some of the other text I already sent about combined mode ciphers, as this already explains them. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 25 05:55:02 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92D3F3A6890; Thu, 25 Sep 2008 05:55:02 -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 230413A6890 for ; Thu, 25 Sep 2008 05:55:01 -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 Ctwivd87W++C for ; Thu, 25 Sep 2008 05:55:00 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 668143A687A for ; Thu, 25 Sep 2008 05:54:41 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8PCsG0J027451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Sep 2008 15:54:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8PCsFmw017353; Thu, 25 Sep 2008 15:54:15 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18651.35319.208797.353962@fireball.kivinen.iki.fi> Date: Thu, 25 Sep 2008 15:54:15 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <18574.24516.764629.590327@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 11 min X-Total-Time: 10 min Cc: ipsec@ietf.org, Paul Hoffman Subject: [IPsec] Issue #14: Bounding the retransmit time X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > > Responder are allowed to forget response after long timeout for the > > memory saving purposes. The timeout must be longer than several > > minutes that could be used for the retransmission timers of the > > other end. ... > Responders MAY forget responses X minutes after first generating > them, as retransmissions of the requests are expected to be done > by then. Responders SHOULD ignore all subsequent retransmissions > of the request. Initiators MUST cease retransmitting requests if > no response has been received within X minutes. In such a case, > the Initiator MUST deem the IKE SA to have failed. As we do not have any specific time interval mentioned in the RFC about the retransmissions in general (except "at least a dozen times over a period of at least several minutes"), I think we do NOT want to put any specific time here. I think it is better to just say that the time limit used when forgetting responses should be longer than the other end's retransmission timers. The end forgetting the response, cannot of course know the exact timer used, thus we cannot say any that the time MUST/SHOULD be longer. Adding text about the responders ignoring retransmissions after that is good and needed (it MUST NOT fail the IKE SA in those cases, as that would open DoS attack). I am not sure if we need the text saying that Initiators MUST cease retransmitting, as that is normally what happens anyways if no response is received from the other end, but having that text there might clarify things even more. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 25 12:48:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9979E3A6985; Thu, 25 Sep 2008 12:48: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 2916B3A6985; Thu, 25 Sep 2008 12:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 EIFD8v+pFg3Y; Thu, 25 Sep 2008 12:48:14 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 4710E3A689D; Thu, 25 Sep 2008 12:48:14 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e6.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8PJoBf4001834; Thu, 25 Sep 2008 15:50:11 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8PJk2K2196066; Thu, 25 Sep 2008 13:46:02 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8PJk2EY027029; Thu, 25 Sep 2008 13:46:02 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8PJk146027019; Thu, 25 Sep 2008 13:46:01 -0600 In-Reply-To: <73EC141C-02C8-41AE-B1E7-53E728948BF6@checkpoint.com> References: <18650.6525.154879.851858@fireball.kivinen.iki.fi> <73EC141C-02C8-41AE-B1E7-53E728948BF6@checkpoint.com> MIME-Version: 1.0 X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 09/25/2008 03:45:28 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 09/25/2008 03:45:28 PM, Serialize complete at 09/25/2008 03:45:28 PM, S/MIME Sign failed at 09/25/2008 03:45:28 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_M2_08202008HFIGS1|August 20, 2008) at 09/25/2008 13:46:01, Serialize complete at 09/25/2008 13:46:01 To: Yoav Nir X-KeepSent: 9F9189E1:6D3F6EF7-852574CF:0067A620; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen Message-ID: Date: Thu, 25 Sep 2008 15:46:00 -0400 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Tero Kivinen , Keith Welter Subject: Re: [IPsec] INVALID_IKE_SPI questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0655674130==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0655674130== Content-Type: multipart/alternative; boundary="=_alternative 006C9126852574CF_=" This is a multipart message in MIME format. --=_alternative 006C9126852574CF_= Content-Type: text/plain; charset="US-ASCII" > I took it to be 37 (INFORMATIONAL) because it's an error message sent > outside the context of an IKE SA, which CCSA should not be. The main downside of this approach is that in the case of INVALID_IKE_SPI it's intended to be a response message (4306 says "MAY send a response," ikev2bis says it "is a response message"), and by tagging the response as having a different exchange but the same message ID as the original request message, it's quite possible that the original sender will simply discard this response as not matching any of its open exchanges, without ever reaching the point of processing the INVALID_IKE_SPI notify. It seems to me that retaining the original exchange type will improve the likelihood of the original sender's processing the notify. ikev2bis does say "MAY send an Informational message" for this case. If we choose to have the INVALID_IKE_SPI case reuse the original request's exchange type, we should rewrite that phrasing so that it is clear that only the INVALID_SPI case necessarily has an Informational exchange type. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yoav Nir To: Tero Kivinen Cc: ipsec@ietf.org, Keith Welter/Raleigh/IBM@IBMUS Date: 09/24/2008 06:55 AM Subject: Re: [IPsec] INVALID_IKE_SPI questions On Sep 24, 2008, at 1:42 PM, Tero Kivinen wrote: > Keith Welter writes: >> For the one-way INVALID_IKE_SPI notification described in RFC 4306 >> section >> 1.5, it is unclear to me what the Exchange Type should be in the IKE >> header. Should it be 37 (INFORMATIONAL) or should it be copied >> from the >> request that contained the unrecognized SPI? > > From RFC 4306 section 2.21: > > If a node receives a message on UDP port 500 or 4500 outside the > context of an IKE_SA known to it (and not a request to start one), > it > may be the result of a recent crash of the node. If the message is > marked as a response, the node MAY audit the suspicious event but > MUST NOT respond. If the message is marked as a request, the node > MAY audit the suspicious event and MAY send a response. If a > response is sent, the response MUST be sent to the IP address and > port from whence it came with the same IKE SPIs and the Message ID > copied. The response MUST NOT be cryptographically protected and > MUST contain a Notify payload indicating INVALID_IKE_SPI. > > As the text says you copy IKE SPIs and Message ID, I would interpret > that response being normal error response, meaning that the exchange > type is also copied. Perhaps this should be clarified in the IKEv2bis? I took it to be 37 (INFORMATIONAL) because it's an error message sent outside the context of an IKE SA, which CCSA should not be. It's also more similar to INVALID_SPI like this, but that's probably not a good argument. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 006C9126852574CF_= Content-Type: text/html; charset="US-ASCII"
> I took it to be 37 (INFORMATIONAL) because it's an error message sent  
> outside the context of an IKE SA, which CCSA should not be.

The main downside of this approach is that in the case of INVALID_IKE_SPI it's intended to be a response message (4306 says "MAY send a response," ikev2bis says it "is a response message"), and by tagging the response as having a different exchange but the same message ID as the original request message, it's quite possible that the original sender will simply discard this response as not matching any of its open exchanges, without ever reaching the point of processing the INVALID_IKE_SPI notify.  It seems to me that retaining the original exchange type will improve the likelihood of the original sender's processing the notify.

ikev2bis does say "MAY send an Informational message" for this case.  If we choose to have the INVALID_IKE_SPI case reuse the original request's exchange type, we should rewrite that phrasing so that it is clear that only the INVALID_SPI case necessarily has an Informational exchange type.


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


From: Yoav Nir <ynir@checkpoint.com>
To: Tero Kivinen <kivinen@iki.fi>
Cc: ipsec@ietf.org, Keith Welter/Raleigh/IBM@IBMUS
Date: 09/24/2008 06:55 AM
Subject: Re: [IPsec] INVALID_IKE_SPI questions





On Sep 24, 2008, at 1:42 PM, Tero Kivinen wrote:

> Keith Welter writes:
>> For the one-way INVALID_IKE_SPI notification described in RFC 4306  
>> section
>> 1.5, it is unclear to me what the Exchange Type should be in the IKE
>> header.  Should it be 37 (INFORMATIONAL) or should it be copied  
>> from the
>> request that contained the unrecognized SPI?
>
> From RFC 4306 section 2.21:
>
>   If a node receives a message on UDP port 500 or 4500 outside the
>   context of an IKE_SA known to it (and not a request to start one),  
> it
>   may be the result of a recent crash of the node.  If the message is
>   marked as a response, the node MAY audit the suspicious event but
>   MUST NOT respond.  If the message is marked as a request, the node
>   MAY audit the suspicious event and MAY send a response.  If a
>   response is sent, the response MUST be sent to the IP address and
>   port from whence it came with the same IKE SPIs and the Message ID
>   copied.  The response MUST NOT be cryptographically protected and
>   MUST contain a Notify payload indicating INVALID_IKE_SPI.
>
> As the text says you copy IKE SPIs and Message ID, I would interpret
> that response being normal error response, meaning that the exchange
> type is also copied. Perhaps this should be clarified in the IKEv2bis?

I took it to be 37 (INFORMATIONAL) because it's an error message sent  
outside the context of an IKE SA, which CCSA should not be.

It's also more similar to INVALID_SPI like this, but that's probably  
not a good argument.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 006C9126852574CF_=-- --===============0655674130== 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 --===============0655674130==-- From ipsec-bounces@ietf.org Thu Sep 25 12:55:46 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1633A695F; Thu, 25 Sep 2008 12:55: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 E97343A6972 for ; Thu, 25 Sep 2008 12:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 uwXeO0e0jOJk for ; Thu, 25 Sep 2008 12:55:45 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 02D023A696A for ; Thu, 25 Sep 2008 12:55:44 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8PJlQTE007099 for ; Thu, 25 Sep 2008 15:47:26 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8PJtUAN206780 for ; Thu, 25 Sep 2008 13:55:31 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8Q1tUh6031403 for ; Thu, 25 Sep 2008 19:55:30 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8Q1tUH1031396 for ; Thu, 25 Sep 2008 19:55:30 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 09/25/2008 12:55:26 PM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 09/25/2008 12:55:26 PM, Serialize complete at 09/25/2008 12:55:26 PM, S/MIME Sign failed at 09/25/2008 12:55:26 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_M2_08202008HFIGS1|August 20, 2008) at 09/25/2008 13:55:30, Serialize complete at 09/25/2008 13:55:30 Message-ID: Date: Thu, 25 Sep 2008 12:55:29 -0700 Subject: [IPsec] Comment on ikev2bis section 2.4 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1167380665==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1167380665== Content-Type: multipart/alternative; boundary="=_alternative 006D720B882574CF_=" This is a multipart message in MIME format. --=_alternative 006D720B882574CF_= Content-Type: text/plain; charset="US-ASCII" >From ikev2bis section 2.4: {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this IKE_SA is the only IKE_SA currently active between the authenticated identities. It MAY be sent when an IKE_SA is established after a crash, and the recipient MAY use this information to delete any other IKE_SAs it has to the same authenticated identity without waiting for a timeout. This notification MUST NOT be sent by an entity that may be replicated (e.g., a roaming user's credentials where the user is allowed to connect to the corporate firewall from two remote systems at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH request, not as a separate exchange afterwards; however, receiving parties need to deal with it in other requests. How can the assertion described in the first sentence be made by the sender of the IKE_AUTH request since the identities are not authenticated until the IKE_AUTH response is received? Furthermore, it seems that even if the "authenticated" condition is dropped from the first sentence, the IKE_AUTH request would need to contain the optional IDr payload in order for INITIAL_CONTACT to make sense in this message. Keith Welter IBM Enterprise Networking Solutions 1-415-545-2694 (T/L: 473-2694) --=_alternative 006D720B882574CF_= Content-Type: text/html; charset="US-ASCII"
From ikev2bis section 2.4:
   {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this
  IKE_SA is the only IKE_SA currently active between the authenticated
  identities.  It MAY be sent when an IKE_SA is established after a
  crash, and the recipient MAY use this information to delete any other
  IKE_SAs it has to the same authenticated identity without waiting for
  a timeout.  This notification MUST NOT be sent by an entity that may
  be replicated (e.g., a roaming user's credentials where the user is
  allowed to connect to the corporate firewall from two remote systems
  at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification,
  if sent, MUST be in the first IKE_AUTH request, not as a separate
  exchange afterwards; however, receiving parties need to deal with it
  in other requests.

How can the assertion described in the first sentence be made by the sender of the IKE_AUTH request since the identities are not authenticated until the IKE_AUTH response is received?  Furthermore, it seems that even if the "authenticated" condition is dropped from the first sentence, the IKE_AUTH request would need to contain the optional IDr payload in order for INITIAL_CONTACT to make sense in this message.

Keith Welter
IBM Enterprise Networking Solutions
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 006D720B882574CF_=-- --===============1167380665== 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 --===============1167380665==-- From ipsec-bounces@ietf.org Thu Sep 25 14:13:19 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1EA23A6969; Thu, 25 Sep 2008 14:13: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 362463A693C for ; Thu, 25 Sep 2008 14:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_43=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 dpqFaoeAiGWo for ; Thu, 25 Sep 2008 14:13:18 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id EB72E3A68E7 for ; Thu, 25 Sep 2008 14:13:17 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id F23FD294002; Fri, 26 Sep 2008 00:13:25 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 21472294001 for ; Fri, 26 Sep 2008 00:13:25 +0300 (IDT) Received: from [172.31.21.22] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8PLDOSJ005397 for ; Fri, 26 Sep 2008 00:13:24 +0300 (IDT) Message-Id: <99C3CC45-7F00-4441-9293-6241B6AF62F3@checkpoint.com> From: Yoav Nir To: ipsec@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 26 Sep 2008 00:13:23 +0300 X-Mailer: Apple Mail (2.929.2) Subject: [IPsec] Hash & URL for certificates X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi. I know what I'm proposing below is a protocol change, but I'm going to propose it anyway. Section 3.6 (Certificate Payload) of the bis document says the following: > Implementations MUST be capable of being configured to send and > accept up to four X.509 certificates in support of authentication, > and also MUST be capable of being configured to send and accept the > two Hash and URL formats (with HTTP URLs). Implementations SHOULD be > capable of being configured to send and accept Raw RSA keys. If > multiple certificates are sent, the first certificate MUST contain > the public key used to sign the AUTH payload. The other certificates > may be sent in any order. Frankly, I hate this entire paragraph, because it mandates configuration abilities for implementations. It should be perfectly fine to have specialized implementations that, for example, are remote- access clients that do not support sending certificates at all. To allow so-called "minimal" implementations we do not mandate support for Create_Child_SA and rekeying, we do not mandate support for NAT-T, CFG or EAP, or for window sizes greater than 1. And yet here we are mandating that every compliant implementation support chains of 4 certificates. But the really bad part is that every implementation MUST be capable of being configured to send and accept the two Hash&URL formats. That means that every IKEv2 implementation MUST have an HTTP client (to fetch the certs). Implementations without support for the Hash&URL format are not compliant. I know there are several implementations that do not support this, mine included. Since implementations currently "MUST be capable of being configured..." but not "MUST be configured..." it's entirely possible that a particular peer will not support Hash&URL, so what I propose will not harm interoperability. I suggest that at least this requirement be demoted to MAY or SHOULD. IMO Hash&URL is a specialty feature that's appropriate for some environments but not others. There is an illuminated discussion about a similar extension to TLS going on right now on the TLS mailing list. While we're at it, I suggest demoting the 4-certificate requirement to a SHOULD as far as sending is concerned. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 25 22:55:08 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF2D3A6AAC; Thu, 25 Sep 2008 22:55: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 480A33A67BD for ; Thu, 25 Sep 2008 22:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=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 pSnDj3UhsIJ7 for ; Thu, 25 Sep 2008 22:55:06 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 58AD73A6850 for ; Thu, 25 Sep 2008 22:55:05 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 33634294002; Fri, 26 Sep 2008 08:23:43 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6CF15294001 for ; Fri, 26 Sep 2008 08:21:56 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m8Q5LtSJ007749 for ; Fri, 26 Sep 2008 08:21:55 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Fri, 26 Sep 2008 08:21:55 +0300 From: Yaron Sheffer To: Yoav Nir , "ipsec@ietf.org" Date: Fri, 26 Sep 2008 08:21:52 +0300 Thread-Topic: [IPsec] Hash & URL for certificates Thread-Index: AckfU5SSDoPQbGTDSbuPslFCv3WAhQAQd9rQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E69A0@il-ex01.ad.checkpoint.com> References: <99C3CC45-7F00-4441-9293-6241B6AF62F3@checkpoint.com> In-Reply-To: <99C3CC45-7F00-4441-9293-6241B6AF62F3@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] Hash & URL for certificates X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0581940262==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0581940262== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0063_01C91FB0.EE1B6E10" ------=_NextPart_000_0063_01C91FB0.EE1B6E10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Yoav, In my reading, "MUST be capable of being configured" is exactly the same as "MUST implement", which is what we specify in RFCs. It's just a white box way of ensuring it, vs. the black box "reverse engineer the code to find out if the feature is really there". So I have no problem with this wording. I dislike the Hash-and-URL mechanism myself, it has the potential to add countless security vulnerabilities to an IPsec implementation. But I am strongly opposed to your proposal. The text you are quoting appears in RFC 4306, and we must not (MUST NOT) use the work on bis as an excuse to open up design decisions that we made in 4306. Both for the pragmatic reason that everybody has their own set of favorite changes (which they view as "corrections") to the spec, and this debate could drag on for years; and also because the industry needs a stable specification for a while, as IKEv2 implementations are starting to emerge. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Friday, September 26, 2008 0:13 To: ipsec@ietf.org Subject: [IPsec] Hash & URL for certificates Hi. I know what I'm proposing below is a protocol change, but I'm going to propose it anyway. Section 3.6 (Certificate Payload) of the bis document says the following: > Implementations MUST be capable of being configured to send and > accept up to four X.509 certificates in support of authentication, > and also MUST be capable of being configured to send and accept the > two Hash and URL formats (with HTTP URLs). Implementations SHOULD be > capable of being configured to send and accept Raw RSA keys. If > multiple certificates are sent, the first certificate MUST contain > the public key used to sign the AUTH payload. The other certificates > may be sent in any order. Frankly, I hate this entire paragraph, because it mandates configuration abilities for implementations. It should be perfectly fine to have specialized implementations that, for example, are remote- access clients that do not support sending certificates at all. To allow so-called "minimal" implementations we do not mandate support for Create_Child_SA and rekeying, we do not mandate support for NAT-T, CFG or EAP, or for window sizes greater than 1. And yet here we are mandating that every compliant implementation support chains of 4 certificates. But the really bad part is that every implementation MUST be capable of being configured to send and accept the two Hash&URL formats. That means that every IKEv2 implementation MUST have an HTTP client (to fetch the certs). Implementations without support for the Hash&URL format are not compliant. I know there are several implementations that do not support this, mine included. Since implementations currently "MUST be capable of being configured..." but not "MUST be configured..." it's entirely possible that a particular peer will not support Hash&URL, so what I propose will not harm interoperability. I suggest that at least this requirement be demoted to MAY or SHOULD. IMO Hash&URL is a specialty feature that's appropriate for some environments but not others. There is an illuminated discussion about a similar extension to TLS going on right now on the TLS mailing list. While we're at it, I suggest demoting the 4-certificate requirement to a SHOULD as far as sending is concerned. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0063_01C91FB0.EE1B6E10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDkyNjA1MjE1MlowIwYJKoZIhvcNAQkEMRYEFLLzKoWrHLQv PXK4wF+Y3++iIJfCMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA SvMfKZLhOi0wF8OyiXxxP71Pty9fazcCvvNhRK0RIATwtX1YHdmyPx0sLPV46bnqnL60rp6SxkYP GyibYJ7e3JgjhZlirLZzGJ3NaBJZD4WoscXXU2XVkxeCLxVz9Rm9EvqoWmvM5Y+J5gTADeunD7qA h+FS4gY+SIOTOznZElrMwkvGYcteDT2uD9h+DN0qyxe8YOlY3yLT5WF5i/nyGtodIcY9lXV7EsDR 0lhF1XWg8S4QGzDp2xtFOXOgHbm0NqPwgH87Y7AO3k2Pwoo9dUET/g45knqItt05DTcCzus2vtw8 NHnfiMqH63CZmCZzSRiKE29MAAYdRZwIsPxzJQAAAAAAAA== ------=_NextPart_000_0063_01C91FB0.EE1B6E10-- --===============0581940262== 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 --===============0581940262==-- From ipsec-bounces@ietf.org Fri Sep 26 01:27:27 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8824328C189; Fri, 26 Sep 2008 01:27:27 -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 3638328C189 for ; Fri, 26 Sep 2008 01:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, J_CHICKENPOX_43=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 O2NbN9F0SfB1 for ; Fri, 26 Sep 2008 01:27:17 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E10A228C188 for ; Fri, 26 Sep 2008 01:27:16 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 51044294003; Fri, 26 Sep 2008 11:27:25 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6A37B294001 for ; Fri, 26 Sep 2008 11:27:24 +0300 (IDT) Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id m8Q8RNSS006044 for ; Fri, 26 Sep 2008 11:27:24 +0300 (IDT) Message-Id: From: Yoav Nir To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E69A0@il-ex01.ad.checkpoint.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 26 Sep 2008 11:27:14 +0300 References: <99C3CC45-7F00-4441-9293-6241B6AF62F3@checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8C5A76E69A0@il-ex01.ad.checkpoint.com> X-Mailer: Apple Mail (2.929.2) Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Hash & URL for certificates X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I'm afraid it's going to make most products non-compliant. There are library implementations out there with Hash&URL: strongSwan, openIKEv2, probably others. But a library is not the same as an implementation. Sure you can just run strongSwan as is, and configure it using large text files in the / etc directory, but that is not the usual way IPsec is used. You usually have a product that packages a library (open or closed source) with a user interface. This feature is so obscure, that I believe many vendors (open-source user interfaces tend to suffer from the design-by-committee syndrome that means all the text file features are there) will omit Hash&URL and end up with non-compliant products. Demoting the MUST to SHOULD allows them to not support Hash&URL if there's a good reason, such as "our users don't have web servers to store their certificates on." On Sep 26, 2008, at 8:21 AM, Yaron Sheffer wrote: > Hi Yoav, > > In my reading, "MUST be capable of being configured" is exactly the > same as > "MUST implement", which is what we specify in RFCs. It's just a > white box > way of ensuring it, vs. the black box "reverse engineer the code to > find out > if the feature is really there". So I have no problem with this > wording. > > I dislike the Hash-and-URL mechanism myself, it has the potential to > add > countless security vulnerabilities to an IPsec implementation. > > But I am strongly opposed to your proposal. The text you are quoting > appears > in RFC 4306, and we must not (MUST NOT) use the work on bis as an > excuse to > open up design decisions that we made in 4306. Both for the > pragmatic reason > that everybody has their own set of favorite changes (which they > view as > "corrections") to the spec, and this debate could drag on for years; > and > also because the industry needs a stable specification for a while, > as IKEv2 > implementations are starting to emerge. > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On > Behalf Of > Yoav Nir > Sent: Friday, September 26, 2008 0:13 > To: ipsec@ietf.org > Subject: [IPsec] Hash & URL for certificates > > Hi. > > I know what I'm proposing below is a protocol change, but I'm going to > propose it anyway. > > Section 3.6 (Certificate Payload) of the bis document says the > following: >> Implementations MUST be capable of being configured to send and >> accept up to four X.509 certificates in support of authentication, >> and also MUST be capable of being configured to send and accept the >> two Hash and URL formats (with HTTP URLs). Implementations SHOULD be >> capable of being configured to send and accept Raw RSA keys. If >> multiple certificates are sent, the first certificate MUST contain >> the public key used to sign the AUTH payload. The other certificates >> may be sent in any order. > Frankly, I hate this entire paragraph, because it mandates > configuration abilities for implementations. It should be perfectly > fine to have specialized implementations that, for example, are > remote- > access clients that do not support sending certificates at all. > To allow so-called "minimal" implementations we do not mandate support > for Create_Child_SA and rekeying, we do not mandate support for NAT-T, > CFG or EAP, or for window sizes greater than 1. > And yet here we are mandating that every compliant implementation > support chains of 4 certificates. But the really bad part is that > every implementation MUST be capable of being configured to send and > accept the two Hash&URL formats. That means that every IKEv2 > implementation MUST have an HTTP client (to fetch the certs). > Implementations without support for the Hash&URL format are not > compliant. > I know there are several implementations that do not support this, > mine included. Since implementations currently "MUST be capable of > being configured..." but not "MUST be configured..." it's entirely > possible that a particular peer will not support Hash&URL, so what I > propose will not harm interoperability. > I suggest that at least this requirement be demoted to MAY or SHOULD. > IMO Hash&URL is a specialty feature that's appropriate for some > environments but not others. There is an illuminated discussion about > a similar extension to TLS going on right now on the TLS mailing list. > While we're at it, I suggest demoting the 4-certificate requirement to > a SHOULD as far as sending is concerned. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > > Scanned by Check Point Total Security Gateway. > _______________________________________________ > 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 Sep 26 02:12:56 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5053A6B3A; Fri, 26 Sep 2008 02:12:55 -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 055DD3A6B32 for ; Fri, 26 Sep 2008 02:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 8lWDNg43xWnw for ; Fri, 26 Sep 2008 02:12:45 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 7B7513A68F5 for ; Fri, 26 Sep 2008 02:12:30 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8Q9CWTS010081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2008 12:12:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8Q9CVW6009688; Fri, 26 Sep 2008 12:12:31 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18652.42879.953190.973639@fireball.kivinen.iki.fi> Date: Fri, 26 Sep 2008 12:12:31 +0300 From: Tero Kivinen To: Keith Welter In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 14 min X-Total-Time: 14 min Cc: ipsec@ietf.org Subject: [IPsec] Comment on ikev2bis section 2.4 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Keith Welter writes: > >From ikev2bis section 2.4: > {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this > IKE_SA is the only IKE_SA currently active between the authenticated > identities. It MAY be sent when an IKE_SA is established after a > crash, and the recipient MAY use this information to delete any other > IKE_SAs it has to the same authenticated identity without waiting for > a timeout. This notification MUST NOT be sent by an entity that may > be replicated (e.g., a roaming user's credentials where the user is > allowed to connect to the corporate firewall from two remote systems > at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification, > if sent, MUST be in the first IKE_AUTH request, not as a separate > exchange afterwards; however, receiving parties need to deal with it > in other requests. > > How can the assertion described in the first sentence be made by the > sender of the IKE_AUTH request since the identities are not authenticated > until the IKE_AUTH response is received? I have implemented it so that we do do mark the initial contact being received when we see the notification, and then when the full IKE SA negotiation is finished (i.e. authenticated successufully), we process the INITIAL_CONTACT notification. Of course you should not act on the INITIAL_CONTACT immediately, but only after the other end is authenticated himself. If the initiator is using EAP to authenticate him, then he is authenticated only after last IKE_AUTH request is processed. > Furthermore, it seems that even if the "authenticated" condition is > dropped from the first sentence, the IKE_AUTH request would need to > contain the optional IDr payload in order for INITIAL_CONTACT to > make sense in this message. The first IKE_AUTH request from initiator to responder will have the IDi, which gives the identity of the initiator, and if there is INITIAL_CONTACT notification in the same packet the responder will know that the identity of the other end will be IDi after the full authentication is finished. If no EAP is used, then the responder can immediately process the AUTH payload too, and will authenticate the other end while processing the request. If EAP is used, then initiator will be authenticated only at the last IKE_AUTH request, thus processing of the INITIAL_CONTACT should be postponed until that. It still makes sense to send the INITIAL_CONTACT in the same packet where the IDi is sent, thus thats why it is sent inside the first IKE_AUTH message. For the responder to send INITIAL_CONTACT to initiator is usually not that useful, as initiator already told the responder that he most likely do not have valid IKE SA with the responder, because he started the IKE SA creation in the first place. The current text added by the clarification actually forbids responder for sending INITIAL_CONTACT, as it says the INITIAL_CONTACT MUST be in the first IKE_AUTH *request*, which means it cannot be in the IKE_AUTH reply sent back by the responder. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 26 04:03:06 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF503A69BD; Fri, 26 Sep 2008 04:03: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 F2BB53A69BD for ; Fri, 26 Sep 2008 04:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=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 3eO+5tvIW5U0 for ; Fri, 26 Sep 2008 04:03:04 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 856D93A6870 for ; Fri, 26 Sep 2008 04:01:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8QB0uW2010461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Sep 2008 14:00:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8QB0tun029081; Fri, 26 Sep 2008 14:00:55 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18652.49383.426881.734048@fireball.kivinen.iki.fi> Date: Fri, 26 Sep 2008 14:00:55 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <99C3CC45-7F00-4441-9293-6241B6AF62F3@checkpoint.com> References: <99C3CC45-7F00-4441-9293-6241B6AF62F3@checkpoint.com> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 16 min X-Total-Time: 103 min Cc: ipsec@ietf.org Subject: [IPsec] Hash & URL for certificates X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Yoav Nir writes: > And yet here we are mandating that every compliant implementation > support chains of 4 certificates. PKIX Certificates are already MUST in section 4. The text saying you "MUST be capable of being configured to send and accept up to four X.509 certificates in support of authentication" does NOT necessarely mean you have to support full chains in your certificates libraries. If It would want to say you MUST support certificate chains up to 4 certificates it would say so. It would be quite ok for your implementation to be manually configured to check that it gets certificate which has the public key mathing the public key given in configuration for the remote end and accept and ignore the other certificates sent by the other end. I.e. it could use the first certificate as Raw RSA key and compare that Raw RSA against its configuration. Again, same implementation could be configured to send up to 4 certificates out, and not bother about what they really mean. > But the really bad part is that every implementation MUST be capable > of being configured to send and accept the two Hash&URL formats. > That means that every IKEv2 implementation MUST have an HTTP client > (to fetch the certs). Again, there is no requirement for actually adding http-client or server to either end. The URL pointing to the certificate can also point to some external server (for example web-server provided by CA). Again the certificate can be preconfigured to the system in minimal implementations, i.e. it can just verify that the hash given in the ash and url must match the one preconfigured in to the system. It must be configured to send the hash&URL of its own certificate so if the other end has full implementation it can fetch the certificate (if it does not already have it) from the external http-server. Also it must be able to accept incoming hash&URL so it can check if hash matches the certificates it already hash. There is no requirement for it to actually being able to fetch the certificates using HTTP (i.e. if it does not send HTTP_CERT_LOOKUP_SUPPORTED then it does not support fetching certificates over http). > Implementations without support for the Hash&URL format are not > compliant. True, so such implementations should add support for them to be compliant. > I know there are several implementations that do not support this, > mine included. Since implementations currently "MUST be capable of > being configured..." but not "MUST be configured..." it's entirely > possible that a particular peer will not support Hash&URL, so what I > propose will not harm interoperability. The reason for that requirement is that should have implementations that can be configured to work with certificates which are too large to be sent inside the IKE because of the fragmentation issues. In those cases by sending only hash of the certificate we can reduce the size of the packet. It is up to the implementations whether they actually use the URL to fecth the certificate, or if they use some other methods (LDAP, preconfigured certificates, CA specific certificate retrieval protocol) to fetch the certificate. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 26 05:50:52 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36DC73A6AEB; Fri, 26 Sep 2008 05:50:52 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA7B83A6AE3; Fri, 26 Sep 2008 05:50:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 BjHyY3ZZ2Ln7; Fri, 26 Sep 2008 05:50:44 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id A26433A689E; Fri, 26 Sep 2008 05:50:44 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8QConht007363; Fri, 26 Sep 2008 08:50:49 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8QCoV5C182818; Fri, 26 Sep 2008 06:50:42 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8QCoV5A030637; Fri, 26 Sep 2008 06:50:31 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8QCoVcZ030630; Fri, 26 Sep 2008 06:50:31 -0600 In-Reply-To: <18652.42879.953190.973639@fireball.kivinen.iki.fi> References: <18652.42879.953190.973639@fireball.kivinen.iki.fi> MIME-Version: 1.0 X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 09/26/2008 08:28:23 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 09/26/2008 08:28:23 AM, Serialize complete at 09/26/2008 08:28:23 AM, S/MIME Sign failed at 09/26/2008 08:28:23 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_M2_08202008HFIGS1|August 20, 2008) at 09/26/2008 06:50:30, Serialize complete at 09/26/2008 06:50:30 To: Tero Kivinen X-KeepSent: D8EFA55A:399D1BC0-852574D0:003F74C3; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen Message-ID: Date: Fri, 26 Sep 2008 08:50:29 -0400 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Keith Welter Subject: Re: [IPsec] Comment on ikev2bis section 2.4 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0627657141==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0627657141== Content-Type: multipart/alternative; boundary="=_alternative 0045D346852574D0_=" This is a multipart message in MIME format. --=_alternative 0045D346852574D0_= Content-Type: text/plain; charset="US-ASCII" Hi Tero, the problem is this: how does the initiator know when to send INITIAL_CONTACT? How can the initiator know that this is the first SA "between the authenticated identities" when the initiator does not yet know IDr? This might be the case because the initiator's PAD entry has a wildcarded remote identity, or it might be the case because the initiator has overlapping PAD entries and allows the peer to send an IDr differing from the initiator's optional IDr payload. In either case, the initiator does not have enough information when it sends the IKE_AUTH request to know conclusively that this is the first SA "between the authenticated identities" simply because it does not know both authenticated identities. For a mobile device bringing up its first and only IKE SA, this is not a problem. But for a multi-homed server bringing up a dozen IKE SAs after reboot, it is problematic. There may also be a (strained) use case for the responder's sending INITIAL_CONTACT. If the responder uses NO_ADDITIONAL_SAs to limit one child SA per IKE SA, the initiator may have multiple IKE SAs to the responder. If the responder reboots and a liveness exchange causes one of those SAs to be deleted and a new one to be negotiated, it would be helpful to receive an INITIAL_CONTACT from the responder to allow for the other IKE SAs to be cleaned up. Perhaps we should only recommend an implementation send INITIAL_CONTACT as responder if it has this limitation of one child SA per IKE SA. But that suggests we should allow for receiving INITIAL_CONTACT from a responder in any case. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Keith Welter/Raleigh/IBM@IBMUS Cc: ipsec@ietf.org Date: 09/26/2008 05:15 AM Subject: [IPsec] Comment on ikev2bis section 2.4 Keith Welter writes: > >From ikev2bis section 2.4: > {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this > IKE_SA is the only IKE_SA currently active between the authenticated > identities. It MAY be sent when an IKE_SA is established after a > crash, and the recipient MAY use this information to delete any other > IKE_SAs it has to the same authenticated identity without waiting for > a timeout. This notification MUST NOT be sent by an entity that may > be replicated (e.g., a roaming user's credentials where the user is > allowed to connect to the corporate firewall from two remote systems > at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification, > if sent, MUST be in the first IKE_AUTH request, not as a separate > exchange afterwards; however, receiving parties need to deal with it > in other requests. > > How can the assertion described in the first sentence be made by the > sender of the IKE_AUTH request since the identities are not authenticated > until the IKE_AUTH response is received? I have implemented it so that we do do mark the initial contact being received when we see the notification, and then when the full IKE SA negotiation is finished (i.e. authenticated successufully), we process the INITIAL_CONTACT notification. Of course you should not act on the INITIAL_CONTACT immediately, but only after the other end is authenticated himself. If the initiator is using EAP to authenticate him, then he is authenticated only after last IKE_AUTH request is processed. > Furthermore, it seems that even if the "authenticated" condition is > dropped from the first sentence, the IKE_AUTH request would need to > contain the optional IDr payload in order for INITIAL_CONTACT to > make sense in this message. The first IKE_AUTH request from initiator to responder will have the IDi, which gives the identity of the initiator, and if there is INITIAL_CONTACT notification in the same packet the responder will know that the identity of the other end will be IDi after the full authentication is finished. If no EAP is used, then the responder can immediately process the AUTH payload too, and will authenticate the other end while processing the request. If EAP is used, then initiator will be authenticated only at the last IKE_AUTH request, thus processing of the INITIAL_CONTACT should be postponed until that. It still makes sense to send the INITIAL_CONTACT in the same packet where the IDi is sent, thus thats why it is sent inside the first IKE_AUTH message. For the responder to send INITIAL_CONTACT to initiator is usually not that useful, as initiator already told the responder that he most likely do not have valid IKE SA with the responder, because he started the IKE SA creation in the first place. The current text added by the clarification actually forbids responder for sending INITIAL_CONTACT, as it says the INITIAL_CONTACT MUST be in the first IKE_AUTH *request*, which means it cannot be in the IKE_AUTH reply sent back by the responder. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0045D346852574D0_= Content-Type: text/html; charset="US-ASCII"
Hi Tero, the problem is this: how does the initiator know when to send INITIAL_CONTACT?  How can the initiator know that this is the first SA "between the authenticated identities" when the initiator does not yet know IDr?  This might be the case because the initiator's PAD entry has a wildcarded remote identity, or it might be the case because the initiator has overlapping PAD entries and allows the peer to send an IDr differing from the initiator's optional IDr payload.  In either case, the initiator does not have enough information when it sends the IKE_AUTH request to know conclusively that this is the first SA "between the authenticated identities" simply because it does not know both authenticated identities.  For a mobile device bringing up its first and only IKE SA, this is not a problem.  But for a multi-homed server bringing up a dozen IKE SAs after reboot, it is problematic.

There may also be a (strained) use case for the responder's sending INITIAL_CONTACT.  If the responder uses NO_ADDITIONAL_SAs to limit one child SA per IKE SA, the initiator may have multiple IKE SAs to the responder.  If the responder reboots and a liveness exchange causes one of those SAs to be deleted and a new one to be negotiated, it would be helpful to receive an INITIAL_CONTACT from the responder to allow for the other IKE SAs to be cleaned up.  Perhaps we should only recommend an implementation send INITIAL_CONTACT as responder if it has this limitation of one child SA per IKE SA.  But that suggests we should allow for receiving INITIAL_CONTACT from a responder in any case.


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


From: Tero Kivinen <kivinen@iki.fi>
To: Keith Welter/Raleigh/IBM@IBMUS
Cc: ipsec@ietf.org
Date: 09/26/2008 05:15 AM
Subject: [IPsec]  Comment on ikev2bis section 2.4




Keith Welter writes:
> >From ikev2bis section 2.4:
>    {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this
>    IKE_SA is the only IKE_SA currently active between the authenticated
>    identities.  It MAY be sent when an IKE_SA is established after a
>    crash, and the recipient MAY use this information to delete any other
>    IKE_SAs it has to the same authenticated identity without waiting for
>    a timeout.  This notification MUST NOT be sent by an entity that may
>    be replicated (e.g., a roaming user's credentials where the user is
>    allowed to connect to the corporate firewall from two remote systems
>    at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification,
>    if sent, MUST be in the first IKE_AUTH request, not as a separate
>    exchange afterwards; however, receiving parties need to deal with it
>    in other requests.
>
> How can the assertion described in the first sentence be made by the
> sender of the IKE_AUTH request since the identities are not authenticated
> until the IKE_AUTH response is received?

I have implemented it so that we do do mark the initial contact being
received when we see the notification, and then when the full IKE SA
negotiation is finished (i.e. authenticated successufully), we
process the INITIAL_CONTACT notification.

Of course you should not act on the INITIAL_CONTACT immediately, but
only after the other end is authenticated himself. If the initiator is
using EAP to authenticate him, then he is authenticated only after
last IKE_AUTH request is processed.

> Furthermore, it seems that even if the "authenticated" condition is
> dropped from the first sentence, the IKE_AUTH request would need to
> contain the optional IDr payload in order for INITIAL_CONTACT to
> make sense in this message.

The first IKE_AUTH request from initiator to responder will have the
IDi, which gives the identity of the initiator, and if there is
INITIAL_CONTACT notification in the same packet the responder will
know that the identity of the other end will be IDi after the full
authentication is finished. If no EAP is used, then the responder can
immediately process the AUTH payload too, and will authenticate the
other end while processing the request. If EAP is used, then initiator
will be authenticated only at the last IKE_AUTH request, thus
processing of the INITIAL_CONTACT should be postponed until that. It
still makes sense to send the INITIAL_CONTACT in the same packet where
the IDi is sent, thus thats why it is sent inside the first IKE_AUTH
message.

For the responder to send INITIAL_CONTACT to initiator is usually not
that useful, as initiator already told the responder that he most
likely do not have valid IKE SA with the responder, because he started
the IKE SA creation in the first place.

The current text added by the clarification actually forbids responder
for sending INITIAL_CONTACT, as it says the INITIAL_CONTACT MUST be in
the first IKE_AUTH *request*, which means it cannot be in the IKE_AUTH
reply sent back by the responder.
--
kivinen@safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 0045D346852574D0_=-- --===============0627657141== 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 --===============0627657141==-- From ipsec-bounces@ietf.org Mon Sep 29 03:25:34 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A2C03A68F5; Mon, 29 Sep 2008 03:25: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 618403A6819 for ; Mon, 29 Sep 2008 03:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 N-DQ8uZ4F3vB for ; Mon, 29 Sep 2008 03:25:32 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 8A5A23A67BD for ; Mon, 29 Sep 2008 03:21:58 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8TAM5SO018587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2008 13:22:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8TAM3fg009984; Mon, 29 Sep 2008 13:22:03 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18656.44106.970934.822374@fireball.kivinen.iki.fi> Date: Mon, 29 Sep 2008 13:22:02 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <18652.42879.953190.973639@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 20 min X-Total-Time: 19 min Cc: ipsec@ietf.org, Keith Welter Subject: Re: [IPsec] Comment on ikev2bis section 2.4 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Scott C Moonen writes: > Hi Tero, the problem is this: how does the initiator know when to send > INITIAL_CONTACT? How can the initiator know that this is the first SA > "between the authenticated identities" when the initiator does not yet > know IDr? This might be the case because the initiator's PAD entry has a > wildcarded remote identity, or it might be the case because the initiator > has overlapping PAD entries and allows the peer to send an IDr differing > from the initiator's optional IDr payload. In either case, the initiator > does not have enough information when it sends the IKE_AUTH request to > know conclusively that this is the first SA "between the authenticated > identities" simply because it does not know both authenticated identities. > For a mobile device bringing up its first and only IKE SA, this is not a > problem. But for a multi-homed server bringing up a dozen IKE SAs after > reboot, it is problematic. I do not think this is really a problem in any real implementations. Implementations need to know the PAD entry they are going to use when they start to create SA. If they have existing SAs with the same PAD entry, they will be using the same IKE SA to create the child SAs or in case the existing SAs is something that cannot be used because for example NO_ADDITIONAL_SAs received before, then they still know there is IKE SA already there. If they have overlapping PAD entries, then they need to give the IDi and IDr to tell the other end which of those PAD entries they are using, so other end can distingush multiple connections. If both ends have same policy then they will not return different IDr. If the policy is different in each end, then they might have situation where the initiator sends IDi, and IDr along with INITIAL_CONTACT and responder select different IDr to be used, but I would say that is configuration error, thus the policy in responder end should be fixed to fix this problem. IKEv2 tries to work at some extent even if the peers have mismatched policies, but there are cases where it cannot work if policies are different enough. I think this is one of those cases. I have never seen this kind of problem in any real world scenarios. Also the easiest fix is to simply disable INITIAL_CONTACT notifications in those cases. IKEv2 do not require INITIAL_CONTACT notifications to work correctly, they are there mostly because IKEv1 had those, and in some simple cases they might optimize the resource usage in the responder. IKEv1 was not reliable protocol, so there it was important to remove all one-way SAs with INITIAL_CONTACT because there was no other way to recover from crash. In IKEv2 the extra SAs will go away quiet quickly after the other end realizes the other end is not sending any traffic and starts DPD, and when that fails it will delete IKE SA and all IPsec SAs associated with IKE SA. Because of this the need for INITIAL_CONTACT is much less than what is was for IKEv1. > There may also be a (strained) use case for the responder's sending > INITIAL_CONTACT. If the responder uses NO_ADDITIONAL_SAs to limit one > child SA per IKE SA, the initiator may have multiple IKE SAs to the > responder. If the responder reboots and a liveness exchange causes one of > those SAs to be deleted and a new one to be negotiated, it would be > helpful to receive an INITIAL_CONTACT from the responder to allow for the > other IKE SAs to be cleaned up. I do not think we are going to see such kind of limited IKE implementations. My guess is that if implementation sends NO_ADDITIONAL_SAs it only supports exactly one IKE SA and one IPsec SA because it is some kind of connection where there can be only one connection at time. I do not really think there will be implementations which would allow multiple IKE SA from same peer, but has only very limited number of IPsec SAs inside each of those IKE SAs. Again the normal IKEv2 DPD and so on will take care of the extra SAs. Note, that if the initiator is going to use the similar mechanims for all of the SAs he has, he will most likely trigger DPD about same time for each of the SAs, and recreate them quite close to each other (also failing DPD with peer, should be considered as a hint there is something wrong with the peer, so at least that should trigger DPD for the rest of the IKE SAs). > Perhaps we should only recommend an > implementation send INITIAL_CONTACT as responder if it has this limitation > of one child SA per IKE SA. But that suggests we should allow for > receiving INITIAL_CONTACT from a responder in any case. I do not really consider that case important enough to add special handling for it. I would much rather stick with the section 7.8 of RFC4718 which restricts the INITIAL_CONTACT to be in the first IKE_AUTH request, i.e. from initiator only. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 29 04:27:12 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EE7C3A6933; Mon, 29 Sep 2008 04:27:12 -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 D3CD13A6933 for ; Mon, 29 Sep 2008 04:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 BWeD-5xHBvlm for ; Mon, 29 Sep 2008 04:27:10 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id E82993A68AB for ; Mon, 29 Sep 2008 04:27:09 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8TBQNEp015240 for ; Mon, 29 Sep 2008 07:26:23 -0400 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8TBQDkI066880 for ; Mon, 29 Sep 2008 05:26:23 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id m8TBQD5m012894 for ; Mon, 29 Sep 2008 05:26:13 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id m8TBQDEG012891; Mon, 29 Sep 2008 05:26:13 -0600 In-Reply-To: <18656.44106.970934.822374@fireball.kivinen.iki.fi> References: <18652.42879.953190.973639@fireball.kivinen.iki.fi> <18656.44106.970934.822374@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: CBA79728:A0E541CC-852574D3:003C2CDD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen Message-ID: Date: Mon, 29 Sep 2008 07:26:11 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V85_M2_08202008HFIGS1|August 20, 2008) at 09/29/2008 05:26:12, Serialize complete at 09/29/2008 05:26:12 Cc: ipsec@ietf.org, Keith Welter Subject: Re: [IPsec] Comment on ikev2bis section 2.4 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1787306564==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1787306564== Content-Type: multipart/alternative; boundary="=_alternative 003ECFA6852574D3_=" This is a multipart message in MIME format. --=_alternative 003ECFA6852574D3_= Content-Type: text/plain; charset="US-ASCII" Tero, thanks for the reply. I think that clears up most of the issues I mentioned except for the issue of a wildcarded PAD entry; e.g., allowing the remote identity to be any subdomain of your own company's domain name, within a certain scope of IP addresses. If we initiate multiple connections to different IP addresses using this PAD entry, then we cannot know whether the IDr for any new connection matches the IDr for any prior connection until after the Auth exchange is complete. I wonder whether we could 1) allow for INITIAL_CONTACT to be sent in a subsequent exchange for just this case; or 2) allow the use of IP address considerations as well as identity considerations in determining whether to send INITIAL_CONTACT, if there is any uncertainty due to identity wildcarding. It sounds like you are hinting at #2 in your note below. You mention checking whether an implementation has "existing SAs with the same PAD entry." But until the remote identity has been resolved, choosing a PAD entry is done only on the basis of IP address anyway. Distinguishing between distinct IP addresses covered by the same PAD entry would seem to be a logical extension of that. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: ipsec@ietf.org, Keith Welter/Raleigh/IBM@IBMUS Date: 09/29/2008 06:26 AM Subject: Re: [IPsec] Comment on ikev2bis section 2.4 Scott C Moonen writes: > Hi Tero, the problem is this: how does the initiator know when to send > INITIAL_CONTACT? How can the initiator know that this is the first SA > "between the authenticated identities" when the initiator does not yet > know IDr? This might be the case because the initiator's PAD entry has a > wildcarded remote identity, or it might be the case because the initiator > has overlapping PAD entries and allows the peer to send an IDr differing > from the initiator's optional IDr payload. In either case, the initiator > does not have enough information when it sends the IKE_AUTH request to > know conclusively that this is the first SA "between the authenticated > identities" simply because it does not know both authenticated identities. > For a mobile device bringing up its first and only IKE SA, this is not a > problem. But for a multi-homed server bringing up a dozen IKE SAs after > reboot, it is problematic. I do not think this is really a problem in any real implementations. Implementations need to know the PAD entry they are going to use when they start to create SA. If they have existing SAs with the same PAD entry, they will be using the same IKE SA to create the child SAs or in case the existing SAs is something that cannot be used because for example NO_ADDITIONAL_SAs received before, then they still know there is IKE SA already there. If they have overlapping PAD entries, then they need to give the IDi and IDr to tell the other end which of those PAD entries they are using, so other end can distingush multiple connections. If both ends have same policy then they will not return different IDr. If the policy is different in each end, then they might have situation where the initiator sends IDi, and IDr along with INITIAL_CONTACT and responder select different IDr to be used, but I would say that is configuration error, thus the policy in responder end should be fixed to fix this problem. IKEv2 tries to work at some extent even if the peers have mismatched policies, but there are cases where it cannot work if policies are different enough. I think this is one of those cases. I have never seen this kind of problem in any real world scenarios. Also the easiest fix is to simply disable INITIAL_CONTACT notifications in those cases. IKEv2 do not require INITIAL_CONTACT notifications to work correctly, they are there mostly because IKEv1 had those, and in some simple cases they might optimize the resource usage in the responder. IKEv1 was not reliable protocol, so there it was important to remove all one-way SAs with INITIAL_CONTACT because there was no other way to recover from crash. In IKEv2 the extra SAs will go away quiet quickly after the other end realizes the other end is not sending any traffic and starts DPD, and when that fails it will delete IKE SA and all IPsec SAs associated with IKE SA. Because of this the need for INITIAL_CONTACT is much less than what is was for IKEv1. > There may also be a (strained) use case for the responder's sending > INITIAL_CONTACT. If the responder uses NO_ADDITIONAL_SAs to limit one > child SA per IKE SA, the initiator may have multiple IKE SAs to the > responder. If the responder reboots and a liveness exchange causes one of > those SAs to be deleted and a new one to be negotiated, it would be > helpful to receive an INITIAL_CONTACT from the responder to allow for the > other IKE SAs to be cleaned up. I do not think we are going to see such kind of limited IKE implementations. My guess is that if implementation sends NO_ADDITIONAL_SAs it only supports exactly one IKE SA and one IPsec SA because it is some kind of connection where there can be only one connection at time. I do not really think there will be implementations which would allow multiple IKE SA from same peer, but has only very limited number of IPsec SAs inside each of those IKE SAs. Again the normal IKEv2 DPD and so on will take care of the extra SAs. Note, that if the initiator is going to use the similar mechanims for all of the SAs he has, he will most likely trigger DPD about same time for each of the SAs, and recreate them quite close to each other (also failing DPD with peer, should be considered as a hint there is something wrong with the peer, so at least that should trigger DPD for the rest of the IKE SAs). > Perhaps we should only recommend an > implementation send INITIAL_CONTACT as responder if it has this limitation > of one child SA per IKE SA. But that suggests we should allow for > receiving INITIAL_CONTACT from a responder in any case. I do not really consider that case important enough to add special handling for it. I would much rather stick with the section 7.8 of RFC4718 which restricts the INITIAL_CONTACT to be in the first IKE_AUTH request, i.e. from initiator only. -- kivinen@safenet-inc.com --=_alternative 003ECFA6852574D3_= Content-Type: text/html; charset="US-ASCII"
Tero, thanks for the reply.  I think that clears up most of the issues I mentioned except for the issue of a wildcarded PAD entry; e.g., allowing the remote identity to be any subdomain of your own company's domain name, within a certain scope of IP addresses.  If we initiate multiple connections to different IP addresses using this PAD entry, then we cannot know whether the IDr for any new connection matches the IDr for any prior connection until after the Auth exchange is complete.

I wonder whether we could 1) allow for INITIAL_CONTACT to be sent in a subsequent exchange for just this case; or 2) allow the use of IP address considerations as well as identity considerations in determining whether to send INITIAL_CONTACT, if there is any uncertainty due to identity wildcarding.

It sounds like you are hinting at #2 in your note below.  You mention checking whether an implementation has "existing SAs with the same PAD entry."  But until the remote identity has been resolved, choosing a PAD entry is done only on the basis of IP address anyway.  Distinguishing between distinct IP addresses covered by the same PAD entry would seem to be a logical extension of that.


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


From: Tero Kivinen <kivinen@iki.fi>
To: Scott C Moonen/Raleigh/IBM@IBMUS
Cc: ipsec@ietf.org, Keith Welter/Raleigh/IBM@IBMUS
Date: 09/29/2008 06:26 AM
Subject: Re: [IPsec] Comment on ikev2bis section 2.4




Scott C Moonen writes:
> Hi Tero, the problem is this: how does the initiator know when to send
> INITIAL_CONTACT?  How can the initiator know that this is the first SA
> "between the authenticated identities" when the initiator does not yet
> know IDr?  This might be the case because the initiator's PAD entry has a
> wildcarded remote identity, or it might be the case because the initiator
> has overlapping PAD entries and allows the peer to send an IDr differing
> from the initiator's optional IDr payload.  In either case, the initiator
> does not have enough information when it sends the IKE_AUTH request to
> know conclusively that this is the first SA "between the authenticated
> identities" simply because it does not know both authenticated identities.
>  For a mobile device bringing up its first and only IKE SA, this is not a
> problem.  But for a multi-homed server bringing up a dozen IKE SAs after
> reboot, it is problematic.

I do not think this is really a problem in any real implementations.
Implementations need to know the PAD entry they are going to use when
they start to create SA. If they have existing SAs with the same PAD
entry, they will be using the same IKE SA to create the child SAs or
in case the existing SAs is something that cannot be used because for
example NO_ADDITIONAL_SAs received before, then they still know there
is IKE SA already there.

If they have overlapping PAD entries, then they need to give the IDi
and IDr to tell the other end which of those PAD entries they are
using, so other end can distingush multiple connections. If both ends
have same policy then they will not return different IDr. If the
policy is different in each end, then they might have situation where
the initiator sends IDi, and IDr along with INITIAL_CONTACT and
responder select different IDr to be used, but I would say that is
configuration error, thus the policy in responder end should be fixed
to fix this problem.

IKEv2 tries to work at some extent even if the peers have mismatched
policies, but there are cases where it cannot work if policies are
different enough. I think this is one of those cases.

I have never seen this kind of problem in any real world scenarios.
Also the easiest fix is to simply disable INITIAL_CONTACT
notifications in those cases. IKEv2 do not require INITIAL_CONTACT
notifications to work correctly, they are there mostly because IKEv1
had those, and in some simple cases they might optimize the resource
usage in the responder.

IKEv1 was not reliable protocol, so there it was important to remove
all one-way SAs with INITIAL_CONTACT because there was no other way to
recover from crash. In IKEv2 the extra SAs will go away quiet quickly
after the other end realizes the other end is not sending any traffic
and starts DPD, and when that fails it will delete IKE SA and all
IPsec SAs associated with IKE SA.

Because of this the need for INITIAL_CONTACT is much less than what is
was for IKEv1.

> There may also be a (strained) use case for the responder's sending
> INITIAL_CONTACT.  If the responder uses NO_ADDITIONAL_SAs to limit one
> child SA per IKE SA, the initiator may have multiple IKE SAs to the
> responder.  If the responder reboots and a liveness exchange causes one of
> those SAs to be deleted and a new one to be negotiated, it would be
> helpful to receive an INITIAL_CONTACT from the responder to allow for the
> other IKE SAs to be cleaned up.

I do not think we are going to see such kind of limited IKE
implementations. My guess is that if implementation sends
NO_ADDITIONAL_SAs it only supports exactly one IKE SA and one IPsec SA
because it is some kind of connection where there can be only one
connection at time. I do not really think there will be
implementations which would allow multiple IKE SA from same peer, but
has only very limited number of IPsec SAs inside each of those IKE
SAs.

Again the normal IKEv2 DPD and so on will take care of the extra SAs.
Note, that if the initiator is going to use the similar mechanims for
all of the SAs he has, he will most likely trigger DPD about same time
for each of the SAs, and recreate them quite close to each other (also
failing DPD with peer, should be considered as a hint there is
something wrong with the peer, so at least that should trigger DPD for
the rest of the IKE SAs).

> Perhaps we should only recommend an
> implementation send INITIAL_CONTACT as responder if it has this limitation
> of one child SA per IKE SA.  But that suggests we should allow for
> receiving INITIAL_CONTACT from a responder in any case.

I do not really consider that case important enough to add special
handling for it. I would much rather stick with the section 7.8 of
RFC4718 which restricts the INITIAL_CONTACT to be in the first
IKE_AUTH request, i.e. from initiator only.
--
kivinen@safenet-inc.com

--=_alternative 003ECFA6852574D3_=-- --===============1787306564== 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 --===============1787306564==-- From ipsec-bounces@ietf.org Mon Sep 29 05:54:55 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AB933A6945; Mon, 29 Sep 2008 05:54:55 -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 9E6F43A6945 for ; Mon, 29 Sep 2008 05:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, 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 I+s6UT9EWuyV for ; Mon, 29 Sep 2008 05:54:52 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id D53BD3A67E6 for ; Mon, 29 Sep 2008 05:54:30 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id m8TCseMa015423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2008 15:54:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id m8TCscGi020389; Mon, 29 Sep 2008 15:54:38 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18656.53262.185846.856390@fireball.kivinen.iki.fi> Date: Mon, 29 Sep 2008 15:54:38 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <18652.42879.953190.973639@fireball.kivinen.iki.fi> <18656.44106.970934.822374@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 22.1.1 X-Edit-Time: 12 min X-Total-Time: 34 min Cc: ipsec@ietf.org, Keith Welter Subject: Re: [IPsec] Comment on ikev2bis section 2.4 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Scott C Moonen writes: > Tero, thanks for the reply. I think that clears up most of the issues I > mentioned except for the issue of a wildcarded PAD entry; e.g., allowing > the remote identity to be any subdomain of your own company's domain name, > within a certain scope of IP addresses. If we initiate multiple > connections to different IP addresses using this PAD entry, then we cannot > know whether the IDr for any new connection matches the IDr for any prior > connection until after the Auth exchange is complete. But if they are going to be on different IP-addresses and they do not have anything special marked on them (i.e. marked in PAD to have multiple IP-addresses), I would guess they are different entities. The IDr text is there just to make sure you do not use ONLY the IP-address to see if the peer is same. In normal case you do both IP and identity checks. > I wonder whether we could 1) allow for INITIAL_CONTACT to be sent in a > subsequent exchange for just this case; or If you are not sure, just dont send INITIAL_CONTACT at all. As I said it is not that important in IKEv2 anyways. > 2) allow the use of IP address > considerations as well as identity considerations in determining whether > to send INITIAL_CONTACT, if there is any uncertainty due to identity > wildcarding. IP-address is assumed to be taken account BEFORE taking account the ID. The RFC says "authenticated identity", this does not rule out IP-address checks. The text was changed from IP-address to authenticated identity just to allow multiple IKE SA with different identities with same IP-address. The original idea was not to assume that any IP-address can have any identity, i.e. normally the first check would be the gateway IP-address (unless the PAD entry is marked specially to replicated gateway or gateway having multiple IP-addresses). > It sounds like you are hinting at #2 in your note below. You mention > checking whether an implementation has "existing SAs with the same PAD > entry." But until the remote identity has been resolved, choosing a PAD > entry is done only on the basis of IP address anyway. Yes. Or the PAD entry is done on the bases of the triggering packet, and we do know the gateway IP-address where we are going to connected using IKE. > Distinguishing between distinct IP addresses covered by the same PAD > entry would seem to be a logical extension of that. Unless there is anything special in the PAD I would always assume that different IP-addresses are different entities, even when they might have same ID. In case you are connecting to different authentication realms you can have exactly same ID for the remote end using different CA certificates for example, and when you have triggering packet you select one of them and connect to the IP-address of the gateway. In that case you must check the peer IP also, as that tells they are different autenticated identities even when they have same ID. Perhaps the term should be "authenticated entity" instead of "authenticated identity". -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 30 05:38:48 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170203A6AD3; Tue, 30 Sep 2008 05:38:48 -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 723B33A68EA for ; Tue, 30 Sep 2008 05:38:46 -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 vgYloVfpHPU9 for ; Tue, 30 Sep 2008 05:38:41 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by core3.amsl.com (Postfix) with ESMTP id 8E2103A6AF9 for ; Tue, 30 Sep 2008 05:38:40 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id q7so535339uge.15 for ; Tue, 30 Sep 2008 05:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ovNnbtkiNx9g1oW/d3xu4kVF/pmFgrXjZVKqEUG6IX8=; b=wkgXRuVYy0ylQFLUQ3Hh9O1uzdXGIkQaR4PZX7oRzJUSmTNHHCHL5JtTehpIxRtxzY 1RC1krti34mPQxk95OtE1/PwiCsG75EHkAJpNi9/q1bb0KHjbE2LrCbn5ZdJvyxCrl2R YjZksXE1MkFCoZ4wzcOAifAnuSlj03o9ub7TY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=HXN6rDLPibb54sVPIC3pFwXx/Wcyb7mjqY3oQ552qn7SU91d4x4ZcC1vO6ZzlZIsXg 1pc3iQ/CvYuxBpXn3RvQuehBspPqj24Y7QOtfCCgBCn7enxt3Vh0G940VtlqGDpny8fP tVqT6lqeZ6ecdtsaV+KeDE6zzKSh2ZeQqQhAI= Received: by 10.103.17.10 with SMTP id u10mr4776795mui.76.1222778330957; Tue, 30 Sep 2008 05:38:50 -0700 (PDT) Received: by 10.103.176.4 with HTTP; Tue, 30 Sep 2008 05:38:50 -0700 (PDT) Message-ID: <895583cb0809300538s2cbef95cy6c064f026c0c4e7@mail.gmail.com> Date: Tue, 30 Sep 2008 14:38:50 +0200 From: "Carl Knutsson" To: "Christou, Christos [USA]" In-Reply-To: <46E7B21EF4A45749B2432ABDCDE6FEA1039FA728@MCLNEXVS12.resource.ds.bah.com> MIME-Version: 1.0 Content-Disposition: inline References: <48D6A96E.2020403@spawar.navy.mil> <37BDD2FAF2AEAE459C6C70FDC2892E4E03499E88@MCLNEXVS05.resource.ds.bah.com> <895583cb0809220349j332d9382l20707a4fbdb79bba@mail.gmail.com> <46E7B21EF4A45749B2432ABDCDE6FEA1039FA728@MCLNEXVS12.resource.ds.bah.com> Cc: ipsec@ietf.org, rohc@ietf.org, "Robert A. Stangarone Jr." , rohc-owner@ietf.org, Pasi.Eronen@nokia.com, Tero Kivinen , Kristofer Sandlund , stangarr@nkiconsulting.com Subject: Re: [IPsec] [rohc] Comments on current RoHC over IPSec draft X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: 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 Chris, Emre, On Mon, Sep 29, 2008 at 5:45 PM, Christou, Christos [USA] wrote: -----8<--------- > As you have pointed out, the overhead varies based on profiles. Although > it might not be as ideal, the overhead we would account for PMTU could > be profile dependent. In other words, there will be an entry in the SPD > for the profiles we would like to compress over particular SA's. > Therefore, depending on the profiles identified, we could account for > the maximum possible RoHC overhead in the PMTU calculation based on the > profiles listed in the SPD. > agreed > We will not include the MAX_HEADER parameter in our drafts. > agreed /Calle _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 30 12:22:10 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 335E93A6A2E; Tue, 30 Sep 2008 12: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 1270D3A6A00 for ; Tue, 30 Sep 2008 12:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, J_CHICKENPOX_46=0.6, 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 zdpeUrLItAzd for ; Tue, 30 Sep 2008 12:22:07 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id AC8193A67EF for ; Tue, 30 Sep 2008 12:22:07 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8UJMQ4s022450 for ; Tue, 30 Sep 2008 15:22:26 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8UJMOiE141046 for ; Tue, 30 Sep 2008 13:22:24 -0600 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 m8UJMN92029479 for ; Tue, 30 Sep 2008 13:22:23 -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 m8UJMJEn029393 for ; Tue, 30 Sep 2008 13:22:20 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 9C76DDB0:0D24628E-852574D4:006428F1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen Message-ID: Date: Tue, 30 Sep 2008 15:22:18 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Build V85_M2_08202008HFIGS1|August 20, 2008) at 09/30/2008 13:22:19, Serialize complete at 09/30/2008 13:22:19 Subject: [IPsec] NON_FIRST_FRAGMENTS_ALSO question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0422059877==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0422059877== Content-Type: multipart/alternative; boundary="=_alternative 006A67C0852574D4_=" This is a multipart message in MIME format. --=_alternative 006A67C0852574D4_= Content-Type: text/plain; charset="US-ASCII" RFC 4301 states the following: IPsec MUST perform the following steps when processing outbound packets: 1. . . . invoke the SPD selection function . . . . . . 3a. . . . Note that the SA PMTU value, plus the value of the stateful fragment checking flag (and the DF bit in the IP header of the outbound packet) determine whether the packet can (must) be fragmented prior to or after IPsec processing, or if it must be discarded and an ICMP PMTU message is sent. >From this text it is clear that outbound SPD lookup occurs before fragmentation. In the case of locally originated traffic, this means that if a packet is fragmented, all of these locally originated fragments will be filtered with the benefit of knowing their upper-layer selectors (ports, type, code). In other words, if there is a tunnel-mode tunnel for a specific port pair, and if the PMTU dictates fragmentation before encapsulation, these fragments will normally all be sent over that tunnel rather than split between that tunnel and a port=OPAQUE tunnel. Based on the following text from RFC 4718, this indicates to me that, even if an implementation does not generally perform stateful fragment checking on forwarded traffic, NON_FIRST_FRAGMENTS_ALSO must be sent in this case for local traffic: [RFC4301] says "Implementations that will transmit non-initial fragments on a tunnel mode SA that makes use of non-trivial port (or ICMP type/code or MH type) selectors MUST notify a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. Even though this text is from RFC 4301, I mention RFC 4718 because it has an important clarification about NON_FIRST_FRAGMENTS_ALSO being a negotiated behavior rather than a unilateral declaration. And that relates to some questions I have for IKEv2 implementors: 1) Does your implementation perform stateful fragment checking? 2) Regardless of the answer to #1, does your implementation correctly recognize that in this case there is a pseudo stateful fragment checking going on even though the traffic at your endpoint is not forwarded? 3) How do you handle this case? Do you send NON_FIRST_FRAGMENTS_ALSO? Or do you mark the SA as stateful-fragment-checking=false, perhaps discarding those non-first fragments? Or do you have additional logic to perform a second SPD lookup for these non-first fragments after they have been produced, so that they can be sent on the appropriate port=ALL or port=OPAQUE SA? 4) If you treat this as a NON_FIRST_FRAGMENTS_ALSO case, what do you do in the event that NON_FIRST_FRAGMENTS_ALSO is not also sent by the peer? Do you delete the SA and document that a port=ALL SA must be established instead (e.g., by setting the port PFP flags to false)? Or do you revert to any of the behaviors suggested in the previous question? Thanks in advance for your answers (and for any additional thoughts or opinions you have), Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen --=_alternative 006A67C0852574D4_= Content-Type: text/html; charset="US-ASCII"
RFC 4301 states the following:

   IPsec MUST perform the following steps when processing outbound packets:

   1.  . . . invoke the SPD selection function . . .
   . . .
   3a. . . . Note that the SA PMTU value, plus the value of
       the stateful fragment checking flag (and the DF bit in the IP
       header of the outbound packet) determine whether the packet can
       (must) be fragmented prior to or after IPsec processing, or if it
       must be discarded and an ICMP PMTU message is sent.

From this text it is clear that outbound SPD lookup occurs before fragmentation.  In the case of locally originated traffic, this means that if a packet is fragmented, all of these locally originated fragments will be filtered with the benefit of knowing their upper-layer selectors (ports, type, code).  In other words, if there is a tunnel-mode tunnel for a specific port pair, and if the PMTU dictates fragmentation before encapsulation, these fragments will normally all be sent over that tunnel rather than split between that tunnel and a port=OPAQUE tunnel.

Based on the following text from RFC 4718, this indicates to me that, even if an implementation does not generally perform stateful fragment checking on forwarded traffic, NON_FIRST_FRAGMENTS_ALSO must be sent in this case for local traffic:

   [RFC4301] says "Implementations that will transmit non-initial
   fragments on a tunnel mode SA that makes use of non-trivial port (or
   ICMP type/code or MH type) selectors MUST notify a peer via the IKE
   NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.

Even though this text is from RFC 4301, I mention RFC 4718 because it has an important clarification about NON_FIRST_FRAGMENTS_ALSO being a negotiated behavior rather than a unilateral declaration.  And that relates to some questions I have for IKEv2 implementors:

  1) Does your implementation perform stateful fragment checking?

  2) Regardless of the answer to #1, does your implementation correctly recognize that in this case there is a pseudo stateful fragment checking going on even though the traffic at your endpoint is not forwarded?

  3) How do you handle this case?  Do you send NON_FIRST_FRAGMENTS_ALSO?  Or do you mark the SA as stateful-fragment-checking=false, perhaps discarding those non-first fragments?  Or do you have additional logic to perform a second SPD lookup for these non-first fragments after they have been produced, so that they can be sent on the appropriate port=ALL or port=OPAQUE SA?

  4) If you treat this as a NON_FIRST_FRAGMENTS_ALSO case, what do you do in the event that NON_FIRST_FRAGMENTS_ALSO is not also sent by the peer?  Do you delete the SA and document that a port=ALL SA must be established instead (e.g., by setting the port PFP flags to false)?  Or do you revert to any of the behaviors suggested in the previous question?

Thanks in advance for your answers (and for any additional thoughts or opinions you have),


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen --=_alternative 006A67C0852574D4_=-- --===============0422059877== 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 --===============0422059877==--