From ipsec-bounces@ietf.org Fri May 2 04:01:36 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A50893A687F; Fri, 2 May 2008 04:01:36 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 905823A687F for ; Fri, 2 May 2008 04:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 H27ecLT2Rp+P for ; Fri, 2 May 2008 04:01:34 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id A773E3A6934 for ; Fri, 2 May 2008 04:01:34 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so901373and.122 for ; Fri, 02 May 2008 04:01:36 -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:mime-version:content-type; bh=zRl+KOok7IfDjE/Aoc1XGMY0iuRadpfMXhTGxSvHp3E=; b=SkHq0r1+HWtdweYLS9rCveUA1FgUEyVbOJXXidNDNbiPmbhLufj8eE829/IZ4Z1rdi1zzgGIBBxf24Hy0ESppUb1nHA3MOJfskz7Qn8LDCsdqQkml9ytrtBZcZjsHEhe4Umt0xZWE5ZZME1nnA50jfYN5yJQVj33TggidGpmWVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=VwDpGJOTRKo5+Fey/X780+nv01P05HYS1oM7bjZPlc7vG6C+4cZPa6fz0fTBAz74xIK7PpJtNjqpBTtL1e2OUAzfoxA7Tja3tS45la5nCbthVBxLPRa8zAPRUZvM1O1qFuNo0eYENAcvoQpVYaF/ZZmeVLSKDhoXBwBD/+EINfE= Received: by 10.100.105.15 with SMTP id d15mr4355616anc.149.1209726096165; Fri, 02 May 2008 04:01:36 -0700 (PDT) Received: by 10.100.110.7 with HTTP; Fri, 2 May 2008 04:01:36 -0700 (PDT) Message-ID: Date: Fri, 2 May 2008 16:31:36 +0530 From: "rajeev mehta" To: ipsec@ietf.org MIME-Version: 1.0 Subject: [IPsec] ipsec behaving strangely X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1665539151==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1665539151== Content-Type: multipart/alternative; boundary="----=_Part_10398_7433149.1209726096159" ------=_Part_10398_7433149.1209726096159 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I have configured ipsec between two machines which have multiple ip addresses configured. Machine 1 has following configuration : eth0 --- 10.118.231.131 eth0:1 --- 10.118.231.130 Machine 2 has following configuration : eth0 --- 10.118.231.143 Now, I want to configure ipsec between 10.118.231.130 & 10.118.231.143. When I do so. I can see from tcpdump isakmp messages being sent out from 10.118.231.131 ip address rather than 10.118.231.130. And isakmp messages being received from 10.118.231.143 on 10.118.231.130. I am unable to understand this anamoly. Pls help. In my view, isakmp messages should be exchanged only between 10.118.231.130& 10.118.231.143. Best Regards, Rajeev Mehta ------=_Part_10398_7433149.1209726096159 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
I have configured ipsec between two machines which have multiple ip addresses configured.
Machine 1 has following configuration :
eth0:1 --- 10.118.231.130
Machine 2 has following configuration :
 
Now, I want to configure ipsec between 10.118.231.130 & 10.118.231.143.
When I do so. I can see from tcpdump isakmp messages being sent out from 10.118.231.131 ip address rather than 10.118.231.130.
And isakmp messages being received from 10.118.231.143 on 10.118.231.130.
I am unable to understand this anamoly. Pls help.
In my view, isakmp messages should be exchanged only between 10.118.231.130 & 10.118.231.143.
 
Best Regards,
Rajeev Mehta
 
------=_Part_10398_7433149.1209726096159-- --===============1665539151== 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 --===============1665539151==-- From ipsec-bounces@ietf.org Wed May 7 03:20:41 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 487373A70F4; Wed, 7 May 2008 03:20: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 867DC3A6A52 for ; Wed, 7 May 2008 03:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.571 X-Spam-Level: X-Spam-Status: No, score=-6.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 L6OpYet24pS9 for ; Wed, 7 May 2008 03:20:35 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 85C4528C5DB for ; Wed, 7 May 2008 03:20:13 -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 m47AJULk028714 for ; Wed, 7 May 2008 05:20:07 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 13:19:10 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 13:19:10 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 May 2008 13:19:09 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPsec maintenance/extensions WG, summary so far Thread-index: AciwK8m/mwKUTwCXTrqgl2KHAdRjBw== From: To: X-OriginalArrivalTime: 07 May 2008 10:19:10.0363 (UTC) FILETIME=[CA4486B0:01C8B02B] X-Nokia-AV: Clean Subject: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org So far, we've had ~20 people who've expressed some form of support for creating a WG. This is good -- many current WGs have less than 20 people who regularly post to the WG mailing list. However, by my count, we've also had ~20 proposals for work items. That obviously does not add up. I agree with Paul's comment about the WG scope: the WG should work on things where having a WG is really needed, and we actually have a *group* of people interested on participating. Having a WG should not encourage people to develop extensions that would not have happened in the absence of a WG (this usually indicates they're not widely needed). For some work items that have been proposed, an individual draft is IMHO a more appropriate process mechanism, and forming a WG would not automatically prevent publication of non-WG documents the WG decided not to take. To get some idea on what work items we have most interest in, I've collected those proposed so far (with some things vendors are known to do in proprietary ways thrown in). Please select the items you think the WG should work on (less than ten, please), order them most important first, and for each item, indicate what you're willing to do: [E]dit: you're willing to edit the draft corresponding to the work item (note: even if we use an individual draft as a starting point, this does not automatically determine the editor of the WG item) [C]ontribute: you're willing to propose non-trivial amounts of text for the document during its development [R]eview: you're willing to review new revisions of the draft regularly (not just during WGLC) For example, [CR] AEAD algorithms in IKEv2 [R] IPsec document roadmap update would mean that AEAD algorithms is your first priority, and you volunteer to contribute and review; and IPsec document roadmap is your second priority, and you volunteer to review. You can also propose a work item that isn't on my list. However, for the time being, I think PF_KEY work does not fit within the scope of the possible WG charter. List follows: o Update to IKEv2 base specification (possible starting point: draft-hoffman-ikev2bis) o IPsec document roadmap update (possible starting point: RFC 2411) o Using AEAD algorithms in IKEv2 (possible starting point: draft-black-ipsec-ikev2-aead-modes) o Redirecting a VPN client from one gateway to another (in a cluster of gateways) o IPsec "secure beacon", or detecting whether you need VPN or not (possible starting point: draft-sheffer-ipsec-secure-beacon) o Detecting crashed peers faster (possible starting point: draft-nir-ike-qcd) o IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) o Authentication-only IPsec that simplifies packet inspection (possible starting points: draft-hoffman-esp-null-protocol, draft-grewal-ipsec-traffic-visibility) o Better IPv6 configuration payloads (possible starting point: draft-eronen-ipsec-ikev2-ipv6-config) o Other work for making sure IKEv1 and IKEv2 work as well as possible with IPv6, both from standards and operations standpoint (please specify more details if you select this one) o Running IPsec over TCP (so your VPN works even if the coffee shop Wi-Fi has stupid packet filtering) o GSS-API (or Kerberos) authentication for IKEv2 o Non-EAP-based one-time password authentication (possible starting point: draft-sunabhi-otp-ikev2) o Using GRE "key" header field as IPsec traffic selector (possible starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) o Authentication with Cryptographically Generated Addresses (CGA) (possible starting point: draft-laganier-ike-ipv6-cga) o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec (possible starting point: draft-bellovin-useipsec) o Labeled IPsec for RFC 430x IPsec o IKEv1/IKEv2 co-existence and transition (please specify more details if you select this one) o Setting up GRE tunnels with IKE (possible starting point: draft-wu-l3vpn-ipsec-gre-00) o Connecting IKEv2 peers behind NATs via a "mediation server" (possible starting point: draft-brunner-ikev2-mediation) o Anything that may be needed from IKE/IPsec with respect to routing protocol security (please specify more details if you select this one) o Documenting differences in IPsec usage in IETF vs. 3GPP vs. 3GPP2 vs. WiMAX vs. vendors etc. (please specify more details if you select this one) o IKEv2 CAPTCHA (possible starting point: draft-mutaf-spikev2-01.txt) Please reply (on the mailing list) within a week or so -- I will then summarize what we have. Best regards, Pasi --- P.S. It's good to note that we currently have several other WGs working on IPsec: o BMWG: benchmarking IPsec devices o BTNS: unauthenticated or leap-of-faith IPsec, channel bindings, IPsec APIs for applications (not key management daemons like PF_KEY) o MEXT: interaction between IPsec and Mobile IP, Mobile IP specific extensions to IPsec o MSEC: multicast IPsec o ROHC: header compression in IPsec tunnel mode SAs o SOFTWIRE: IPsec tunnels as a softwire, setting those up based on BGP etc. These WGs will continue as-is, and e.g. any changes to their charters are not in the scope of this discussion. Future work items could be considered case-by-case, but the intent is *not* to collect all IPsec-related work to one WG. --- P.P.S. Acknowledgement: if you followed how Julien Laganier and Marcelo Bagnulo handled the MEXT WG rechartering recently, you'll notice I have stolen some ideas from them :-) _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 7 04:33:59 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7BF28C5BA; Wed, 7 May 2008 04:33: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 22F2D28C5DE for ; Wed, 7 May 2008 04:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 oKgJxkhoFnst for ; Wed, 7 May 2008 04:33:51 -0700 (PDT) Received: from moog.chdir.org (unknown [IPv6:2002:58bf:2aa0:339b:f654:e10e:317f:e6fa]) by core3.amsl.com (Postfix) with ESMTP id 6B3E43A7145 for ; Wed, 7 May 2008 04:33:47 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Jthtu-0005Cl-CY; Wed, 07 May 2008 13:33:34 +0200 X-Hashcash: 1:20:080507:jari.arkko@piuha.net::XN+xRDiB0Z0NiR7i:000000000000000000000000000000000000000001Y/A From: arno@natisbad.org (Arnaud Ebalard) To: References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080507:ipsec@ietf.org::I9R2QI8OhYfjpV+S:000162Z X-Hashcash: 1:20:080507:pasi.eronen@nokia.com::9UoulB6uz2TTnIHH:00000000000000000000000000000000000000005agt Date: Wed, 07 May 2008 13:33:30 +0200 In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> (Pasi Eronen's message of "Wed, 7 May 2008 13:19:09 +0300") Message-ID: <873aouxsad.fsf@natisbad.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, writes: > P.S. It's good to note that we currently have several other WGs > working on IPsec: > > > > o MEXT: interaction between IPsec and Mobile IP, Mobile IP > specific extensions to IPsec > > > > These WGs will continue as-is, and e.g. any changes to their charters > are not in the scope of this discussion. Future work items could be > considered case-by-case, but the intent is *not* to collect all > IPsec-related work to one WG. Sorry for joigning the discussion a little bit late. I should have posted to make a proposal for some work on MIPv6/IPsec/IKE interactions as WG items before. The IPsec-related elements you cite in your P.S. for MEXT were *not* taken as Working Group items during the recent recharter (decision of the chairs) even if there were people interested by working on it. Some other functionalities have been preferred. At the moment, even if MIPv6 specification expects interactions between IPsec stack and MIPv6 module for IPSec to survive movement, no interface is defined. The 2 proposals I am aware of on that topic: - draft-sugimoto-mip6-pfkey-migrate-04 - draft-qi-mip6-ikev2-interfacing-01 are still now simple external documents. IMO, the main issue here is that the topic crosses different WG or is related to different subjects (IPsec, MIPv6, IKE, PF_KEY). As you wrote for the IPsec WG "the intent is *not* to collect all IPsec-related work to one WG". What is happening in practice is that IPsec and MIPv6 will be *separately* added new features (probably useful in a sense) but will not or badly work together. Where should associated efforts and discussions be handled? Thanks, a+ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 7 05:20:34 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337EE3A7148; Wed, 7 May 2008 05:20: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 19C333A7148 for ; Wed, 7 May 2008 05:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.396, 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 oMcDMeW2KVT0 for ; Wed, 7 May 2008 05:20:31 -0700 (PDT) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 33FFF3A69D5 for ; Wed, 7 May 2008 05:20:31 -0700 (PDT) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 73B69198803; Wed, 7 May 2008 15:20:27 +0300 (EEST) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 390A0198713; Wed, 7 May 2008 15:20:23 +0300 (EEST) Message-ID: <48219E8D.7090001@piuha.net> Date: Wed, 07 May 2008 14:20:29 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi, The ones that I actually personally care about: > [R] o Update to IKEv2 base specification (possible starting point: > draft-hoffman-ikev2bis) > > [CR] o Better IPv6 configuration payloads (possible starting point: > draft-eronen-ipsec-ikev2-ipv6-config) > > [R] o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec > (possible starting point: draft-bellovin-useipsec) > The following were also mildly interesting, I wouldn't mind if the WG did them: > o IPsec document roadmap update (possible starting point: RFC 2411) > > o Using AEAD algorithms in IKEv2 (possible starting point: > draft-black-ipsec-ikev2-aead-modes) > > o Redirecting a VPN client from one gateway to another > (in a cluster of gateways) > > o IPsec "secure beacon", or detecting whether you need VPN or > not (possible starting point: draft-sheffer-ipsec-secure-beacon) > > o Detecting crashed peers faster (possible starting point: > draft-nir-ike-qcd) > > o IKEv2 session resumption / optimizing IKEv2 handshake when > connecting again to same peer/cluster of peers (possible > starting point: draft-sheffer-ipsec-failover) > > o Authentication-only IPsec that simplifies packet inspection > (possible starting points: draft-hoffman-esp-null-protocol, > draft-grewal-ipsec-traffic-visibility) > > o Using GRE "key" header field as IPsec traffic selector (possible > starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) > > o Authentication with Cryptographically Generated Addresses (CGA) > (possible starting point: draft-laganier-ike-ipv6-cga) > > o Setting up GRE tunnels with IKE (possible starting point: > draft-wu-l3vpn-ipsec-gre-00) > Then again, much of the above is extensions, rather than fixing bugs & revising brokenness. The latter should have priority. Is IKEv2 the only thing that has issues in that regard? Jari _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 7 06:05:16 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D91B3A7174; Wed, 7 May 2008 06:05: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 DAF7428C64A for ; Wed, 7 May 2008 06:04: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=[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 Aw0E2f1zIPcl for ; Wed, 7 May 2008 06:03:26 -0700 (PDT) Received: from labs3.cc.fer.hr (labs3.cc.fer.hr [161.53.72.21]) by core3.amsl.com (Postfix) with ESMTP id AE87528C653 for ; Wed, 7 May 2008 06:02:30 -0700 (PDT) Received: from sluga.fer.hr (sluga.cc.fer.hr [161.53.72.14]) by labs3.cc.fer.hr (8.13.8+Sun/8.12.10) with ESMTP id m47D2PSG002308 for ; Wed, 7 May 2008 15:02:26 +0200 (CEST) Received: from [161.53.19.28] ([161.53.19.28]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 May 2008 15:02:25 +0200 Message-ID: <4821A860.5050700@fer.hr> Date: Wed, 07 May 2008 15:02:24 +0200 From: Ana Kukec Organization: University of Zagreb, Faculty of Electrical Engineering and Computing User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Stephen Kent References: <6572A948732BCA4691C089730717118A07A0B7@sluga.fer.hr> In-Reply-To: X-OriginalArrivalTime: 07 May 2008 13:02:25.0890 (UTC) FILETIME=[98DB5420:01C8B042] Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Steve, Sorry for the delay with replay. We agree that LoF is useful mechanism in IKEv2 context and could be supported in different manners, as you pointed out. The advantage of CGA over others is easy deployment, since CGAs require minimal overhead to existing IKEv2 implementations. With certificates (even self-signed), IKEv2 payloads and verification mechanisms, as well as initial pre-arrangements and configuration are more complicated. We also agree that CGAs or bare public keys are not the only way to avoid centralized trust architecture. But, since CGAs are widely accepted and deployed in IPv6, from the deployment point of view and from the user point of view, it is more appropriate to use CGAs than bare public keys or self signed certificates (traditional CERT/CERTREQ fields). Regarding the PAD complexity, IMHO, a new PAD column (for CGA support) is minimal overhead to PAD. After all, PAD needs some extensions in any event. AFAIU, it is designed to be extensible. And regarding the secure initial authentication and SPD constraints, i agree, we don't need new column to support CGA constraints, since we can use SPD constraints in both cases. Ana Stephen Kent wrote: > > OK, I'm happy to hear you agree that, by itself, CGA would also just > be an LoF mechanism like BTNS. > > First, I want to observe that If one had the ability to store a public > key in the PAD for authorization, then one can also store a cert. The > cert can be a self-signed CA cert, under which the EE cert for the > peer is issued. So the argument that one needs to use bare keys to > avoid a centralized infrastructure is simply not true, even if it is > often cited :-). RFC 4301 has a requirement that the PAD support X.509 > certs and pre-shared secrets, but not for bare public keys. In part > this is because mandating support for bare public keys would be > redundant given the above analysis, and thus would only add to the > complexity of the PAD. > > Second, once you have a PAD entry, you can use either an address or a > name as the basis for SPD entry constraints. If you use name-based > constraints, then no new mechanisms are needed when CGAs are employed, > and the CGA can even change over time (as originally envisioned) > without needing to change the PAD or SPD entries. > > If the CGA remains constant, then it becomes equivalent to a > traditional IP (v6) address re access control, and the PAD could be > configured with that address as a trivial address range for traffic > selectors, and one can use the address in SPD entries. So I'm not sure > why one needs new IKE payloads and new PAD entry values to accommodate > CGAs. > > Steve > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 7 11:14:36 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C5323A68D8; Wed, 7 May 2008 11:14:36 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F9528C6FE for ; Wed, 7 May 2008 11:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.665 X-Spam-Level: X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=1.600, 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 1ESDlD-087Ti for ; Wed, 7 May 2008 11:14:26 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 3E4FE28C6FF for ; Wed, 7 May 2008 11:14:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id DC94D10224076; Wed, 7 May 2008 11:14:00 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 7 May 2008 11:14:01 -0700 (PDT) Message-ID: In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Date: Wed, 7 May 2008 11:14:01 -0700 (PDT) From: "Dan Harkins" To: Pasi.Eronen@nokia.com User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Pasi, [CR] IKE session resumption [ECR] AEAD modes for IKE (and a better one than 4309 for IPsec) [ECR] non-EAP-based password authentication for IKEv2 [R] VPN client redirection regards, Dan. On Wed, May 7, 2008 3:19 am, Pasi.Eronen@nokia.com wrote: > So far, we've had ~20 people who've expressed some form of support > for creating a WG. This is good -- many current WGs have less than 20 > people who regularly post to the WG mailing list. > > However, by my count, we've also had ~20 proposals for work items. > That obviously does not add up. > > I agree with Paul's comment about the WG scope: the WG should work > on things where having a WG is really needed, and we actually have a > *group* of people interested on participating. > > Having a WG should not encourage people to develop extensions that > would not have happened in the absence of a WG (this usually indicates > they're not widely needed). For some work items that have been > proposed, an individual draft is IMHO a more appropriate process > mechanism, and forming a WG would not automatically prevent > publication of non-WG documents the WG decided not to take. > > To get some idea on what work items we have most interest in, I've > collected those proposed so far (with some things vendors are known to > do in proprietary ways thrown in). > > Please select the items you think the WG should work on (less than > ten, please), order them most important first, and for each item, > indicate what you're willing to do: > > [E]dit: you're willing to edit the draft corresponding to the work > item (note: even if we use an individual draft as a starting point, > this does not automatically determine the editor of the WG item) > > [C]ontribute: you're willing to propose non-trivial amounts of > text for the document during its development > > [R]eview: you're willing to review new revisions of the draft > regularly (not just during WGLC) > > For example, > > [CR] AEAD algorithms in IKEv2 > [R] IPsec document roadmap update > > would mean that AEAD algorithms is your first priority, and you > volunteer to contribute and review; and IPsec document roadmap is > your second priority, and you volunteer to review. > > You can also propose a work item that isn't on my list. > However, for the time being, I think PF_KEY work does not fit > within the scope of the possible WG charter. > > List follows: > > o Update to IKEv2 base specification (possible starting point: > draft-hoffman-ikev2bis) > > o IPsec document roadmap update (possible starting point: RFC 2411) > > o Using AEAD algorithms in IKEv2 (possible starting point: > draft-black-ipsec-ikev2-aead-modes) > > o Redirecting a VPN client from one gateway to another > (in a cluster of gateways) > > o IPsec "secure beacon", or detecting whether you need VPN or > not (possible starting point: draft-sheffer-ipsec-secure-beacon) > > o Detecting crashed peers faster (possible starting point: > draft-nir-ike-qcd) > > o IKEv2 session resumption / optimizing IKEv2 handshake when > connecting again to same peer/cluster of peers (possible > starting point: draft-sheffer-ipsec-failover) > > o Authentication-only IPsec that simplifies packet inspection > (possible starting points: draft-hoffman-esp-null-protocol, > draft-grewal-ipsec-traffic-visibility) > > o Better IPv6 configuration payloads (possible starting point: > draft-eronen-ipsec-ikev2-ipv6-config) > > o Other work for making sure IKEv1 and IKEv2 work as well as > possible with IPv6, both from standards and operations standpoint > (please specify more details if you select this one) > > o Running IPsec over TCP (so your VPN works even if the coffee > shop Wi-Fi has stupid packet filtering) > > o GSS-API (or Kerberos) authentication for IKEv2 > > o Non-EAP-based one-time password authentication (possible > starting point: draft-sunabhi-otp-ikev2) > > o Using GRE "key" header field as IPsec traffic selector (possible > starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) > > o Authentication with Cryptographically Generated Addresses (CGA) > (possible starting point: draft-laganier-ike-ipv6-cga) > > o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec > (possible starting point: draft-bellovin-useipsec) > > o Labeled IPsec for RFC 430x IPsec > > o IKEv1/IKEv2 co-existence and transition (please specify more > details if you select this one) > > o Setting up GRE tunnels with IKE (possible starting point: > draft-wu-l3vpn-ipsec-gre-00) > > o Connecting IKEv2 peers behind NATs via a "mediation server" > (possible starting point: draft-brunner-ikev2-mediation) > > o Anything that may be needed from IKE/IPsec with respect to > routing protocol security (please specify more details if > you select this one) > > o Documenting differences in IPsec usage in IETF vs. 3GPP vs. > 3GPP2 vs. WiMAX vs. vendors etc. (please specify more details > if you select this one) > > o IKEv2 CAPTCHA > (possible starting point: draft-mutaf-spikev2-01.txt) > > Please reply (on the mailing list) within a week or so -- I will > then summarize what we have. > > Best regards, > Pasi > > --- > > P.S. It's good to note that we currently have several other WGs > working on IPsec: > > o BMWG: benchmarking IPsec devices > > o BTNS: unauthenticated or leap-of-faith IPsec, channel bindings, > IPsec APIs for applications (not key management daemons like > PF_KEY) > > o MEXT: interaction between IPsec and Mobile IP, Mobile IP > specific extensions to IPsec > > o MSEC: multicast IPsec > > o ROHC: header compression in IPsec tunnel mode SAs > > o SOFTWIRE: IPsec tunnels as a softwire, setting those up > based on BGP etc. > > These WGs will continue as-is, and e.g. any changes to their charters > are not in the scope of this discussion. Future work items could be > considered case-by-case, but the intent is *not* to collect all > IPsec-related work to one WG. > > --- > > P.P.S. Acknowledgement: if you followed how Julien Laganier and > Marcelo Bagnulo handled the MEXT WG rechartering recently, you'll > notice I have stolen some ideas from them :-) > _______________________________________________ > 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 May 7 11:16:06 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC0D28C6DA; Wed, 7 May 2008 11:16: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 29F0228C6DA for ; Wed, 7 May 2008 11:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.699 X-Spam-Level: X-Spam-Status: No, score=-100.699 tagged_above=-999 required=5 tests=[AWL=1.900, 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 2n-jnHSy-wzm for ; Wed, 7 May 2008 11:15:59 -0700 (PDT) Received: from mail.exchange.microsoft.com (mail1.exchange.microsoft.com [131.107.1.17]) by core3.amsl.com (Postfix) with ESMTP id 9609D28C6C9 for ; Wed, 7 May 2008 11:15:59 -0700 (PDT) Received: from df-bhd-01.exchange.corp.microsoft.com (157.54.111.57) by DF-GWY-05.exchange.corp.microsoft.com (157.54.87.87) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 7 May 2008 11:16:40 -0700 Received: from DF-GRTDANE-MSG.exchange.corp.microsoft.com ([157.54.62.10]) by df-bhd-01.exchange.corp.microsoft.com ([157.54.111.57]) with mapi; Wed, 7 May 2008 11:16:40 -0700 From: Charlie Kaufman To: "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" Date: Wed, 7 May 2008 11:15:51 -0700 Thread-Topic: IPsec maintenance/extensions WG, summary so far Thread-Index: AciwK8m/mwKUTwCXTrqgl2KHAdRjBwAQHWWQ Message-ID: <30C65F3A3407B943826897E025135BE60120266A89D8@DF-GRTDANE-MSG.exchange.corp.microsoft.com> References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com said: >So far, we've had ~20 people who've expressed some form of support >for creating a WG. This is good -- many current WGs have less than 20 >people who regularly post to the WG mailing list. > >However, by my count, we've also had ~20 proposals for work items. >That obviously does not add up. > >I agree with Paul's comment about the WG scope: the WG should work >on things where having a WG is really needed, and we actually have a >*group* of people interested on participating. > >Having a WG should not encourage people to develop extensions that >would not have happened in the absence of a WG (this usually indicates >they're not widely needed). For some work items that have been >proposed, an individual draft is IMHO a more appropriate process >mechanism, and forming a WG would not automatically prevent >publication of non-WG documents the WG decided not to take. While I agree that there are cases where individual drafts are a more appropriate process mechanism, there are a lot of cases where we could use an IPsec WG to focus review and collection of comments. Small but important changes (like specifying use of a new cryptographic algorithm with ESP or IKE) might not have the energy behind them to motivate forming a WG but would nonetheless be more appropriately done as an additional work item in an existing WG than as an individual submission. While a tightly scoped charter is always a good idea, I don't think we should send the message that "this is the last train for five years... if you think you're going to want anything in IPsec ever, lobby to get it into the charter now or forever hold your peace." We should start with the highest priority non-controversial and mostly completed items with the expectations that there will be time at meetings to present proposals for less-well-known extensions and have a decision made then as to whether to accept them as working group items, suggest they be the basis of a new working group, suggest they be individual submissions, or suggest they go away. --Charlie So far, we've had ~20 people who've expressed some form of support for creating a WG. This is good -- many current WGs have less than 20 people who regularly post to the WG mailing list. However, by my count, we've also had ~20 proposals for work items. That obviously does not add up. I agree with Paul's comment about the WG scope: the WG should work on things where having a WG is really needed, and we actually have a *group* of people interested on participating. Having a WG should not encourage people to develop extensions that would not have happened in the absence of a WG (this usually indicates they're not widely needed). For some work items that have been proposed, an individual draft is IMHO a more appropriate process mechanism, and forming a WG would not automatically prevent publication of non-WG documents the WG decided not to take. [charliek:] _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 7 11:30:37 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E9243A6E86; Wed, 7 May 2008 11:30: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 B067B3A6E86 for ; Wed, 7 May 2008 11:30:35 -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 VRXcIndA2l7Z for ; Wed, 7 May 2008 11:30:34 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 5BD3C3A6DBA for ; Wed, 7 May 2008 11:30:34 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so381615wfd.31 for ; Wed, 07 May 2008 11:30:32 -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=BMXnkwtPyfwiR9qp6ySFIasaDojc+dtrutbfWfrgTWA=; b=fePwX4RCt6S+w7zMx7d/PmB/J/TY0ktfd4kaqLKknf87IhgS7h0n7Uu1Os1TUt0QO6EVuRXcx1gnsmZh/PE214GwySyYIuAuFzX4N+8WU+SqJ9qEQc6pmW3v1InT6WBc9BzK285+OgWHtAV16C/8810Z69pO5fQpoAHLU01BsgI= 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=kbC+i8d9ybtc+1Y32H50GdhzR42h8ACt9TMLzb7JUzPaAhb7MYZXJHgDrKlUQw8525UhLe5+FpPzz0FZmbzqdRYPksbrdFA0XIQdo7i1cSA2ECjPKURRaEA2qPBOLSGiZyHtldNQa6EhHhqRuSkpJhYDLI2kKY+oVtuMV7hq/h4= Received: by 10.142.58.14 with SMTP id g14mr985906wfa.313.1210185031967; Wed, 07 May 2008 11:30:31 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Wed, 7 May 2008 11:30:31 -0700 (PDT) Message-ID: Date: Wed, 7 May 2008 11:30:31 -0700 From: "Vijay Devarapallli" To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Pasi, I have one more. Sorry for not posting this earlier. There was a proposal coming out of the former MIP6 WG to use IKEv2 to re-direct a mobile node to another home agent. The Binding Update/Binding Acknowledgement exchange between the mobile node and the home agent is always preceded by an IKEv2 exchange for mutual authentication, home address configuration and setting up the required security associations for protecting Mobile IPv6 signaling messages. It was felt that it would be desirable for the home agent to tell the mobile node to go another home agent before the IKEv2 exchange completes. Otherwise the mobile node would have do the IKEv2 exchange with the new home agent all over. This proposal for re-directing the mobile node to another home agent during the IKE_SA_INIT exchange was in a ex-MIP6 WG document. There were some issues raised during the IESG review for the IKEv2 re-direct mechanism. So the mechanism was taken out and the rest of the document was published as RFC 5026. One of the concerns expressed was that it could be generic extension to IKEv2 rather than being something specific to Mobile IPv6. So I would like to propose to add another work item to the new IPsec WG charter to work on a IKEv2 re-direct mechanism during the IKE_SA_INIT exchange. Much of the details have already been worked out (by the ex-MIP6 WG and then some discussions offline), it is just a matter of writing up a draft. I am in the process of writing up this draft. This is coming a bit late. I hope it can be included in the IPsec re-chartering process. Regards, Vijay On Wed, May 7, 2008 at 3:19 AM, wrote: > So far, we've had ~20 people who've expressed some form of support > for creating a WG. This is good -- many current WGs have less than 20 > people who regularly post to the WG mailing list. > > However, by my count, we've also had ~20 proposals for work items. > That obviously does not add up. > > I agree with Paul's comment about the WG scope: the WG should work > on things where having a WG is really needed, and we actually have a > *group* of people interested on participating. > > Having a WG should not encourage people to develop extensions that > would not have happened in the absence of a WG (this usually indicates > they're not widely needed). For some work items that have been > proposed, an individual draft is IMHO a more appropriate process > mechanism, and forming a WG would not automatically prevent > publication of non-WG documents the WG decided not to take. > > To get some idea on what work items we have most interest in, I've > collected those proposed so far (with some things vendors are known to > do in proprietary ways thrown in). > > Please select the items you think the WG should work on (less than > ten, please), order them most important first, and for each item, > indicate what you're willing to do: > > [E]dit: you're willing to edit the draft corresponding to the work > item (note: even if we use an individual draft as a starting point, > this does not automatically determine the editor of the WG item) > > [C]ontribute: you're willing to propose non-trivial amounts of > text for the document during its development > > [R]eview: you're willing to review new revisions of the draft > regularly (not just during WGLC) > > For example, > > [CR] AEAD algorithms in IKEv2 > [R] IPsec document roadmap update > > would mean that AEAD algorithms is your first priority, and you > volunteer to contribute and review; and IPsec document roadmap is > your second priority, and you volunteer to review. > > You can also propose a work item that isn't on my list. > However, for the time being, I think PF_KEY work does not fit > within the scope of the possible WG charter. > > List follows: > > o Update to IKEv2 base specification (possible starting point: > draft-hoffman-ikev2bis) > > o IPsec document roadmap update (possible starting point: RFC 2411) > > o Using AEAD algorithms in IKEv2 (possible starting point: > draft-black-ipsec-ikev2-aead-modes) > > o Redirecting a VPN client from one gateway to another > (in a cluster of gateways) > > o IPsec "secure beacon", or detecting whether you need VPN or > not (possible starting point: draft-sheffer-ipsec-secure-beacon) > > o Detecting crashed peers faster (possible starting point: > draft-nir-ike-qcd) > > o IKEv2 session resumption / optimizing IKEv2 handshake when > connecting again to same peer/cluster of peers (possible > starting point: draft-sheffer-ipsec-failover) > > o Authentication-only IPsec that simplifies packet inspection > (possible starting points: draft-hoffman-esp-null-protocol, > draft-grewal-ipsec-traffic-visibility) > > o Better IPv6 configuration payloads (possible starting point: > draft-eronen-ipsec-ikev2-ipv6-config) > > o Other work for making sure IKEv1 and IKEv2 work as well as > possible with IPv6, both from standards and operations standpoint > (please specify more details if you select this one) > > o Running IPsec over TCP (so your VPN works even if the coffee > shop Wi-Fi has stupid packet filtering) > > o GSS-API (or Kerberos) authentication for IKEv2 > > o Non-EAP-based one-time password authentication (possible > starting point: draft-sunabhi-otp-ikev2) > > o Using GRE "key" header field as IPsec traffic selector (possible > starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) > > o Authentication with Cryptographically Generated Addresses (CGA) > (possible starting point: draft-laganier-ike-ipv6-cga) > > o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec > (possible starting point: draft-bellovin-useipsec) > > o Labeled IPsec for RFC 430x IPsec > > o IKEv1/IKEv2 co-existence and transition (please specify more > details if you select this one) > > o Setting up GRE tunnels with IKE (possible starting point: > draft-wu-l3vpn-ipsec-gre-00) > > o Connecting IKEv2 peers behind NATs via a "mediation server" > (possible starting point: draft-brunner-ikev2-mediation) > > o Anything that may be needed from IKE/IPsec with respect to > routing protocol security (please specify more details if > you select this one) > > o Documenting differences in IPsec usage in IETF vs. 3GPP vs. > 3GPP2 vs. WiMAX vs. vendors etc. (please specify more details > if you select this one) > > o IKEv2 CAPTCHA > (possible starting point: draft-mutaf-spikev2-01.txt) > > Please reply (on the mailing list) within a week or so -- I will > then summarize what we have. > > Best regards, > Pasi > > --- > > P.S. It's good to note that we currently have several other WGs > working on IPsec: > > o BMWG: benchmarking IPsec devices > > o BTNS: unauthenticated or leap-of-faith IPsec, channel bindings, > IPsec APIs for applications (not key management daemons like > PF_KEY) > > o MEXT: interaction between IPsec and Mobile IP, Mobile IP > specific extensions to IPsec > > o MSEC: multicast IPsec > > o ROHC: header compression in IPsec tunnel mode SAs > > o SOFTWIRE: IPsec tunnels as a softwire, setting those up > based on BGP etc. > > These WGs will continue as-is, and e.g. any changes to their charters > are not in the scope of this discussion. Future work items could be > considered case-by-case, but the intent is *not* to collect all > IPsec-related work to one WG. > > --- > > P.P.S. Acknowledgement: if you followed how Julien Laganier and > Marcelo Bagnulo handled the MEXT WG rechartering recently, you'll > notice I have stolen some ideas from them :-) > _______________________________________________ > 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 May 7 11:33:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2920128C635; Wed, 7 May 2008 11:33: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 79A1728C10C for ; Wed, 7 May 2008 11:33: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=[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 XMjuMG38ZasX for ; Wed, 7 May 2008 11:33:21 -0700 (PDT) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.189]) by core3.amsl.com (Postfix) with ESMTP id B1F3928C635 for ; Wed, 7 May 2008 11:33:20 -0700 (PDT) Received: by rn-out-0910.google.com with SMTP id e27so144106rng.18 for ; Wed, 07 May 2008 11:33: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:content-transfer-encoding:content-disposition:references; bh=M5jY5HIYVZpbL++6AGQlFIm2zuzEiS4DtAegEwd5xBM=; b=CQiDcgp6JC9eqizUb2oAv3CZwhQiS7aUXKiSFEckrKIxk6dagy7mgGGUbdFpq3FduRCFwyizAD2eQBIr7vfnC/7KW/iARhQyPxJsGUWUOQpKHJqDE9b+mGgIbmI63gSi9mlx+84x9TzHtDAtUYmqWEzCh2k6YY99RLW/5DSdSBs= 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=Rl21UttJvDCbuf1za3z26seUhUQ6BjQI9R4h/OGvg33nM7+jux85ItzilMeyFKvJxo6zCBg/Ce0cu8uFY/sYrFhNgJ+rvuljP5YviHpX+kffOZXWglep5P87Ej8cA1uCasZ0uoD47Yaz7ohpduGcqkvfhgcYXDFfEQMF/ECaPvI= Received: by 10.142.191.2 with SMTP id o2mr1001332wff.132.1210185197213; Wed, 07 May 2008 11:33:17 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Wed, 7 May 2008 11:33:17 -0700 (PDT) Message-ID: Date: Wed, 7 May 2008 11:33:17 -0700 From: "Vijay Devarapallli" To: Pasi.Eronen@nokia.com In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org oops.. I just noticed that you did have the following in the list. o Redirecting a VPN client from one gateway to another (in a cluster of gateways) Is this the same? Or did someone else propose this? Vijay On Wed, May 7, 2008 at 11:30 AM, Vijay Devarapallli wrote: > Hi Pasi, > > I have one more. Sorry for not posting this earlier. > > There was a proposal coming out of the former MIP6 WG to use IKEv2 to > re-direct a mobile node to another home agent. The Binding > Update/Binding Acknowledgement exchange between the mobile node and > the home agent is always preceded by an IKEv2 exchange for mutual > authentication, home address configuration and setting up the required > security associations for protecting Mobile IPv6 signaling messages. > It was felt that it would be desirable for the home agent to tell the > mobile node to go another home agent before the IKEv2 exchange > completes. Otherwise the mobile node would have do the IKEv2 exchange > with the new home agent all over. > > This proposal for re-directing the mobile node to another home agent > during the IKE_SA_INIT exchange was in a ex-MIP6 WG document. There > were some issues raised during the IESG review for the IKEv2 re-direct > mechanism. So the mechanism was taken out and the rest of the document > was published as RFC 5026. One of the concerns expressed was that it > could be generic extension to IKEv2 rather than being something > specific to Mobile IPv6. > > So I would like to propose to add another work item to the new IPsec > WG charter to work on a IKEv2 re-direct mechanism during the > IKE_SA_INIT exchange. Much of the details have already been worked out > (by the ex-MIP6 WG and then some discussions offline), it is just a > matter of writing up a draft. I am in the process of writing up this > draft. This is coming a bit late. I hope it can be included in the > IPsec re-chartering process. > > Regards, > Vijay > > > > On Wed, May 7, 2008 at 3:19 AM, wrote: > > So far, we've had ~20 people who've expressed some form of support > > for creating a WG. This is good -- many current WGs have less than 20 > > people who regularly post to the WG mailing list. > > > > However, by my count, we've also had ~20 proposals for work items. > > That obviously does not add up. > > > > I agree with Paul's comment about the WG scope: the WG should work > > on things where having a WG is really needed, and we actually have a > > *group* of people interested on participating. > > > > Having a WG should not encourage people to develop extensions that > > would not have happened in the absence of a WG (this usually indicates > > they're not widely needed). For some work items that have been > > proposed, an individual draft is IMHO a more appropriate process > > mechanism, and forming a WG would not automatically prevent > > publication of non-WG documents the WG decided not to take. > > > > To get some idea on what work items we have most interest in, I've > > collected those proposed so far (with some things vendors are known to > > do in proprietary ways thrown in). > > > > Please select the items you think the WG should work on (less than > > ten, please), order them most important first, and for each item, > > indicate what you're willing to do: > > > > [E]dit: you're willing to edit the draft corresponding to the work > > item (note: even if we use an individual draft as a starting point, > > this does not automatically determine the editor of the WG item) > > > > [C]ontribute: you're willing to propose non-trivial amounts of > > text for the document during its development > > > > [R]eview: you're willing to review new revisions of the draft > > regularly (not just during WGLC) > > > > For example, > > > > [CR] AEAD algorithms in IKEv2 > > [R] IPsec document roadmap update > > > > would mean that AEAD algorithms is your first priority, and you > > volunteer to contribute and review; and IPsec document roadmap is > > your second priority, and you volunteer to review. > > > > You can also propose a work item that isn't on my list. > > However, for the time being, I think PF_KEY work does not fit > > within the scope of the possible WG charter. > > > > List follows: > > > > o Update to IKEv2 base specification (possible starting point: > > draft-hoffman-ikev2bis) > > > > o IPsec document roadmap update (possible starting point: RFC 2411) > > > > o Using AEAD algorithms in IKEv2 (possible starting point: > > draft-black-ipsec-ikev2-aead-modes) > > > > o Redirecting a VPN client from one gateway to another > > (in a cluster of gateways) > > > > o IPsec "secure beacon", or detecting whether you need VPN or > > not (possible starting point: draft-sheffer-ipsec-secure-beacon) > > > > o Detecting crashed peers faster (possible starting point: > > draft-nir-ike-qcd) > > > > o IKEv2 session resumption / optimizing IKEv2 handshake when > > connecting again to same peer/cluster of peers (possible > > starting point: draft-sheffer-ipsec-failover) > > > > o Authentication-only IPsec that simplifies packet inspection > > (possible starting points: draft-hoffman-esp-null-protocol, > > draft-grewal-ipsec-traffic-visibility) > > > > o Better IPv6 configuration payloads (possible starting point: > > draft-eronen-ipsec-ikev2-ipv6-config) > > > > o Other work for making sure IKEv1 and IKEv2 work as well as > > possible with IPv6, both from standards and operations standpoint > > (please specify more details if you select this one) > > > > o Running IPsec over TCP (so your VPN works even if the coffee > > shop Wi-Fi has stupid packet filtering) > > > > o GSS-API (or Kerberos) authentication for IKEv2 > > > > o Non-EAP-based one-time password authentication (possible > > starting point: draft-sunabhi-otp-ikev2) > > > > o Using GRE "key" header field as IPsec traffic selector (possible > > starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) > > > > o Authentication with Cryptographically Generated Addresses (CGA) > > (possible starting point: draft-laganier-ike-ipv6-cga) > > > > o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec > > (possible starting point: draft-bellovin-useipsec) > > > > o Labeled IPsec for RFC 430x IPsec > > > > o IKEv1/IKEv2 co-existence and transition (please specify more > > details if you select this one) > > > > o Setting up GRE tunnels with IKE (possible starting point: > > draft-wu-l3vpn-ipsec-gre-00) > > > > o Connecting IKEv2 peers behind NATs via a "mediation server" > > (possible starting point: draft-brunner-ikev2-mediation) > > > > o Anything that may be needed from IKE/IPsec with respect to > > routing protocol security (please specify more details if > > you select this one) > > > > o Documenting differences in IPsec usage in IETF vs. 3GPP vs. > > 3GPP2 vs. WiMAX vs. vendors etc. (please specify more details > > if you select this one) > > > > o IKEv2 CAPTCHA > > (possible starting point: draft-mutaf-spikev2-01.txt) > > > > Please reply (on the mailing list) within a week or so -- I will > > then summarize what we have. > > > > Best regards, > > Pasi > > > > --- > > > > P.S. It's good to note that we currently have several other WGs > > working on IPsec: > > > > o BMWG: benchmarking IPsec devices > > > > o BTNS: unauthenticated or leap-of-faith IPsec, channel bindings, > > IPsec APIs for applications (not key management daemons like > > PF_KEY) > > > > o MEXT: interaction between IPsec and Mobile IP, Mobile IP > > specific extensions to IPsec > > > > o MSEC: multicast IPsec > > > > o ROHC: header compression in IPsec tunnel mode SAs > > > > o SOFTWIRE: IPsec tunnels as a softwire, setting those up > > based on BGP etc. > > > > These WGs will continue as-is, and e.g. any changes to their charters > > are not in the scope of this discussion. Future work items could be > > considered case-by-case, but the intent is *not* to collect all > > IPsec-related work to one WG. > > > > --- > > > > P.P.S. Acknowledgement: if you followed how Julien Laganier and > > Marcelo Bagnulo handled the MEXT WG rechartering recently, you'll > > notice I have stolen some ideas from them :-) > > _______________________________________________ > > 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 May 7 12:20:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7FD28C635; Wed, 7 May 2008 12:20: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 B438428C5C1 for ; Wed, 7 May 2008 12:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bw3gNFh1KuX for ; Wed, 7 May 2008 12:20:14 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id A03FF3A6A0B for ; Wed, 7 May 2008 12:20:14 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m47JKCti029789 for ; Wed, 7 May 2008 19:20:12 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m47JKBVs023803 for ; Wed, 7 May 2008 13:20:11 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m47JKBUx022477; Wed, 7 May 2008 14:20:11 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m47JKAFJ022476; Wed, 7 May 2008 14:20:10 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 7 May 2008 14:20:10 -0500 From: Nicolas Williams To: Pasi.Eronen@nokia.com Message-ID: <20080507192010.GL13552@Sun.COM> Mail-Followup-To: Pasi.Eronen@nokia.com, ipsec@ietf.org References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Wed, May 07, 2008 at 01:19:09PM +0300, Pasi.Eronen@nokia.com wrote: I'm willing to review: > o Update to IKEv2 base specification (possible starting point: > draft-hoffman-ikev2bis) > o IPsec document roadmap update (possible starting point: RFC 2411) > o IKEv2 session resumption / optimizing IKEv2 handshake when > connecting again to same peer/cluster of peers (possible > starting point: draft-sheffer-ipsec-failover) > o Labeled IPsec for RFC 430x IPsec > o IKEv1/IKEv2 co-existence and transition (please specify more > details if you select this one) I think this item: > o GSS-API (or Kerberos) authentication for IKEv2 seems unnecessary. Keep in mind that I once thought the opposite. But let's consider: - IPsec w/ Kerberos V -> KINK - IPsec w/ PSK, PKI, EAP -> IKEv2 So what existing, planned or potential GSS-API mechanisms might one want to use with IPsec which isn't covered via KINK or IKEv2? Now, perhaps there is dissatisfaction with KINK. Or perhaps there's a desire to mix Kerberos V and whatnot in one KE. If so, let's hear it. If not, let's drop this. I'm willing to collaborate on this one: > o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec > (possible starting point: draft-bellovin-useipsec) Primarily because I think that applications shouldn't use IPsec without IPsec APIs, and IPsec APIs is something that I'm collaborating on in the BTNS WG. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 8 14:04: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 9F0373A6E7A; Thu, 8 May 2008 14:04: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 3A8693A6E53 for ; Thu, 8 May 2008 14:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsBTvgCAcbZ2 for ; Thu, 8 May 2008 14:04:32 -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 67A023A6E43 for ; Thu, 8 May 2008 14:04:32 -0700 (PDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m48L4UhO020181 for ; Thu, 8 May 2008 21:04:30 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 m48L4UQG057336 for ; Thu, 8 May 2008 17:04:30 -0400 (EDT) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m48KrFjN004366 for ; Thu, 8 May 2008 16:53:15 -0400 (EDT) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m48KrF6c004365 for ipsec@ietf.org; Thu, 8 May 2008 16:53:15 -0400 (EDT) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Thu, 8 May 2008 16:53:15 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20080508205315.GD2207@sun.com> References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Wed, May 07, 2008 at 01:19:09PM +0300, Pasi.Eronen@nokia.com wrote: > However, by my count, we've also had ~20 proposals for work items. > That obviously does not add up. Here are proposals for which I have actual interest: [RC] Running IPsec over TCP (so your VPN works even if the coffee shop Wi-Fi has stupid packet filtering) Note 1: cisco has done stuff like this with their proprietary vpn client. Note 2: I need to dig deep into my memory, but folks I knew in grad school had fun using the x-kernel to construct an arbitrary datagram protocol on top of TCP (RAT == Record-Accessed TCP). Such work might be useful for any "TCP encapsulation" for NAT-Traversal. Note 3: Make sure you include "IKE" as running over TCP. [R] IPsec document roadmap update (possible starting point: RFC 2411) [] Update to IKEv2 base specification (possible starting point: draft-hoffman-ikev2bis) [] Using AEAD algorithms in IKEv2 (possible starting point: draft-black-ipsec-ikev2-aead-modes) (ESPECIALLY including any suggestions Dan H. may have about 4309 improvement or the AES-GCM equivalent to 4309... 41xx, for xx I can't remember). [] IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 9 08:47: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 88B0A3A6818; Fri, 9 May 2008 08:47: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 C9A4128C2F4; Thu, 8 May 2008 09:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.678 X-Spam-Level: X-Spam-Status: No, score=0.678 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2smgT04VhD4; Thu, 8 May 2008 09:00:56 -0700 (PDT) Received: from in.dii.unile.it (in.dii.unile.it [193.204.77.69]) by core3.amsl.com (Postfix) with ESMTP id 136CF28CEEB; Thu, 8 May 2008 06:41:12 -0700 (PDT) Received: from localhost (localhost.unile.it [127.0.0.1]) by in.dii.unile.it (Postfix) with ESMTP id 7BBAF273261; Thu, 8 May 2008 10:57:01 +0200 (CEST) Received: from in.dii.unile.it ([127.0.0.1]) by localhost (in.dii.unile.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDSPZG61lw81; Thu, 8 May 2008 10:56:51 +0200 (CEST) Received: from SNOOPY.unile.it (unknown [193.204.77.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by in.dii.unile.it (Postfix) with ESMTP id 8BF1D273248; Thu, 8 May 2008 10:56:50 +0200 (CEST) Message-Id: <7.0.1.0.2.20080508104656.05dc5818@unile.it> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 08 May 2008 10:56:43 +0200 To: softcom@fesb.hr,rozic@fesb.hr From: "Ing. Luigi Patrono" Mime-Version: 1.0 Content-Type: multipart/mixed; x-avg-checked=avg-ok-707F6791; boundary="=======AVGMAIL-4822C04D74CE=======" X-Mailman-Approved-At: Fri, 09 May 2008 08:27:32 -0700 Subject: [IPsec] CfP of the Symposium on Mobile Wireless Networks (SoftCOM'08) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --=======AVGMAIL-4822C04D74CE======= Content-Type: multipart/alternative; boundary="=====================_7054046==.ALT"; x-avg-checked=avg-ok-707F6791 --=====================_7054046==.ALT Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-707F6791 (We apologize if you receive multiple copies of this email. Please forward this announcement to your colleagues.) ************************************************************************************************************************************* Symposium on MOBILE WIRELESS NETWORKS September 25-27, 2008 Split-Dubrovnik (CROATIA) Symposium Chair: Mario De Blasi University of Salento, Italy, (mario.deblasi@unile.it) The Symposium on Mobile Wireless Networks (see http://www.fesb.hr/SoftCOM/2008/CfP_DeBlasi_2008.pdf for more details) will be held in the frame of the 16th International Conference on Software, Telecommunications and Computer Networks (SoftCOM 2008), co-sponsored by the IEEE Communication Society (COMSOC). The main goal of this symposium is to present and discuss recent advances in the development of innovative wireless networks that support user mobility. Particular attention will be given to recent challenges related to wireless vehicular ad hoc networking (VANET) technologies. These communication systems (vehicle-to-vehicle and vehicle-to-roadside) will enable vehicular both safety applications and non-safety applications such as mobile entertainment. We cordially invite speakers who wish to present original papers on the following subjects, but not limited to these, associated with wireless communication: * Ad Hoc Wireless Networks * Intelligent Transportation Systems (ITS) * Vehicular communications * Safety and entertainment applications * Wireless MAC protocols * Routing protocols in mobile ad hoc wireless networks * Multicast routing in ad hoc wireless networks * Mobile Internet * Transport layer for Wireless Networks * Interoperability between heterogeneous Wireless Networks * Wireless Sensor Networks * Energy management in Ad Hoc Wireless Networks * Quality of Service in Wireless Networks * Security in Wireless Networks * Ultra-Wide-Band radio communications * Wireless PAN, LAN, MAN * Network applications based on RFID technologies Important dates: Paper submission: June 1, 2008 Notification of acceptance: July 1, 2008 Camera ready papers due: September 1, 2008 Submission of Manuscripts: Please follow the general submission requirements of SoftCOM2007 ( http://www.fesb.hr/SoftCOM). ---------------------------------------------------- Ing. Luigi Patrono, PhD ---------------------------------------------------- University of Salento Dep. of Innovation Engineering Via Monteroni 73100 Lecce - ITALY Tel. +39 0832 297330 Fax. +39 0832 297279 e-mail: luigi.patrono@unile.it ---------------------------------------------------- --=====================_7054046==.ALT Content-Type: text/html; charset=us-ascii; x-avg-checked=avg-ok-707F6791 (We apologize if you receive multiple copies of this email. Please forward this announcement to your colleagues.)
*************************************************************************************************************************************
 

Symposium on
MOBILE WIRELESS NETWORKS

September 25-27, 2008
Split-Dubrovnik (CROATIA)

Symposium Chair: Mario De Blasi
University of Salento, Italy, (mario.deblasi@unile.it)

The Symposium on Mobile Wireless Networks (see http://www.fesb.hr/SoftCOM/2008/CfP_DeBlasi_2008.pdf for more details) will be held in the frame of the 16th International Conference on Software, Telecommunications and Computer Networks (SoftCOM 2008), co-sponsored by the IEEE Communication Society (COMSOC).
 
The main goal of this symposium is to present and discuss recent advances in the development of innovative wireless networks that support user mobility. Particular attention will be given to recent challenges related to wireless vehicular ad hoc networking (VANET) technologies. These communication systems (vehicle-to-vehicle and vehicle-to-roadside) will enable vehicular both safety applications and non-safety applications such as mobile entertainment.

We cordially invite speakers who wish to present original papers on the following subjects, but not limited to these, associated with wireless communication:
* Ad Hoc Wireless Networks
* Intelligent Transportation Systems (ITS)
* Vehicular communications
* Safety and entertainment applications
* Wireless MAC protocols
* Routing protocols in mobile ad hoc wireless networks
* Multicast routing in ad hoc wireless networks
* Mobile Internet
* Transport layer for Wireless Networks
* Interoperability between heterogeneous Wireless Networks
* Wireless Sensor Networks
* Energy management in Ad Hoc Wireless Networks
* Quality of Service in Wireless Networks
* Security in Wireless Networks
* Ultra-Wide-Band radio communications
* Wireless PAN, LAN, MAN
* Network applications based on RFID technologies

Important dates:  
                 Paper submission: June 1, 2008
                         Notification of acceptance: July 1, 2008
                        Camera ready papers due: September 1, 2008


Submission of Manuscripts: Please follow the general submission requirements of SoftCOM2007 ( http://www.fesb.hr/SoftCOM).



----------------------------------------------------
Ing.  Luigi Patrono,  PhD
----------------------------------------------------
University of Salento
Dep. of Innovation Engineering
Via Monteroni
73100 Lecce - ITALY

Tel.  +39 0832 297330
Fax. +39 0832 297279
e-mail: luigi.patrono@unile.it
---------------------------------------------------- --=====================_7054046==.ALT-- --=======AVGMAIL-4822C04D74CE======= Content-Type: text/plain; x-avg=cert; charset=us-ascii; x-avg-checked=avg-ok-707F6791 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Description: "AVG certification" No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.10/1421 - Release Date: 07/05/2008= 17.23 --=======AVGMAIL-4822C04D74CE======= 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 --=======AVGMAIL-4822C04D74CE=======-- From ipsec-bounces@ietf.org Fri May 9 08:47: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 9D3FC3A68B7; Fri, 9 May 2008 08:47:48 -0700 (PDT) X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 65534) id 7C4ED3A67F3; Thu, 8 May 2008 21:38:26 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Old-Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC11C28C84D for ; Thu, 8 May 2008 08:21: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 Ld14l8DDi1+A for ; Thu, 8 May 2008 08:21:49 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 8B63228C2D0 for ; Thu, 8 May 2008 06:16:12 -0700 (PDT) Received: from zcp4hxm0.corp.nortel.com (zcp4hxm0.corp.nortel.com [47.152.152.59]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m48AWnv20388; Thu, 8 May 2008 10:32:49 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 8 May 2008 18:32:17 +0800 Message-ID: <6525A993506152478BA085F87670DFF305E18FED@zcp4hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VPN policy encrypts traffic between the router and the local network Thread-Index: Aciw9snYmiGMEw39SRSMWLceJI2Gdg== From: "Gaurav Nagare" To: X-TMDA-Confirmed: Thu, 08 May 2008 21:38:26 -0700 X-Mailman-Approved-At: Fri, 09 May 2008 08:27:32 -0700 Cc: gauravsn@gmail.com Subject: [IPsec] VPN policy encrypts traffic between the router and the local network X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1139357747==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1139357747== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8B0F6.CA652E59" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8B0F6.CA652E59 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Here is the setup for this issue ____ _____ | | | | 192.168.0.0/16--------------- |SGW1|-----------------------------------|SGW2|------------192.168.11.0/ 24 (Network) |_____ |20.1.1.20 20.1.1.21|_____| (network) There is a VPN policy in tunnel mode between SGW1 and SGW2. the VPN tunnel is setup with two networks, 192.168.0.0/16(kind of supernet) and 192.168.11.0/24. Now, once the IPsec policy in enabled, client on network 192.168.11.0/24 is not able to access the local router interface and trafic between local network and router is also encrypted. However the router allows IPsec traffic to pass to a peer on network 192.168.0.0/16. I am not sure if this behaviour is acceptable or the router should be accessible from local network. Please let me know your comments. Regards, Gaurav ------_=_NextPart_001_01C8B0F6.CA652E59 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable VPN policy encrypts traffic between the router and the local = network

Hi,
Here is the setup for this = issue

         &nbs= p;            = ;            =      = ____           &nb= sp;           &nbs= p;            = ;   _____
         &nbs= p;            = ;            =    |          = |            =             &= nbsp;          = |          |
192.168.0.0/16--------------- = |SGW1|-----------------------------------|SGW2|------------192.168.11.0/2= 4
 (Network)       &= nbsp;           &n= bsp;   |_____ = |20.1.1.20         = 20.1.1.21|_____|         &nb= sp;  (network)



There is a VPN policy in tunnel mode = between SGW1 and SGW2. the VPN tunnel is setup with two networks, = 192.168.0.0/16(kind of supernet) and 192.168.11.0/24.

Now, once the IPsec policy in enabled, = client on network 192.168.11.0/24 is not able to access the local router = interface and trafic between local network and router is also encrypted. = However the router allows IPsec traffic to pass to a peer on network = 192.168.0.0/16.

I am not sure if this behaviour is = acceptable or the router should be accessible from local network. Please = let me know your comments.


Regards,
Gaurav

------_=_NextPart_001_01C8B0F6.CA652E59-- --===============1139357747== 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 --===============1139357747==-- From ipsec-bounces@ietf.org Fri May 9 11:03:51 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 AB96D28C163; Fri, 9 May 2008 11:03:51 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22B323A6801 for ; Fri, 9 May 2008 10:44: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 WQsO9XT78MQP for ; Fri, 9 May 2008 10:44:52 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by core3.amsl.com (Postfix) with ESMTP id 574CF3A67CE for ; Fri, 9 May 2008 10:44:52 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i29so1475370wxd.31 for ; Fri, 09 May 2008 10:43:01 -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=UYj2YxcFhTtW7zHKhfL0JRA2tv6qkLUdEw59SuuRyDQ=; b=O+fHB1zqj3sQTkAdxPaaG+w5TDwdQ4yB5AJ5ae5fJCh4DNFfIKfhPVjm0juoRAYx9cjPtLiZrScD5Yq5yPkfLQ43/YmOOCR0fUi7k9lSmrBqA/JkzFyQ89Ei/4elaEbwHPjjYpmBd3hnvAR8JLT/XzXkqWN/ONmNXnhayEtRrO8= 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=AtIKDZLeLWV3wH1O9GCuXd95lhI6CNtD8iZB9BRo3lXB2U3jRvHDacZrkmsXy6RnLDDhznd3OJ6DEqKZ7M+WpLpR4NQO5wdDKbt0cFSFKr+1+bKVweEIXehHCjsjKbF2/TDIaZXrE7uzKl84t5r/WCwfOlvH0syUw6aOT4hnh70= Received: by 10.100.10.15 with SMTP id 15mr6125504anj.105.1210354981448; Fri, 09 May 2008 10:43:01 -0700 (PDT) Received: by 10.100.202.10 with HTTP; Fri, 9 May 2008 10:43:01 -0700 (PDT) Message-ID: Date: Fri, 9 May 2008 10:43:01 -0700 From: "fan zhao" To: "Vijay Devarapallli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Vijay, I also support this work item. Sincerely, fan On Wed, May 7, 2008 at 11:33 AM, Vijay Devarapallli wrote: > oops.. I just noticed that you did have the following in the list. > > o Redirecting a VPN client from one gateway to another > (in a cluster of gateways) > > Is this the same? Or did someone else propose this? > > Vijay > > On Wed, May 7, 2008 at 11:30 AM, Vijay Devarapallli wrote: >> Hi Pasi, >> >> I have one more. Sorry for not posting this earlier. >> >> There was a proposal coming out of the former MIP6 WG to use IKEv2 to >> re-direct a mobile node to another home agent. The Binding >> Update/Binding Acknowledgement exchange between the mobile node and >> the home agent is always preceded by an IKEv2 exchange for mutual >> authentication, home address configuration and setting up the required >> security associations for protecting Mobile IPv6 signaling messages. >> It was felt that it would be desirable for the home agent to tell the >> mobile node to go another home agent before the IKEv2 exchange >> completes. Otherwise the mobile node would have do the IKEv2 exchange >> with the new home agent all over. >> >> This proposal for re-directing the mobile node to another home agent >> during the IKE_SA_INIT exchange was in a ex-MIP6 WG document. There >> were some issues raised during the IESG review for the IKEv2 re-direct >> mechanism. So the mechanism was taken out and the rest of the document >> was published as RFC 5026. One of the concerns expressed was that it >> could be generic extension to IKEv2 rather than being something >> specific to Mobile IPv6. >> >> So I would like to propose to add another work item to the new IPsec >> WG charter to work on a IKEv2 re-direct mechanism during the >> IKE_SA_INIT exchange. Much of the details have already been worked out >> (by the ex-MIP6 WG and then some discussions offline), it is just a >> matter of writing up a draft. I am in the process of writing up this >> draft. This is coming a bit late. I hope it can be included in the >> IPsec re-chartering process. >> >> Regards, >> Vijay >> >> >> >> On Wed, May 7, 2008 at 3:19 AM, wrote: >> > So far, we've had ~20 people who've expressed some form of support >> > for creating a WG. This is good -- many current WGs have less than 20 >> > people who regularly post to the WG mailing list. >> > >> > However, by my count, we've also had ~20 proposals for work items. >> > That obviously does not add up. >> > >> > I agree with Paul's comment about the WG scope: the WG should work >> > on things where having a WG is really needed, and we actually have a >> > *group* of people interested on participating. >> > >> > Having a WG should not encourage people to develop extensions that >> > would not have happened in the absence of a WG (this usually indicates >> > they're not widely needed). For some work items that have been >> > proposed, an individual draft is IMHO a more appropriate process >> > mechanism, and forming a WG would not automatically prevent >> > publication of non-WG documents the WG decided not to take. >> > >> > To get some idea on what work items we have most interest in, I've >> > collected those proposed so far (with some things vendors are known to >> > do in proprietary ways thrown in). >> > >> > Please select the items you think the WG should work on (less than >> > ten, please), order them most important first, and for each item, >> > indicate what you're willing to do: >> > >> > [E]dit: you're willing to edit the draft corresponding to the work >> > item (note: even if we use an individual draft as a starting point, >> > this does not automatically determine the editor of the WG item) >> > >> > [C]ontribute: you're willing to propose non-trivial amounts of >> > text for the document during its development >> > >> > [R]eview: you're willing to review new revisions of the draft >> > regularly (not just during WGLC) >> > >> > For example, >> > >> > [CR] AEAD algorithms in IKEv2 >> > [R] IPsec document roadmap update >> > >> > would mean that AEAD algorithms is your first priority, and you >> > volunteer to contribute and review; and IPsec document roadmap is >> > your second priority, and you volunteer to review. >> > >> > You can also propose a work item that isn't on my list. >> > However, for the time being, I think PF_KEY work does not fit >> > within the scope of the possible WG charter. >> > >> > List follows: >> > >> > o Update to IKEv2 base specification (possible starting point: >> > draft-hoffman-ikev2bis) >> > >> > o IPsec document roadmap update (possible starting point: RFC 2411) >> > >> > o Using AEAD algorithms in IKEv2 (possible starting point: >> > draft-black-ipsec-ikev2-aead-modes) >> > >> > o Redirecting a VPN client from one gateway to another >> > (in a cluster of gateways) >> > >> > o IPsec "secure beacon", or detecting whether you need VPN or >> > not (possible starting point: draft-sheffer-ipsec-secure-beacon) >> > >> > o Detecting crashed peers faster (possible starting point: >> > draft-nir-ike-qcd) >> > >> > o IKEv2 session resumption / optimizing IKEv2 handshake when >> > connecting again to same peer/cluster of peers (possible >> > starting point: draft-sheffer-ipsec-failover) >> > >> > o Authentication-only IPsec that simplifies packet inspection >> > (possible starting points: draft-hoffman-esp-null-protocol, >> > draft-grewal-ipsec-traffic-visibility) >> > >> > o Better IPv6 configuration payloads (possible starting point: >> > draft-eronen-ipsec-ikev2-ipv6-config) >> > >> > o Other work for making sure IKEv1 and IKEv2 work as well as >> > possible with IPv6, both from standards and operations standpoint >> > (please specify more details if you select this one) >> > >> > o Running IPsec over TCP (so your VPN works even if the coffee >> > shop Wi-Fi has stupid packet filtering) >> > >> > o GSS-API (or Kerberos) authentication for IKEv2 >> > >> > o Non-EAP-based one-time password authentication (possible >> > starting point: draft-sunabhi-otp-ikev2) >> > >> > o Using GRE "key" header field as IPsec traffic selector (possible >> > starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) >> > >> > o Authentication with Cryptographically Generated Addresses (CGA) >> > (possible starting point: draft-laganier-ike-ipv6-cga) >> > >> > o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec >> > (possible starting point: draft-bellovin-useipsec) >> > >> > o Labeled IPsec for RFC 430x IPsec >> > >> > o IKEv1/IKEv2 co-existence and transition (please specify more >> > details if you select this one) >> > >> > o Setting up GRE tunnels with IKE (possible starting point: >> > draft-wu-l3vpn-ipsec-gre-00) >> > >> > o Connecting IKEv2 peers behind NATs via a "mediation server" >> > (possible starting point: draft-brunner-ikev2-mediation) >> > >> > o Anything that may be needed from IKE/IPsec with respect to >> > routing protocol security (please specify more details if >> > you select this one) >> > >> > o Documenting differences in IPsec usage in IETF vs. 3GPP vs. >> > 3GPP2 vs. WiMAX vs. vendors etc. (please specify more details >> > if you select this one) >> > >> > o IKEv2 CAPTCHA >> > (possible starting point: draft-mutaf-spikev2-01.txt) >> > >> > Please reply (on the mailing list) within a week or so -- I will >> > then summarize what we have. >> > >> > Best regards, >> > Pasi >> > >> > --- >> > >> > P.S. It's good to note that we currently have several other WGs >> > working on IPsec: >> > >> > o BMWG: benchmarking IPsec devices >> > >> > o BTNS: unauthenticated or leap-of-faith IPsec, channel bindings, >> > IPsec APIs for applications (not key management daemons like >> > PF_KEY) >> > >> > o MEXT: interaction between IPsec and Mobile IP, Mobile IP >> > specific extensions to IPsec >> > >> > o MSEC: multicast IPsec >> > >> > o ROHC: header compression in IPsec tunnel mode SAs >> > >> > o SOFTWIRE: IPsec tunnels as a softwire, setting those up >> > based on BGP etc. >> > >> > These WGs will continue as-is, and e.g. any changes to their charters >> > are not in the scope of this discussion. Future work items could be >> > considered case-by-case, but the intent is *not* to collect all >> > IPsec-related work to one WG. >> > >> > --- >> > >> > P.P.S. Acknowledgement: if you followed how Julien Laganier and >> > Marcelo Bagnulo handled the MEXT WG rechartering recently, you'll >> > notice I have stolen some ideas from them :-) >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 9 11: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 56F4528C151; Fri, 9 May 2008 11: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 947C33A6866 for ; Fri, 9 May 2008 11:08: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=[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 tg9tjGCdescM for ; Fri, 9 May 2008 11:08:13 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id 00A6A3A67FA for ; Fri, 9 May 2008 11:06:27 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so854422and.122 for ; Fri, 09 May 2008 11:05:08 -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=4UwTQoqDNg1IK8iOa2267JIPV80lXW+jChd7rJrGb4g=; b=cZQ5r96BUiGvoMpaLPLwunR8eapfoZbclMD+1un6KIrnew7ho5ReMmYDadgi+p5idQJ3ZbAD5vc23k6S95B5QASC9qUmLoEHFTmBiN1RdvmPnSP8Z39YdTvMdtgvjmfxhzHZ5weiqWWSK3ig2+IlVU+8/XNzxEv8zm77RMQ2CjQ= 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=NWsSr4DS+3p9hTgBRORp/ftm2OkgToENwwooFxYqVUOkOV3JBGAGcTItE9VU5/XUrjykIVG7DaNWUly6h2gF9qxyxz3H1mbzqn4Gy+TOwqHBUewfVYefYmghgZ1Yt3IDv8oitFDljdRDz76j7AllKSkrbyCiDi3jKDmhmm9LRcU= Received: by 10.100.41.4 with SMTP id o4mr6107043ano.136.1210354819745; Fri, 09 May 2008 10:40:19 -0700 (PDT) Received: by 10.100.202.10 with HTTP; Fri, 9 May 2008 10:40:19 -0700 (PDT) Message-ID: Date: Fri, 9 May 2008 10:40:19 -0700 From: "fan zhao" To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Pasi, The following is my list. > > [CR] o Update to IKEv2 base specification (possible starting point: > draft-hoffman-ikev2bis) > > [ECR] o Redirecting a VPN client from one gateway to another > (in a cluster of gateways) > > [CR] o Better IPv6 configuration payloads (possible starting point: > draft-eronen-ipsec-ikev2-ipv6-config) Thanks. Sincerely, fan > > > Please reply (on the mailing list) within a week or so -- I will > then summarize what we have. > > Best regards, > Pasi > > --- > > P.S. It's good to note that we currently have several other WGs > working on IPsec: > > o BMWG: benchmarking IPsec devices > > o BTNS: unauthenticated or leap-of-faith IPsec, channel bindings, > IPsec APIs for applications (not key management daemons like > PF_KEY) > > o MEXT: interaction between IPsec and Mobile IP, Mobile IP > specific extensions to IPsec > > o MSEC: multicast IPsec > > o ROHC: header compression in IPsec tunnel mode SAs > > o SOFTWIRE: IPsec tunnels as a softwire, setting those up > based on BGP etc. > > These WGs will continue as-is, and e.g. any changes to their charters > are not in the scope of this discussion. Future work items could be > considered case-by-case, but the intent is *not* to collect all > IPsec-related work to one WG. > > --- > > P.P.S. Acknowledgement: if you followed how Julien Laganier and > Marcelo Bagnulo handled the MEXT WG rechartering recently, you'll > notice I have stolen some ideas from them :-) > _______________________________________________ > 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 May 9 12:03: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 295B23A690C; Fri, 9 May 2008 12:03: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 3CC9C3A68C4 for ; Fri, 9 May 2008 12:03:06 -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 EUWv2wH3PoQD for ; Fri, 9 May 2008 12:03:04 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id D46E83A68DF for ; Fri, 9 May 2008 12:00:53 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m49IxvUT014631; Fri, 9 May 2008 13:59:57 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 May 2008 13:59:57 -0500 Received: from [142.133.10.140] ([142.133.10.140]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 May 2008 13:59:56 -0500 Message-ID: <48249EA8.9040802@ericsson.com> Date: Fri, 09 May 2008 14:57:44 -0400 From: Suresh Krishnan User-Agent: Thunderbird 2.0.0.12 (X11/20080227) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> X-OriginalArrivalTime: 09 May 2008 18:59:56.0901 (UTC) FILETIME=[DF7B5950:01C8B206] Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Pasi, Here is my ordered list > o [R] Update to IKEv2 base specification (possible starting point: > draft-hoffman-ikev2bis) > > o [ECR] Redirecting a VPN client from one gateway to another > (in a cluster of gateways) > > o [ECR] Detecting crashed peers faster (possible starting point: > draft-nir-ike-qcd) > > o [CR] Better IPv6 configuration payloads (possible starting point: > draft-eronen-ipsec-ikev2-ipv6-config) > > o [ECR] Guidelines for Mandating the Use of IPsec, for RFC430x IPsec > (possible starting point: draft-bellovin-useipsec) > > o [ECR] IPsec document roadmap update (possible starting point: RFC 2411) > > o [CR] Using GRE "key" header field as IPsec traffic selector (possible > starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) > > o [CR] Authentication with Cryptographically Generated Addresses (CGA) > (possible starting point: draft-laganier-ike-ipv6-cga) > > o [CR] IPsec "secure beacon", or detecting whether you need VPN or > not (possible starting point: draft-sheffer-ipsec-secure-beacon) Thanks Suresh _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 9 12:23: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 03EAE3A67FD; Fri, 9 May 2008 12:23: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 5DC5F3A67FD for ; Fri, 9 May 2008 12:23: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 B4n0OKYnynFW for ; Fri, 9 May 2008 12:23:19 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 0DA443A67CE for ; Fri, 9 May 2008 12:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=ldondeti@qualcomm.com; q=dns/txt; s=qcdkim; t=1210360998; x=1241896998; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-ironport-av; z=Message-ID:=20<4824A40A.7040408@qualcomm.com>|Date:=20Fr i,=2009=20May=202008=2012:20:42=20-0700|From:=20Lakshmina th=20Dondeti=20|User-Agent:=20Thun derbird=202.0.0.14=20(Windows/20080421)|MIME-Version:=201 .0|To:=20Pasi.Eronen@nokia.com|CC:=20ipsec@ietf.org |Subject:=20Re:=20[IPsec]=20IPsec=20maintenance/extension s=20WG,=20summary=20so=20far|References:=20<1696498986EFE C4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> |In-Reply-To:=20<1696498986EFEC4D9153717DA325CB728D5AF2@v aebe104.NOE.Nokia.com>|Content-Type:=20text/plain=3B=20ch arset=3DISO-8859-15=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-IronPort-AV:=20E=3DM cAfee=3Bi=3D"5100,188,5292"=3B=20a=3D"2841995"; bh=vo4H3AT/aoQEOjcNOw6S5dmmFn7uvRexhG2s+cTuLjU=; b=kzZVPV9rYaaFabBdBQRaoh+KGCcamz/JRZ7nVk7hGGOX5+uWHopx4JnF 9F8ziFltKl4YTSz+r5gjPnza7TGfY9t5FTz7JvMXBAn2Or6ZsztmA8dNN 6nZ6QYJqVnQrmnNsEiA6Y+nJ+hUQ5EApyXNeQyUShjouvQTrt4OmuR8Z3 w=; X-IronPort-AV: E=McAfee;i="5100,188,5292"; a="2841995" 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; 09 May 2008 12:20:41 -0700 Received: from msgtransport05.qualcomm.com (msgtransport05.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m49JKdn7027613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 9 May 2008 12:20:39 -0700 Received: from [10.50.68.20] (qconnect-10-50-68-20.qualcomm.com [10.50.68.20]) by msgtransport05.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id m49JKciQ027095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 May 2008 12:20:39 -0700 Message-ID: <4824A40A.7040408@qualcomm.com> Date: Fri, 09 May 2008 12:20:42 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I will probably review the NAT related stuff as well, and in general might review most of the documents chartered anyway. Will contribute at least to the failover related stuff. At some point I was interested in the "use-IPsec" type of work, but I am not so sure it is really useful. The work on documenting differences in IPsec usage says something about this already. :) regards, Lakshminath On 5/7/2008 3:19 AM, Pasi.Eronen@nokia.com wrote: > List follows: > [R] Update to IKEv2 base specification (possible starting point: draft-hoffman-ikev2bis) > [R] IPsec document roadmap update (possible starting point: RFC 2411) > [R] Using AEAD algorithms in IKEv2 (possible starting point: draft-black-ipsec-ikev2-aead-modes) > [R] Redirecting a VPN client from one gateway to another (in a cluster of gateways) > > o IPsec "secure beacon", or detecting whether you need VPN or > not (possible starting point: draft-sheffer-ipsec-secure-beacon) > > o Detecting crashed peers faster (possible starting point: > draft-nir-ike-qcd) > [ECR] IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) > [R] Authentication-only IPsec that simplifies packet inspection > (possible starting points: draft-hoffman-esp-null-protocol, > draft-grewal-ipsec-traffic-visibility) > > o Better IPv6 configuration payloads (possible starting point: > draft-eronen-ipsec-ikev2-ipv6-config) > > o Other work for making sure IKEv1 and IKEv2 work as well as > possible with IPv6, both from standards and operations standpoint > (please specify more details if you select this one) > > o Running IPsec over TCP (so your VPN works even if the coffee > shop Wi-Fi has stupid packet filtering) > > o GSS-API (or Kerberos) authentication for IKEv2 > > o Non-EAP-based one-time password authentication (possible > starting point: draft-sunabhi-otp-ikev2) > > o Using GRE "key" header field as IPsec traffic selector (possible > starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) > > o Authentication with Cryptographically Generated Addresses (CGA) > (possible starting point: draft-laganier-ike-ipv6-cga) > > o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec > (possible starting point: draft-bellovin-useipsec) > > o Labeled IPsec for RFC 430x IPsec > > o IKEv1/IKEv2 co-existence and transition (please specify more > details if you select this one) > > o Setting up GRE tunnels with IKE (possible starting point: > draft-wu-l3vpn-ipsec-gre-00) > > o Connecting IKEv2 peers behind NATs via a "mediation server" > (possible starting point: draft-brunner-ikev2-mediation) > > o Anything that may be needed from IKE/IPsec with respect to > routing protocol security (please specify more details if > you select this one) > [CR] Documenting differences in IPsec usage in IETF vs. 3GPP vs. 3GPP2 vs. WiMAX vs. vendors etc. (please specify more details > if you select this one) > > o IKEv2 CAPTCHA > (possible starting point: draft-mutaf-spikev2-01.txt) > > Please reply (on the mailing list) within a week or so -- I will > then summarize what we have. > > Best regards, > Pasi > > --- > > P.S. It's good to note that we currently have several other WGs > working on IPsec: > > o BMWG: benchmarking IPsec devices > > o BTNS: unauthenticated or leap-of-faith IPsec, channel bindings, > IPsec APIs for applications (not key management daemons like > PF_KEY) > > o MEXT: interaction between IPsec and Mobile IP, Mobile IP > specific extensions to IPsec > > o MSEC: multicast IPsec > > o ROHC: header compression in IPsec tunnel mode SAs > > o SOFTWIRE: IPsec tunnels as a softwire, setting those up > based on BGP etc. > > These WGs will continue as-is, and e.g. any changes to their charters > are not in the scope of this discussion. Future work items could be > considered case-by-case, but the intent is *not* to collect all > IPsec-related work to one WG. > > --- > > P.P.S. Acknowledgement: if you followed how Julien Laganier and > Marcelo Bagnulo handled the MEXT WG rechartering recently, you'll > notice I have stolen some ideas from them :-) > _______________________________________________ > 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 Sat May 10 08:45: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 F09773A68CA; Sat, 10 May 2008 08:45: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 A00393A68CA for ; Sat, 10 May 2008 08:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.587 X-Spam-Level: X-Spam-Status: No, score=-0.587 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FAKE_REPLY_C=2.012] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCRR1+LvOENo for ; Sat, 10 May 2008 08:45:18 -0700 (PDT) Received: from arwen.velv.hr (arwen.velv.hr [193.198.63.3]) by core3.amsl.com (Postfix) with ESMTP id AFCE33A687F for ; Sat, 10 May 2008 08:45:13 -0700 (PDT) Received: from localhost (localhost.velv.hr [127.0.0.1]) by arwen.velv.hr (Postfix) with ESMTP id 6E92642BE; Sat, 10 May 2008 15:38:35 +0200 (CEST) Received: from arwen.velv.hr ([127.0.0.1]) by localhost (arwen [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13366-01; Sat, 10 May 2008 15:38:33 +0200 (CEST) Received: by arwen.velv.hr (Postfix, from userid 1790) id ECD3142FD; Sat, 10 May 2008 15:38:32 +0200 (CEST) Date: Sat, 10 May 2008 15:38:32 +0200 From: Ana Kukec To: Pasi.Eronen@nokia.com Message-ID: <20080510133832.GA13441@arwen.velv.hr> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at vels.hr Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all, [ECR] Authentication with Cryptographically Generated Addresses (CGA) (possible starting point: draft-laganier-ike-ipv6-cga) Ana _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun May 11 22:32: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 5545F28C20E; Sun, 11 May 2008 22:32:04 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 990BA28C135 for ; Sun, 11 May 2008 22:32: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 cO97hSc4xwL2 for ; Sun, 11 May 2008 22:32:00 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id E048728C20E for ; Sun, 11 May 2008 22:31:59 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so958402tib.25 for ; Sun, 11 May 2008 22:31:55 -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=SSrFveV3B2XOIifUbHNlh3YcFJ7hPE1oUyWi37gfyGI=; b=mh3afdZCOKDeHtlgmEbSqdXwwZPdxUu3IMVW5Tpudvo9LtRv7NvZXr/FdkfdFNavExdATU5D4b60m6BDN1RQZQCvnmIPbOW1bQucCGOPkgXk2nTZjgk5FbR//KcUJj+g1tRo1YItwJJ0QBiWSNkoQPkHusj2bguzD8BFrA86VRo= 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=IoG1Eq/jUufmr9gdq47Ocbs49Yhs/Y++FQcpV1iWMsNf/wY2IIxMzoudjg65ui5TwmRrlK8zcfY+7ywvrKnc2+/hC7UpRNWKSaizQ4p6dOIihyHSG0j43HDnnGMjMTiSotYc6tCBGW8MIemADJdUSojVrPfjzkYa/xcD8Edu5E4= Received: by 10.110.84.2 with SMTP id h2mr743305tib.45.1210570315669; Sun, 11 May 2008 22:31:55 -0700 (PDT) Received: by 10.110.93.4 with HTTP; Sun, 11 May 2008 22:31:55 -0700 (PDT) Message-ID: <1d38a3350805112231g1d721ad0jf9a28f6a9626aa90@mail.gmail.com> Date: Mon, 12 May 2008 13:31:55 +0800 From: "Hui Deng" To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, "denghui@chinamobile.com" Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 Thanks Pasi's charter discussion, Here is my list: [ECR] o Using GRE "key" header field as IPsec traffic selector (possible starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) [ECR] o Setting up GRE tunnels with IKE (possible starting point: draft-wu-l3vpn-ipsec-gre-00) [ECR] o IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) Thanks, -Hui 2008/5/7 : > So far, we've had ~20 people who've expressed some form of support > for creating a WG. This is good -- many current WGs have less than 20 > people who regularly post to the WG mailing list. > > However, by my count, we've also had ~20 proposals for work items. > That obviously does not add up. > > I agree with Paul's comment about the WG scope: the WG should work > on things where having a WG is really needed, and we actually have a > *group* of people interested on participating. > > Having a WG should not encourage people to develop extensions that > would not have happened in the absence of a WG (this usually indicates > they're not widely needed). For some work items that have been > proposed, an individual draft is IMHO a more appropriate process > mechanism, and forming a WG would not automatically prevent > publication of non-WG documents the WG decided not to take. > > To get some idea on what work items we have most interest in, I've > collected those proposed so far (with some things vendors are known to > do in proprietary ways thrown in). > > Please select the items you think the WG should work on (less than > ten, please), order them most important first, and for each item, > indicate what you're willing to do: > > [E]dit: you're willing to edit the draft corresponding to the work > item (note: even if we use an individual draft as a starting point, > this does not automatically determine the editor of the WG item) > > [C]ontribute: you're willing to propose non-trivial amounts of > text for the document during its development > > [R]eview: you're willing to review new revisions of the draft > regularly (not just during WGLC) > > For example, > > [CR] AEAD algorithms in IKEv2 > [R] IPsec document roadmap update > > would mean that AEAD algorithms is your first priority, and you > volunteer to contribute and review; and IPsec document roadmap is > your second priority, and you volunteer to review. > > You can also propose a work item that isn't on my list. > However, for the time being, I think PF_KEY work does not fit > within the scope of the possible WG charter. > > List follows: > > o Update to IKEv2 base specification (possible starting point: > draft-hoffman-ikev2bis) > > o IPsec document roadmap update (possible starting point: RFC 2411) > > o Using AEAD algorithms in IKEv2 (possible starting point: > draft-black-ipsec-ikev2-aead-modes) > > o Redirecting a VPN client from one gateway to another > (in a cluster of gateways) > > o IPsec "secure beacon", or detecting whether you need VPN or > not (possible starting point: draft-sheffer-ipsec-secure-beacon) > > o Detecting crashed peers faster (possible starting point: > draft-nir-ike-qcd) > > o IKEv2 session resumption / optimizing IKEv2 handshake when > connecting again to same peer/cluster of peers (possible > starting point: draft-sheffer-ipsec-failover) > > o Authentication-only IPsec that simplifies packet inspection > (possible starting points: draft-hoffman-esp-null-protocol, > draft-grewal-ipsec-traffic-visibility) > > o Better IPv6 configuration payloads (possible starting point: > draft-eronen-ipsec-ikev2-ipv6-config) > > o Other work for making sure IKEv1 and IKEv2 work as well as > possible with IPv6, both from standards and operations standpoint > (please specify more details if you select this one) > > o Running IPsec over TCP (so your VPN works even if the coffee > shop Wi-Fi has stupid packet filtering) > > o GSS-API (or Kerberos) authentication for IKEv2 > > o Non-EAP-based one-time password authentication (possible > starting point: draft-sunabhi-otp-ikev2) > > o Using GRE "key" header field as IPsec traffic selector (possible > starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) > > o Authentication with Cryptographically Generated Addresses (CGA) > (possible starting point: draft-laganier-ike-ipv6-cga) > > o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec > (possible starting point: draft-bellovin-useipsec) > > o Labeled IPsec for RFC 430x IPsec > > o IKEv1/IKEv2 co-existence and transition (please specify more > details if you select this one) > > o Setting up GRE tunnels with IKE (possible starting point: > draft-wu-l3vpn-ipsec-gre-00) > > o Connecting IKEv2 peers behind NATs via a "mediation server" > (possible starting point: draft-brunner-ikev2-mediation) > > o Anything that may be needed from IKE/IPsec with respect to > routing protocol security (please specify more details if > you select this one) > > o Documenting differences in IPsec usage in IETF vs. 3GPP vs. > 3GPP2 vs. WiMAX vs. vendors etc. (please specify more details > if you select this one) > > o IKEv2 CAPTCHA > (possible starting point: draft-mutaf-spikev2-01.txt) > > Please reply (on the mailing list) within a week or so -- I will > then summarize what we have. > > Best regards, > Pasi > > --- > > P.S. It's good to note that we currently have several other WGs > working on IPsec: > > o BMWG: benchmarking IPsec devices > > o BTNS: unauthenticated or leap-of-faith IPsec, channel bindings, > IPsec APIs for applications (not key management daemons like > PF_KEY) > > o MEXT: interaction between IPsec and Mobile IP, Mobile IP > specific extensions to IPsec > > o MSEC: multicast IPsec > > o ROHC: header compression in IPsec tunnel mode SAs > > o SOFTWIRE: IPsec tunnels as a softwire, setting those up > based on BGP etc. > > These WGs will continue as-is, and e.g. any changes to their charters > are not in the scope of this discussion. Future work items could be > considered case-by-case, but the intent is *not* to collect all > IPsec-related work to one WG. > > --- > > P.P.S. Acknowledgement: if you followed how Julien Laganier and > Marcelo Bagnulo handled the MEXT WG rechartering recently, you'll > notice I have stolen some ideas from them :-) > _______________________________________________ > 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 May 12 03:30: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 322833A67AC; Mon, 12 May 2008 03:30: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 B652D3A67AC for ; Mon, 12 May 2008 03:30:01 -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 H5JFz2Du7qnZ for ; Mon, 12 May 2008 03:30:01 -0700 (PDT) Received: from strongswan.org (sidv0150.hsr.ch [152.96.52.150]) by core3.amsl.com (Postfix) with ESMTP id E65CA3A6785 for ; Mon, 12 May 2008 03:30:00 -0700 (PDT) Received: from [10.10.0.1] (satay.strongsec.com [10.10.0.1]) by strongswan.org (Postfix) with ESMTP id C7BB1EF907; Mon, 12 May 2008 09:00:48 +0200 (CEST) Message-ID: <4827EB1F.3060103@strongswan.org> Date: Mon, 12 May 2008 09:00:47 +0200 From: Andreas Steffen User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 Hello Pasi, here the is the list of the strongSwan team: [ECR] Connecting IKEv2 peers behind NATs via a "mediation server" (possible starting point: draft-brunner-ikev2-mediation) [R] Update to IKEv2 base specification (possible starting point: draft-hoffman-ikev2bis) [R] Detecting crashed peers faster (possible starting point: draft-nir-ike-qcd) [R] IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) [R] Running IPsec over TCP (so your VPN works even if the coffee shop Wi-Fi has stupid packet filtering) Best regards Andreas ====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 12 04:53: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 D2B783A6B7D; Mon, 12 May 2008 04:53: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 3B23F3A6AE7 for ; Mon, 12 May 2008 04:53:32 -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 rkBg0fwu7zJG for ; Mon, 12 May 2008 04:53:31 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with SMTP id 5E3103A6B7D for ; Mon, 12 May 2008 04:52:02 -0700 (PDT) Received: from source ([202.122.134.5]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP; Mon, 12 May 2008 04:51:38 PDT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 May 2008 17:21:26 +0530 Message-ID: <7A581A93408E68408DB73274370D78D342A906@NOI1EXCH002.sfnt.local> In-Reply-To: <4827EB1F.3060103@strongswan.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IPsec maintenance/extensions WG, summary so far Thread-Index: Aci0GykeTozCr4RIQuyZlhn8oLvfSQACYe6A References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <4827EB1F.3060103@strongswan.org> From: "Kumar, Sunil" To: Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 Pasi, We really support the idea of Working Group towards the IPSec and really want to contribute as well. Here are proposals for which I am interested: [R] IPsec document roadmap update [R] Update to IKEv2 base specification (possible starting point: draft-hoffman-ikev2bis) [ECR] Redirecting a VPN client from one gateway to another (in a cluster of gateways) Thanks n Regards, Sunil Kumar SafeNet Infotech Pvt. Ltd. Noida- 201301 India -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Andreas Steffen Sent: Monday, May 12, 2008 12:31 PM To: Pasi.Eronen@nokia.com Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far Hello Pasi, here the is the list of the strongSwan team: [ECR] Connecting IKEv2 peers behind NATs via a "mediation server" (possible starting point: draft-brunner-ikev2-mediation) [R] Update to IKEv2 base specification (possible starting point: draft-hoffman-ikev2bis) [R] Detecting crashed peers faster (possible starting point: draft-nir-ike-qcd) [R] IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) [R] Running IPsec over TCP (so your VPN works even if the coffee shop Wi-Fi has stupid packet filtering) Best regards Andreas ====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 12 08:01: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 D3E703A6AF6; Mon, 12 May 2008 08:01: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 AA7C43A6AF6 for ; Mon, 12 May 2008 08:01:37 -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 gPN-BQdkVj7T for ; Mon, 12 May 2008 08:01:36 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by core3.amsl.com (Postfix) with ESMTP id 3FC8A3A6AB4 for ; Mon, 12 May 2008 08:01:34 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1055093tib.25 for ; Mon, 12 May 2008 08:01:19 -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:mime-version:content-type:content-transfer-encoding:content-disposition; bh=FfXjDAN64WqDAWLpEyHe/UCkfFVWji4I3r6G6jXzwi4=; b=IVDTuSY+ilq5lpN6jwOk91DeJOCbqqQDvuF+cndGPf68IqEMnuhjqx9lxGJ1+jR5u50X5ZRCmvZQhsl3qb7nr2/owCIew6XDkkK9WJGBxCYtUF/hZ/2yWm+K7l9nF4lLfGLCW2fPFvEa7A6jTyT3jVjTh72XkFImmb4zwpUBnag= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=ugTLSWwcVRiBE4rZNr2Fh6J3yWNZ79R3UjcPaCqX2W+lfgw1R8ZyGWYk7o54vT2cgFjBY7AgP/pnVul+oUXV84+Gbck6jJvfrOuq+5j6ljh2vLZfOVdk8HkEo5V90/Wo2nuHzzQzCRcew7i0HfeFNtzg/MVrhiJTEuie+4h1U3c= Received: by 10.110.8.5 with SMTP id 5mr811670tih.3.1210604478750; Mon, 12 May 2008 08:01:18 -0700 (PDT) Received: by 10.110.90.18 with HTTP; Mon, 12 May 2008 08:01:18 -0700 (PDT) Message-ID: Date: Mon, 12 May 2008 23:01:18 +0800 From: "ma yc" To: ipsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 Parsi, I would like to participate the following items. [ECR] o Using GRE "key" header field as IPsec traffic selector (possible starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) [ECR] o Setting up GRE tunnels with IKE (possible starting point: draft-wu-l3vpn-ipsec-gre-00) [R] o Non-EAP-based one-time password authentication (possible starting point: draft-sunabhi-otp-ikev2) [R] o IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) Regards Yuanchen > On Wed, May 7, 2008 3:19 am, Pasi.Eronen@nokia.com wrote: > > So far, we've had ~20 people who've expressed some form of support > > for creating a WG. This is good -- many current WGs have less than 20 > > people who regularly post to the WG mailing list. > > > > However, by my count, we've also had ~20 proposals for work items. > > That obviously does not add up. > > > > I agree with Paul's comment about the WG scope: the WG should work > > on things where having a WG is really needed, and we actually have a > > *group* of people interested on participating. > > > > Having a WG should not encourage people to develop extensions that > > would not have happened in the absence of a WG (this usually indicates > > they're not widely needed). For some work items that have been > > proposed, an individual draft is IMHO a more appropriate process > > mechanism, and forming a WG would not automatically prevent > > publication of non-WG documents the WG decided not to take. > > > > To get some idea on what work items we have most interest in, I've > > collected those proposed so far (with some things vendors are known to > > do in proprietary ways thrown in). > > > > Please select the items you think the WG should work on (less than > > ten, please), order them most important first, and for each item, > > indicate what you're willing to do: > > > > [E]dit: you're willing to edit the draft corresponding to the work > > item (note: even if we use an individual draft as a starting point, > > this does not automatically determine the editor of the WG item) > > > > [C]ontribute: you're willing to propose non-trivial amounts of > > text for the document during its development > > > > [R]eview: you're willing to review new revisions of the draft > > regularly (not just during WGLC) > > > > For example, > > > > [CR] AEAD algorithms in IKEv2 > > [R] IPsec document roadmap update > > > > would mean that AEAD algorithms is your first priority, and you > > volunteer to contribute and review; and IPsec document roadmap is > > your second priority, and you volunteer to review. > > > > You can also propose a work item that isn't on my list. > > However, for the time being, I think PF_KEY work does not fit > > within the scope of the possible WG charter. > > > > List follows: > > > > o Update to IKEv2 base specification (possible starting point: > > draft-hoffman-ikev2bis) > > > > o IPsec document roadmap update (possible starting point: RFC 2411) > > > > o Using AEAD algorithms in IKEv2 (possible starting point: > > draft-black-ipsec-ikev2-aead-modes) > > > > o Redirecting a VPN client from one gateway to another > > (in a cluster of gateways) > > > > o IPsec "secure beacon", or detecting whether you need VPN or > > not (possible starting point: draft-sheffer-ipsec-secure-beacon) > > > > o Detecting crashed peers faster (possible starting point: > > draft-nir-ike-qcd) > > > > o IKEv2 session resumption / optimizing IKEv2 handshake when > > connecting again to same peer/cluster of peers (possible > > starting point: draft-sheffer-ipsec-failover) > > > > o Authentication-only IPsec that simplifies packet inspection > > (possible starting points: draft-hoffman-esp-null-protocol, > > draft-grewal-ipsec-traffic-visibility) > > > > o Better IPv6 configuration payloads (possible starting point: > > draft-eronen-ipsec-ikev2-ipv6-config) > > > > o Other work for making sure IKEv1 and IKEv2 work as well as > > possible with IPv6, both from standards and operations standpoint > > (please specify more details if you select this one) > > > > o Running IPsec over TCP (so your VPN works even if the coffee > > shop Wi-Fi has stupid packet filtering) > > > > o GSS-API (or Kerberos) authentication for IKEv2 > > > > o Non-EAP-based one-time password authentication (possible > > starting point: draft-sunabhi-otp-ikev2) > > > > o Using GRE "key" header field as IPsec traffic selector (possible > > starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) > > > > o Authentication with Cryptographically Generated Addresses (CGA) > > (possible starting point: draft-laganier-ike-ipv6-cga) > > > > o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec > > (possible starting point: draft-bellovin-useipsec) > > > > o Labeled IPsec for RFC 430x IPsec > > > > o IKEv1/IKEv2 co-existence and transition (please specify more > > details if you select this one) > > > > o Setting up GRE tunnels with IKE (possible starting point: > > draft-wu-l3vpn-ipsec-gre-00) > > > > o Connecting IKEv2 peers behind NATs via a "mediation server" > > (possible starting point: draft-brunner-ikev2-mediation) > > > > o Anything that may be needed from IKE/IPsec with respect to > > routing protocol security (please specify more details if > > you select this one) > > > > o Documenting differences in IPsec usage in IETF vs. 3GPP vs. > > 3GPP2 vs. WiMAX vs. vendors etc. (please specify more details > > if you select this one) > > > > o IKEv2 CAPTCHA > > (possible starting point: draft-mutaf-spikev2-01.txt) > > > > Please reply (on the mailing list) within a week or so -- I will > > then summarize what we have. > > > > Best regards, > > Pasi > > > > --- > > > > P.S. It's good to note that we currently have several other WGs > > working on IPsec: > > > > o BMWG: benchmarking IPsec devices > > > > o BTNS: unauthenticated or leap-of-faith IPsec, channel bindings, > > IPsec APIs for applications (not key management daemons like > > PF_KEY) > > > > o MEXT: interaction between IPsec and Mobile IP, Mobile IP > > specific extensions to IPsec > > > > o MSEC: multicast IPsec > > > > o ROHC: header compression in IPsec tunnel mode SAs > > > > o SOFTWIRE: IPsec tunnels as a softwire, setting those up > > based on BGP etc. > > > > These WGs will continue as-is, and e.g. any changes to their charters > > are not in the scope of this discussion. Future work items could be > > considered case-by-case, but the intent is *not* to collect all > > IPsec-related work to one WG. > > > > --- > > > > P.P.S. Acknowledgement: if you followed how Julien Laganier and > > Marcelo Bagnulo handled the MEXT WG rechartering recently, you'll > > notice I have stolen some ideas from them :-) > > _______________________________________________ > > 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 May 12 09:38: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 D7DF83A680A; Mon, 12 May 2008 09:38: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 B26D83A680A for ; Mon, 12 May 2008 09:38:30 -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 E9NkL+yYTUBT for ; Mon, 12 May 2008 09:38:29 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 7C0873A6804 for ; Mon, 12 May 2008 09:38:29 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 12 May 2008 09:36:09 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.27,474,1204531200"; d="scan'208";a="563703136" Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmga001.fm.intel.com with ESMTP; 12 May 2008 09:39:07 -0700 Received: from fmsmsx881.amr.corp.intel.com ([10.19.19.13]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 May 2008 09:38:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 May 2008 09:38:17 -0700 Message-ID: In-Reply-To: <1d38a3350805112231g1d721ad0jf9a28f6a9626aa90@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IPsec maintenance/extensions WG, summary so far Thread-Index: Aciz8YglpuJpVZeiSWeRqVD3dwzSSgAW+2Jg References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <1d38a3350805112231g1d721ad0jf9a28f6a9626aa90@mail.gmail.com> From: "Grewal, Ken" To: X-OriginalArrivalTime: 12 May 2008 16:38:18.0113 (UTC) FILETIME=[950C7710:01C8B44E] Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 Pasi, I will be interested in the following topics. [ECR] o Authentication-only IPsec that simplifies packet inspection (possible starting points: draft-hoffman-esp-null-protocol, draft-grewal-ipsec-traffic-visibility) [ECR] o Running IPsec over TCP (so your VPN works even if the coffee shop Wi-Fi has stupid packet filtering) [RC] o IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) [R] o Redirecting a VPN client from one gateway to another (in a cluster of gateways) [R] o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec (possible starting point: draft-bellovin-useipsec) [R] o Connecting IKEv2 peers behind NATs via a "mediation server" (possible starting point: draft-brunner-ikev2-mediation) Thanks, - Ken 2008/5/7 : > So far, we've had ~20 people who've expressed some form of support > for creating a WG. This is good -- many current WGs have less than 20 > people who regularly post to the WG mailing list. > > However, by my count, we've also had ~20 proposals for work items. > That obviously does not add up. > > I agree with Paul's comment about the WG scope: the WG should work > on things where having a WG is really needed, and we actually have a > *group* of people interested on participating. > > Having a WG should not encourage people to develop extensions that > would not have happened in the absence of a WG (this usually indicates > they're not widely needed). For some work items that have been > proposed, an individual draft is IMHO a more appropriate process > mechanism, and forming a WG would not automatically prevent > publication of non-WG documents the WG decided not to take. > > To get some idea on what work items we have most interest in, I've > collected those proposed so far (with some things vendors are known to > do in proprietary ways thrown in). > > Please select the items you think the WG should work on (less than > ten, please), order them most important first, and for each item, > indicate what you're willing to do: > > [E]dit: you're willing to edit the draft corresponding to the work > item (note: even if we use an individual draft as a starting point, > this does not automatically determine the editor of the WG item) > > [C]ontribute: you're willing to propose non-trivial amounts of > text for the document during its development > > [R]eview: you're willing to review new revisions of the draft > regularly (not just during WGLC) > > For example, > > [CR] AEAD algorithms in IKEv2 > [R] IPsec document roadmap update > > would mean that AEAD algorithms is your first priority, and you > volunteer to contribute and review; and IPsec document roadmap is > your second priority, and you volunteer to review. > > You can also propose a work item that isn't on my list. > However, for the time being, I think PF_KEY work does not fit > within the scope of the possible WG charter. > > List follows: > > o Update to IKEv2 base specification (possible starting point: > draft-hoffman-ikev2bis) > > o IPsec document roadmap update (possible starting point: RFC 2411) > > o Using AEAD algorithms in IKEv2 (possible starting point: > draft-black-ipsec-ikev2-aead-modes) > > o Redirecting a VPN client from one gateway to another > (in a cluster of gateways) > > o IPsec "secure beacon", or detecting whether you need VPN or > not (possible starting point: draft-sheffer-ipsec-secure-beacon) > > o Detecting crashed peers faster (possible starting point: > draft-nir-ike-qcd) > > o IKEv2 session resumption / optimizing IKEv2 handshake when > connecting again to same peer/cluster of peers (possible > starting point: draft-sheffer-ipsec-failover) > > o Authentication-only IPsec that simplifies packet inspection > (possible starting points: draft-hoffman-esp-null-protocol, > draft-grewal-ipsec-traffic-visibility) > > o Better IPv6 configuration payloads (possible starting point: > draft-eronen-ipsec-ikev2-ipv6-config) > > o Other work for making sure IKEv1 and IKEv2 work as well as > possible with IPv6, both from standards and operations standpoint > (please specify more details if you select this one) > > o Running IPsec over TCP (so your VPN works even if the coffee > shop Wi-Fi has stupid packet filtering) > > o GSS-API (or Kerberos) authentication for IKEv2 > > o Non-EAP-based one-time password authentication (possible > starting point: draft-sunabhi-otp-ikev2) > > o Using GRE "key" header field as IPsec traffic selector (possible > starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) > > o Authentication with Cryptographically Generated Addresses (CGA) > (possible starting point: draft-laganier-ike-ipv6-cga) > > o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec > (possible starting point: draft-bellovin-useipsec) > > o Labeled IPsec for RFC 430x IPsec > > o IKEv1/IKEv2 co-existence and transition (please specify more > details if you select this one) > > o Setting up GRE tunnels with IKE (possible starting point: > draft-wu-l3vpn-ipsec-gre-00) > > o Connecting IKEv2 peers behind NATs via a "mediation server" > (possible starting point: draft-brunner-ikev2-mediation) > > o Anything that may be needed from IKE/IPsec with respect to > routing protocol security (please specify more details if > you select this one) > > o Documenting differences in IPsec usage in IETF vs. 3GPP vs. > 3GPP2 vs. WiMAX vs. vendors etc. (please specify more details > if you select this one) > > o IKEv2 CAPTCHA > (possible starting point: draft-mutaf-spikev2-01.txt) > > Please reply (on the mailing list) within a week or so -- I will > then summarize what we have. > > Best regards, > Pasi > > --- > > P.S. It's good to note that we currently have several other WGs > working on IPsec: > > o BMWG: benchmarking IPsec devices > > o BTNS: unauthenticated or leap-of-faith IPsec, channel bindings, > IPsec APIs for applications (not key management daemons like > PF_KEY) > > o MEXT: interaction between IPsec and Mobile IP, Mobile IP > specific extensions to IPsec > > o MSEC: multicast IPsec > > o ROHC: header compression in IPsec tunnel mode SAs > > o SOFTWIRE: IPsec tunnels as a softwire, setting those up > based on BGP etc. > > These WGs will continue as-is, and e.g. any changes to their charters > are not in the scope of this discussion. Future work items could be > considered case-by-case, but the intent is *not* to collect all > IPsec-related work to one WG. > > --- > > P.P.S. Acknowledgement: if you followed how Julien Laganier and > Marcelo Bagnulo handled the MEXT WG rechartering recently, you'll > notice I have stolen some ideas from them :-) > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 04:48: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 A4B9D3A6C0F; Tue, 13 May 2008 04:48: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 239A73A6881 for ; Tue, 13 May 2008 04:48: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 aZ4gXrsVbqn1 for ; Tue, 13 May 2008 04:48:28 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 70DA23A6C16 for ; Tue, 13 May 2008 04:48:02 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9ECBE294007; Mon, 12 May 2008 13:32:48 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1402C294001; Mon, 12 May 2008 13:32:48 +0300 (IDT) Received: from MBP.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m4CAWlfU000030; Mon, 12 May 2008 13:32:47 +0300 (IDT) Message-Id: <921AE5AE-BBB7-4E2D-853E-15B9A0B07B31@checkpoint.com> From: Yoav Nir To: Dan McDonald In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 12 May 2008 13:32:46 +0300 References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080508205315.GD2207@sun.com> X-Mailer: Apple Mail (2.919.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 May 8, 2008, at 11:53 PM, Dan McDonald wrote: > > Here are proposals for which I have actual interest: > > [RC] Running IPsec over TCP (so your VPN works even if the coffee > shop Wi-Fi has stupid packet filtering) > > Note 1: cisco has done stuff like this with their proprietary vpn > client. So have others. Sometimes I think this is the whole point of so-called "SSL VPN" > > Note 2: I need to dig deep into my memory, but folks I knew in > grad > school had fun using the x-kernel to construct an arbitrary > datagram protocol on top of TCP (RAT == Record-Accessed TCP). > Such work might be useful for any "TCP encapsulation" for > NAT-Traversal. > > Note 3: Make sure you include "IKE" as running over TCP. A few years ago I suggested just IKE over TCP. That proposal was shot down because "using fragments, you can get UDP packets up to 65K", which should be good for IKE. So your Wi-Fi router with stupid packet filtering is considered "broken". The IETF usually takes the position that broken implementations should be fixed, not circumvented. At the time I tried to justify IKE over TCP because routers sometimes lost fragments and some packet filtering firewalls dropped packets. The answer was "(1) If a router can't handle fragments then it's broken and (2) If you're going to send messages over a lossless connection, use SCTP". like the stupid packet filter that can't handle UDP fragments is going to handle SCTP But here's another couple of notes for you: Note 4: Since the Wi-Fi has stupid packet filtering, the only TCP connection that's going to work is to port 443. Some of those stupid filters try allow only ports 80 and 443, and they scan port 80 to make sure there's valid HTTP in there Note 5: Some of them are getting so smart, they look at the traffic in port 443 to make sure it's really TLS. Which brings us back to the point about "SSL VPN" _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 04:48: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 685B53A6C10; Tue, 13 May 2008 04:48: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 982403A6C10 for ; Tue, 13 May 2008 04:48: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 yf5C8qUpxo4W for ; Tue, 13 May 2008 04:48:28 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 77EAD3A6C15 for ; Tue, 13 May 2008 04:48:01 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8DEE2294004; Sat, 10 May 2008 23:31:47 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 38B3A294001; Sat, 10 May 2008 23:30:53 +0300 (IDT) Received: from [172.31.24.139] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m4AKUqfU013279; Sat, 10 May 2008 23:30:52 +0300 (IDT) Message-Id: <695DA200-8E23-404F-924D-AAA056750E56@checkpoint.com> From: Yoav Nir To: ipsec@ietf.org In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 10 May 2008 23:30:52 +0300 References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> X-Mailer: Apple Mail (2.919.2) Cc: "Pasi.Eronen@nokia.com>" Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 May 7, 2008, at 1:19 PM, wrote: > > List follows: > > [R] Redirecting a VPN client from one gateway to another > (in a cluster of gateways) > > [CR] IPsec "secure beacon", or detecting whether you need VPN or > not (possible starting point: draft-sheffer-ipsec-secure-beacon) > > [EC] Detecting crashed peers faster (possible starting point: > draft-nir-ike-qcd) > > [R] IKEv2 session resumption / optimizing IKEv2 handshake when > connecting again to same peer/cluster of peers (possible > starting point: draft-sheffer-ipsec-failover) > > [R] Better IPv6 configuration payloads (possible starting point: > draft-eronen-ipsec-ikev2-ipv6-config) > > [CR] Running IPsec over TCP (so your VPN works even if the coffee > shop Wi-Fi has stupid packet filtering) > > [R] Connecting IKEv2 peers behind NATs via a "mediation server" > (possible starting point: draft-brunner-ikev2-mediation) _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 04:49: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 E9D473A6C18; Tue, 13 May 2008 04:49: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 D750C3A6C18 for ; Tue, 13 May 2008 04:48: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 iz5SAqz1z0RR for ; Tue, 13 May 2008 04:48:58 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 0DA3B3A6C1A for ; Tue, 13 May 2008 04:48:58 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6B72329400C; Mon, 12 May 2008 19:35:04 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4436A294008; Mon, 12 May 2008 19:35:03 +0300 (IDT) Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id m4CGZ3fV029698; Mon, 12 May 2008 19:35:03 +0300 (IDT) Message-ID: <482871B2.7000304@checkpoint.com> Date: Mon, 12 May 2008 19:34:58 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ipsec@ietf.org, Pasi.Eronen@nokia.com, Yoav Nir References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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, Here's my priority list with some annotations: [R] Update to IKEv2 base specification (possible starting point: draft-hoffman-ikev2bis) [R] Detecting crashed peers faster (possible starting point: draft-nir-ike-qcd) [ECR] IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) [ERC] Anything that may be needed from IKE/IPsec with respect to routing protocol security - this is a placeholder, since the ongoing discussion on routing security is both important and likely to benefit from using IKE, instead of an ad hoc key management solution (or none). So I'd rather have it in the charter from day one, even if we don't yet have concrete drafts. [?] Redirecting a VPN client from one gateway to another (in a cluster of gateways) - this can be easily folded into the "session resumption" work, and probably should. [ECR] IPsec "secure beacon", or detecting whether you need VPN or not (possible starting point: draft-sheffer-ipsec-secure-beacon) [ECR] Authentication-only IPsec that simplifies packet inspection (possible starting points: draft-hoffman-esp-null-protocol, draft-grewal-ipsec-traffic-visibility) [R] Better IPv6 configuration payloads (possible starting point: draft-eronen-ipsec-ikev2-ipv6-config) [R] IPsec document roadmap update (possible starting point: RFC 2411) [R] Connecting IKEv2 peers behind NATs via a "mediation server" (possible starting point: draft-brunner-ikev2-mediation) - but I'd like to see a less IKE-specific solution here. Pasi, thanks for facilitating this discussion! Yaron Pasi.Eronen@nokia.com wrote: > So far, we've had ~20 people who've expressed some form of support > for creating a WG. This is good -- many current WGs have less than 20 > people who regularly post to the WG mailing list. > > However, by my count, we've also had ~20 proposals for work items. > That obviously does not add up. > > I agree with Paul's comment about the WG scope: the WG should work > on things where having a WG is really needed, and we actually have a > *group* of people interested on participating. > > Having a WG should not encourage people to develop extensions that > would not have happened in the absence of a WG (this usually indicates > they're not widely needed). For some work items that have been > proposed, an individual draft is IMHO a more appropriate process > mechanism, and forming a WG would not automatically prevent > publication of non-WG documents the WG decided not to take. > > To get some idea on what work items we have most interest in, I've > collected those proposed so far (with some things vendors are known to > do in proprietary ways thrown in). > > Please select the items you think the WG should work on (less than > ten, please), order them most important first, and for each item, > indicate what you're willing to do: > > [E]dit: you're willing to edit the draft corresponding to the work > item (note: even if we use an individual draft as a starting point, > this does not automatically determine the editor of the WG item) > > [C]ontribute: you're willing to propose non-trivial amounts of > text for the document during its development > > [R]eview: you're willing to review new revisions of the draft > regularly (not just during WGLC) > > For example, > > [CR] AEAD algorithms in IKEv2 > [R] IPsec document roadmap update > > would mean that AEAD algorithms is your first priority, and you > volunteer to contribute and review; and IPsec document roadmap is > your second priority, and you volunteer to review. > > You can also propose a work item that isn't on my list. > However, for the time being, I think PF_KEY work does not fit > within the scope of the possible WG charter. > > List follows: > [deleted] _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 04:49:03 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 66CCC3A6C1E; Tue, 13 May 2008 04:49:03 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B780B3A6C18 for ; Tue, 13 May 2008 04:49: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=[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 dyauqxuwFZBz for ; Tue, 13 May 2008 04:48:59 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3F44D3A6C03 for ; Tue, 13 May 2008 04:48:59 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8059129400B; Mon, 12 May 2008 14:20:42 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B46DC29400A; Mon, 12 May 2008 14:20:40 +0300 (IDT) Received: from MBP.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m4CBKefU023190; Mon, 12 May 2008 14:20:40 +0300 (IDT) Message-Id: From: Yoav Nir To: ipsec@ietf.org In-Reply-To: <695DA200-8E23-404F-924D-AAA056750E56@checkpoint.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 12 May 2008 14:20:40 +0300 References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <695DA200-8E23-404F-924D-AAA056750E56@checkpoint.com> X-Mailer: Apple Mail (2.919.2) Cc: "Pasi.Eronen@nokia.com>" , yoavnir@hotmail.com Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 Sorry, last time I sent it I forgot to sort them by priority. Here goes again > > List follows: [R] IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) [EC] Detecting crashed peers faster (possible starting point: draft-nir-ike-qcd) [ECR] Preventing DoS attacks by using a puzzle mechanism (no draft yet, but I'm interested in whether the proposed WG would like something like that, given that there may be IPR claims) [CR] Running IPsec over TCP (so your VPN works even if the coffee shop Wi-Fi has stupid packet filtering) [R] Redirecting a VPN client from one gateway to another (in a cluster of gateways) [CR] IPsec "secure beacon", or detecting whether you need VPN or not (possible starting point: draft-sheffer-ipsec-secure-beacon) [R] Connecting IKEv2 peers behind NATs via a "mediation server" (possible starting point: draft-brunner-ikev2-mediation) _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 04: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 F11D93A6C1D; Tue, 13 May 2008 04:50:51 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B5143A6C28 for ; Tue, 13 May 2008 04:50: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=[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 c6aq+LP6Zeg3 for ; Tue, 13 May 2008 04:50:49 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 08B6E3A6C26 for ; Tue, 13 May 2008 04:50:49 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6B0E5294005; Sat, 10 May 2008 23:19:42 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id BAB6C294004; Sat, 10 May 2008 23:19:41 +0300 (IDT) Received: from [172.31.24.139] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m4AKJefU009734; Sat, 10 May 2008 23:19:41 +0300 (IDT) Message-Id: From: Yoav Nir To: Dan McDonald In-Reply-To: <20080508205315.GD2207@sun.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 10 May 2008 23:19:40 +0300 References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080508205315.GD2207@sun.com> X-Mailer: Apple Mail (2.919.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 May 8, 2008, at 11:53 PM, Dan McDonald wrote: > > Here are proposals for which I have actual interest: > > [RC] Running IPsec over TCP (so your VPN works even if the coffee > shop Wi-Fi has stupid packet filtering) > > Note 1: cisco has done stuff like this with their proprietary vpn > client. So have others. Sometimes I think this is the whole point of so-called "SSL VPN" > > Note 2: I need to dig deep into my memory, but folks I knew in > grad > school had fun using the x-kernel to construct an arbitrary > datagram protocol on top of TCP (RAT == Record-Accessed TCP). > Such work might be useful for any "TCP encapsulation" for > NAT-Traversal. > > Note 3: Make sure you include "IKE" as running over TCP. A few years ago I suggested just IKE over TCP. That proposal was shot down because "using fragments, you can get UDP packets up to 65K", which should be good for IKE. So your Wi-Fi router with stupid packet filtering is considered "broken". The IETF usually takes the position that broken implementations should be fixed, not circumvented. At the time I tried to justify IKE over TCP because routers sometimes lost fragments and some packet filtering firewalls dropped packets. The answer was "(1) If a router can't handle fragments then it's broken and (2) If you're going to send messages over a lossless connection, use SCTP". like the stupid packet filter that can't handle UDP fragments is going to handle SCTP But here's another couple of notes for you: Note 4: Since the Wi-Fi has stupid packet filtering, the only TCP connection that's going to work is to port 443. Some of those stupid filters try allow only ports 80 and 443, and they scan port 80 to make sure there's valid HTTP in there Note 5: Some of them are getting so smart, they look at the traffic in port 443 to make sure it's really TLS. Which brings us back to the point about "SSL VPN" _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 04:59: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 0692528C260; Tue, 13 May 2008 04:59: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 313D828C260 for ; Tue, 13 May 2008 04:59: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 OSdcN9dLOpak for ; Tue, 13 May 2008 04:59:50 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 7222828C15F for ; Tue, 13 May 2008 04:59:50 -0700 (PDT) Received: from [128.89.252.30] (helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Jvt9H-0005NM-4D; Tue, 13 May 2008 07:58:27 -0400 Message-ID: <48298261.3080700@bbn.com> Date: Tue, 13 May 2008 07:58:25 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Yoav Nir References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080508205315.GD2207@sun.com> In-Reply-To: Cc: ipsec@ietf.org, Dan McDonald Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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: > On May 8, 2008, at 11:53 PM, Dan McDonald wrote: >> Here are proposals for which I have actual interest: >> >> [RC] Running IPsec over TCP (so your VPN works even if the coffee >> shop Wi-Fi has stupid packet filtering) >> >> Note 1: cisco has done stuff like this with their proprietary vpn >> client. > > So have others. Sometimes I think this is the whole point of so-called > "SSL VPN" This can also be done using RFC 3093. --RLB _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 06:47: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 C2EBC3A6AF4; Tue, 13 May 2008 06:47: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 DF1F53A6C13 for ; Tue, 13 May 2008 06:47:31 -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 gkFfbiFbSLDW for ; Tue, 13 May 2008 06:47:31 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A6C263A6AF4 for ; Tue, 13 May 2008 06:47:30 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 57559294002; Tue, 13 May 2008 16:18:42 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 90F8F294001; Tue, 13 May 2008 16:18:41 +0300 (IDT) Received: from MBP.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m4DDIffU005581; Tue, 13 May 2008 16:18:41 +0300 (IDT) Message-Id: <4E0A1558-D20D-49E2-9563-2B89345508AA@checkpoint.com> From: Yoav Nir To: Richard Barnes In-Reply-To: <48298261.3080700@bbn.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 13 May 2008 16:18:40 +0300 References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080508205315.GD2207@sun.com> <48298261.3080700@bbn.com> X-Mailer: Apple Mail (2.919.2) Cc: ipsec@ietf.org, Dan McDonald Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 May 13, 2008, at 2:58 PM, Richard Barnes wrote: > Yoav Nir wrote: >> On May 8, 2008, at 11:53 PM, Dan McDonald wrote: >>> Here are proposals for which I have actual interest: >>> >>> [RC] Running IPsec over TCP (so your VPN works even if the coffee >>> shop Wi-Fi has stupid packet filtering) >>> >>> Note 1: cisco has done stuff like this with their proprietary >>> vpn >>> client. >> So have others. Sometimes I think this is the whole point of so- >> called "SSL VPN" > > This can also be done using RFC 3093. > > --RLB Actually, RFC 3093 only specifies TCP/IP/HTTP/TCP/IP. It specifies neither UDP/IP/HTTP/TCP/IP nor ESP/IP/HTTP/TCP/IP, which makes it unsuitable for either IKE or IPsec. :-) I know there is a general sentiment in the IETF against circumventing defective equipment, but vendors like Cisco (and Check Point) have to get our products working even in said coffee shop. It's a shame that this IETF sentiment prevents us from doing so in an interoperable manner. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 08:04: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 674FB3A6C30; Tue, 13 May 2008 08:04: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 445A33A6C22 for ; Tue, 13 May 2008 08:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSIcBa6JrzDT for ; Tue, 13 May 2008 08:04:22 -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 A015E28C0EF for ; Tue, 13 May 2008 08:04:21 -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 m4DE272M025989 for ; Tue, 13 May 2008 14:02:07 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m4DE27NC048445 for ; Tue, 13 May 2008 08:02:07 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m4DE23a3025354; Tue, 13 May 2008 09:02:03 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m4DE237l025353; Tue, 13 May 2008 09:02:03 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 13 May 2008 09:02:02 -0500 From: Nicolas Williams To: Yoav Nir Message-ID: <20080513140202.GZ13552@Sun.COM> Mail-Followup-To: Yoav Nir , Richard Barnes , ipsec@ietf.org, Dan McDonald References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080508205315.GD2207@sun.com> <48298261.3080700@bbn.com> <4E0A1558-D20D-49E2-9563-2B89345508AA@checkpoint.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <4E0A1558-D20D-49E2-9563-2B89345508AA@checkpoint.com> User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org, Richard Barnes , Dan McDonald Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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, May 13, 2008 at 04:18:40PM +0300, Yoav Nir wrote: > I know there is a general sentiment in the IETF against circumventing > defective equipment, but vendors like Cisco (and Check Point) have to > get our products working even in said coffee shop. It's a shame that > this IETF sentiment prevents us from doing so in an interoperable > manner. FWIW, in the several years that I have been using an IPsec-based VPN I've not have had any trouble with hotel or coffee shop wifi filtering out IPsec. OTOH, in the several years before that when I used an IPsec-VPN-over-TCP solution I had many problems where bits would stop moving. I don't know if that was a function of flow control issues (hmmm, TCP over TCP...), lousy client software, or what. But I do know that I never have such issues now with straight IPsec. I have had some strange road warrior problems with _IP_ though. The most interesting one being a hotel wifi network whose DHCP server handed out addresses with a /32 netmask: my Solaris laptop then would then reject the default route from the DHCP server since the router wasn't on-link (going by the netmask) and there was no other route to it. I was able to make this work (and once it did so did IPsec, of course). All that said, I do find it might odd that there isn't an option for running IKE over TCP/SCTP. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 08:44: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 427A63A6BED; Tue, 13 May 2008 08:44: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 AC5713A6C3A for ; Tue, 13 May 2008 08:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[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 P86ZpBfP10uL for ; Tue, 13 May 2008 08:44:45 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id F2A343A6BED for ; Tue, 13 May 2008 08:44:44 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m4DFglnw064422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 May 2008 08:42:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 13 May 2008 08:42:45 -0700 To: IPsec WG From: Paul Hoffman Subject: [IPsec] Fwd: Last Call: draft-kato-ipsec-camellia-modes (The Additional Modes of Operation for Camellia and Its Use With IPsec) to Proposed Standard 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 IESG has received a request from an individual submitter to consider >the following document: > >- 'The Additional Modes of Operation for Camellia and Its Use With > IPsec' > as a Proposed Standard > >The IESG plans to make a decision in the next few weeks, and solicits >final comments on this action. Please send substantive comments to the >ietf@ietf.org mailing lists by 2008-06-10. Exceptionally, >comments may be sent to iesg@ietf.org instead. In either case, please >retain the beginning of the Subject line to allow automated sorting. > >The file can be obtained via >http://www.ietf.org/internet-drafts/draft-kato-ipsec-camellia-modes-07.txt --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 09:27: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 C93123A68AD; Tue, 13 May 2008 09:27: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 E32063A68F2 for ; Tue, 13 May 2008 09:27:56 -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 2SQqeS0qUPnl for ; Tue, 13 May 2008 09:27:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 03DE93A6C2C for ; Tue, 13 May 2008 09:27:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,480,1204531200"; d="scan'208";a="33293578" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 13 May 2008 09:26:12 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m4DGQCab001057; Tue, 13 May 2008 09:26:12 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m4DGQFe0014526; Tue, 13 May 2008 16:26:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 09:26:11 -0700 Received: from [128.107.163.179] ([128.107.163.179]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 May 2008 09:26:11 -0700 Message-ID: <4829C123.3020208@cisco.com> Date: Tue, 13 May 2008 09:26:11 -0700 From: Cheryl Madson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> X-OriginalArrivalTime: 13 May 2008 16:26:11.0527 (UTC) FILETIME=[0E61FD70:01C8B516] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=614; t=1210695972; x=1211559972; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=cmadson@cisco.com; z=From:=20Cheryl=20Madson=20 |Subject:=20Re=3A=20[IPsec]=20IPsec=20maintenance/extension s=20WG,=20summary=20so=20far |Sender:=20; bh=bc7gi76gjMHhWUaXOTvF93B7DeWp79g4vhvAaqSPy6k=; b=EVXw+HmdEv81eyhEz+6Ds/j2U30lRKxY2eZNj3Lv4QLahyluCNlceOEIKs f7VxDCa/9dbU2YNOWDmLtoiKwTvFPcVOVrl6FnR1ZtnIMujBJCFb8OfciTti 5Q0RW+zHGx; Authentication-Results: sj-dkim-3; header.From=cmadson@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cmadson@cisco.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 Pasi, 1) I'm actually interested in more than these, but until I better understand the background/issues, I'm not comfortable volunteering as of yet. 2) (E) means that I'm willing to help edit if necessary 3) The priorities are a bit arbitrary + [ECR] IKEv1/IKEv2 working better with IPv6 + [ECR] IKEv1/v2 coexistence/transition + [(E)CR] Updated to IKEv2 base specification + [ECR] Authentication-only IPsec + [(E)CR] document roadmap update + [ECR] Using GRE key header field as a traffic selector + [CR] Setting up GRE tunnels with IKE + [CR] Better IPv6 configuration payloads thx - C _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 12:47: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 C46E93A6880; Tue, 13 May 2008 12:47: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 37E8F3A687F for ; Tue, 13 May 2008 12:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dB2td3wcDnrK for ; Tue, 13 May 2008 12:47:47 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id 3E96E3A67A4 for ; Tue, 13 May 2008 12:47:46 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4DJjQMP015196 for ; Tue, 13 May 2008 19:45:26 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m4DJjPdQ046443 for ; Tue, 13 May 2008 13:45:26 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m4DJjM4U025757; Tue, 13 May 2008 14:45:22 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m4DJjMgp025756; Tue, 13 May 2008 14:45:22 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 13 May 2008 14:45:22 -0500 From: Nicolas Williams To: Yoav Nir Message-ID: <20080513194521.GK13552@Sun.COM> Mail-Followup-To: Yoav Nir , Richard Barnes , ipsec@ietf.org, Dan McDonald References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080508205315.GD2207@sun.com> <48298261.3080700@bbn.com> <4E0A1558-D20D-49E2-9563-2B89345508AA@checkpoint.com> <20080513140202.GZ13552@Sun.COM> <791AFD5C-86BA-4B3F-B6D3-6DDF7CF6C08C@checkpoint.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <791AFD5C-86BA-4B3F-B6D3-6DDF7CF6C08C@checkpoint.com> User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org, Richard Barnes , Dan McDonald Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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, May 13, 2008 at 10:33:52PM +0300, Yoav Nir wrote: > On May 13, 2008, at 5:02 PM, Nicolas Williams wrote: > > > >FWIW, in the several years that I have been using an IPsec-based VPN > >I've not have had any trouble with hotel or coffee shop wifi filtering > >out IPsec. > > I've never had that in coffee shops, but I have had that in hotels and > airports, mostly in Europe. You usually find this kind of mandatory > proxy where they want to charge you for using the Wifi. Well, yes, but if there's any way to get VPN to work without paying then presumably that's a bug in the hotel/airport/whatever wifi. So this is a non-issue for IPsec. > >OTOH, in the several years before that when I used an IPsec-VPN-over- > >TCP solution I had many problems where bits would stop moving. I > >don't know if that was a function of flow control issues (hmmm, TCP > >over TCP...), lousy client software, or what. But I do know that I > >never have such issues now with straight IPsec. > > TCP over TCP is fun, and an experiment showed that two TCPs over the > same TCP is even more fun. UDP over TCP is also fun (think VoIP going > silent until that lost packet/segment gets retransmitted). But still, > when nothing else works, it lets you read your mail. Again, if this is about getting VPN to work on non-free access points, well, I have no sympathy (sure, I want free access too, but I don't think resorting to VPN over TCP is the right answer here). > >All that said, I do find it might odd that there isn't an option for > >running IKE over TCP/SCTP. > > IKE-over-TCP works well, and allows for sending certificates and CRLs But really, we should all be using OCSP instead of CRLs... > within Main Mode / Authentication exchange. It also allows large > proposals in IKEv1 and large config payloads in IKEv2. When I proposed > to write a draft about it, it was shot down because IKE is message- > oriented while TCP is stream. SCTP sounds better, but the packet > filters would balk, and also it's harder to implement because > operating systems don't have native support. I think the "IKE is message-oriented while TCP is stream" argument is bunk. There's no reason that enough framing can't be provided to make it work. We (the IETF) have lots of experience running message-oriented protocols over TCP (DNS, NFS, LDAP, HTTP/1.1, SSHv2, TLS, ...); one might even say that most protocols that run over TCP are message oriented. Sure, SCTP is here now and all that, but, so what? If middle boxes make SCTP deployment harder then we should make SCTP MUST- implement and TCP SHOULD-implement. One good reason for supporting IKE over TCP is that NAT boxes are much nicer with TCP than UDP traffic, mostly because they can maintain connection state more accurately for longer due to TCP's connection oriented nature. In short: I don't buy the arguments for VPN-over-TCP (if nothing else the second order flow-control issues are a big deal), but I agree that IKE should support running over TCP. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 14:53: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 4A4603A68BF; Tue, 13 May 2008 14:53: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 2AF253A6954 for ; Tue, 13 May 2008 14:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_STATIC=1.172, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyprMTdp4VpM for ; Tue, 13 May 2008 14:53:31 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id 6B13A3A685D for ; Tue, 13 May 2008 14:53:31 -0700 (PDT) Received: from ywu (69-229-94-147.ded.pacbell.net [69.229.94.147]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m4DLrHOu019608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 13 May 2008 16:53:19 -0500 From: "Yingzhe Wu" To: References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Date: Tue, 13 May 2008 14:52:29 -0700 Message-ID: <005701c8b543$b4c932a0$1e5b97e0$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciwK8m/mwKUTwCXTrqgl2KHAdRjBwFFoIXA Content-Language: en-us Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 Hello Pasi, Here is my ordered list: [ECR] o Setting up GRE tunnels with IKE (possible starting point: draft-wu-l3vpn-ipsec-gre-00) [ECR] o Using GRE "key" header field as IPsec traffic selector (possible starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) [R] o Update to IKEv2 base specification (possible starting point: draft-hoffman-ikev2bis) [R] o Better IPv6 configuration payloads (possible starting point: draft-eronen-ipsec-ikev2-ipv6-config) thanks, Yingzhe _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 17:20:03 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 E8D6D3A6953; Tue, 13 May 2008 17:20: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 752723A6953 for ; Tue, 13 May 2008 17:19:57 -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 dY3jCba4qb7c for ; Tue, 13 May 2008 17:19:56 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 2D4F93A6975 for ; Tue, 13 May 2008 17:19:56 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 528EE294002; Tue, 13 May 2008 22:33:55 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 76E05294001; Tue, 13 May 2008 22:33:54 +0300 (IDT) Received: from [172.31.24.139] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m4DJXqfU013316; Tue, 13 May 2008 22:33:53 +0300 (IDT) Message-Id: <791AFD5C-86BA-4B3F-B6D3-6DDF7CF6C08C@checkpoint.com> From: Yoav Nir To: Nicolas Williams In-Reply-To: <20080513140202.GZ13552@Sun.COM> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 13 May 2008 22:33:52 +0300 References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080508205315.GD2207@sun.com> <48298261.3080700@bbn.com> <4E0A1558-D20D-49E2-9563-2B89345508AA@checkpoint.com> <20080513140202.GZ13552@Sun.COM> X-Mailer: Apple Mail (2.919.2) Cc: ipsec@ietf.org, Richard Barnes , Dan McDonald Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 May 13, 2008, at 5:02 PM, Nicolas Williams wrote: > > FWIW, in the several years that I have been using an IPsec-based VPN > I've not have had any trouble with hotel or coffee shop wifi filtering > out IPsec. I've never had that in coffee shops, but I have had that in hotels and airports, mostly in Europe. You usually find this kind of mandatory proxy where they want to charge you for using the Wifi. > > OTOH, in the several years before that when I used an IPsec-VPN-over- > TCP > solution I had many problems where bits would stop moving. I don't > know > if that was a function of flow control issues (hmmm, TCP over TCP...), > lousy client software, or what. But I do know that I never have such > issues now with straight IPsec. TCP over TCP is fun, and an experiment showed that two TCPs over the same TCP is even more fun. UDP over TCP is also fun (think VoIP going silent until that lost packet/segment gets retransmitted). But still, when nothing else works, it lets you read your mail. > I have had some strange road warrior problems with _IP_ though. The > most interesting one being a hotel wifi network whose DHCP server > handed > out addresses with a /32 netmask: my Solaris laptop then would then > reject the default route from the DHCP server since the router wasn't > on-link (going by the netmask) and there was no other route to it. I > was able to make this work (and once it did so did IPsec, of course). > > All that said, I do find it might odd that there isn't an option for > running IKE over TCP/SCTP. IKE-over-TCP works well, and allows for sending certificates and CRLs within Main Mode / Authentication exchange. It also allows large proposals in IKEv1 and large config payloads in IKEv2. When I proposed to write a draft about it, it was shot down because IKE is message- oriented while TCP is stream. SCTP sounds better, but the packet filters would balk, and also it's harder to implement because operating systems don't have native support. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 13 23:56: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 B7D6C3A6A10; Tue, 13 May 2008 23:56: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 782433A6A10 for ; Tue, 13 May 2008 23:56: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 o8zePJc+HIYL for ; Tue, 13 May 2008 23:56:29 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 2DFB23A6A0A for ; Tue, 13 May 2008 23:56:29 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A8CEB294002; Wed, 14 May 2008 09:38:32 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id AC5AA294001; Wed, 14 May 2008 09:37:27 +0300 (IDT) Received: from MBP.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m4E6bRfU011648; Wed, 14 May 2008 09:37:27 +0300 (IDT) Message-Id: From: Yoav Nir To: Nicolas Williams In-Reply-To: <20080513194521.GK13552@Sun.COM> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 14 May 2008 09:37:26 +0300 References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080508205315.GD2207@sun.com> <48298261.3080700@bbn.com> <4E0A1558-D20D-49E2-9563-2B89345508AA@checkpoint.com> <20080513140202.GZ13552@Sun.COM> <791AFD5C-86BA-4B3F-B6D3-6DDF7CF6C08C@checkpoint.com> <20080513194521.GK13552@Sun.COM> X-Mailer: Apple Mail (2.919.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 May 13, 2008, at 10:45 PM, Nicolas Williams wrote: > On Tue, May 13, 2008 at 10:33:52PM +0300, Yoav Nir wrote: >> On May 13, 2008, at 5:02 PM, Nicolas Williams wrote: >>> >>> FWIW, in the several years that I have been using an IPsec-based VPN >>> I've not have had any trouble with hotel or coffee shop wifi >>> filtering >>> out IPsec. >> >> I've never had that in coffee shops, but I have had that in hotels >> and >> airports, mostly in Europe. You usually find this kind of mandatory >> proxy where they want to charge you for using the Wifi. > > Well, yes, but if there's any way to get VPN to work without paying > then > presumably that's a bug in the hotel/airport/whatever wifi. So this > is > a non-issue for IPsec. The issue is not to avoid paying. The airport has an HTTP/HTTPS proxy and the wifi has a policy that says: - Allow DNS - Allow port 80 to the proxy - Allow port 443 to the proxy - Drop everything else The proxy is needed, so that the first time you try to access anything it redirects you to the billing page. Once you've paid, you still can't get anything out unless it's through the proxy, so what the VPN client does, is route IKE and IPsec over a TCP connection that looks like HTTPS and goes through the proxy. It's tough to get straight IPsec to run through an HTTP proxy. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 14 02:33: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 DBC4D3A67D8; Wed, 14 May 2008 02:33: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 8BC4A3A67D8 for ; Wed, 14 May 2008 02:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.973 X-Spam-Level: X-Spam-Status: No, score=-5.973 tagged_above=-999 required=5 tests=[AWL=0.626, 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 l4B4rN3Q4o4Y for ; Wed, 14 May 2008 02:33:29 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 7E6C13A67A2 for ; Wed, 14 May 2008 02:33:29 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4E9VdZx003783 for ; Wed, 14 May 2008 12:31:52 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 12:31:40 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 12:31:40 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 12:31:39 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB729CB352@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IPsec maintenance/extensions WG, summary so far Thread-index: AciwK8m/mwKUTwCXTrqgl2KHAdRjBwFeOdBQ References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> From: To: X-OriginalArrivalTime: 14 May 2008 09:31:40.0558 (UTC) FILETIME=[508B0AE0:01C8B5A5] X-Nokia-AV: Clean Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 My own list (not wearing any hats): [CR] Update to IKEv2 base specification [ECR] Better IPv6 configuration payloads [CR] IPsec document roadmap update [CR] IKEv2 session resumption [R] Redirecting a VPN client from one gateway to another [R] Running IPsec over TCP [R] Using AEAD algorithms in IKEv2 Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 14 03:32: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 AA63D3A6855; Wed, 14 May 2008 03:32: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 A90873A6855 for ; Wed, 14 May 2008 03:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.003 X-Spam-Level: X-Spam-Status: No, score=-6.003 tagged_above=-999 required=5 tests=[AWL=0.596, 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 AIjRMcopGFYY for ; Wed, 14 May 2008 03:32:26 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id F205F3A67A2 for ; Wed, 14 May 2008 03:32:21 -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 m4EAUOKl004727; Wed, 14 May 2008 13:30:24 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 13:30:23 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 13:30:22 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 13:30:22 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB729CB46B@vaebe104.NOE.Nokia.com> In-Reply-To: <20080507192010.GL13552@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IPsec maintenance/extensions WG, summary so far Thread-index: Aciwd2IiUJAOK+7fR3u+p/3b2E84cAFMg/ZA References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080507192010.GL13552@Sun.COM> From: To: X-OriginalArrivalTime: 14 May 2008 10:30:22.0581 (UTC) FILETIME=[83D51A50:01C8B5AD] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 Nicolas Williams wrote: > I think this item: > > > o GSS-API (or Kerberos) authentication for IKEv2 > > seems unnecessary. Keep in mind that I once thought the > opposite. But let's consider: > > - IPsec w/ Kerberos V -> KINK > - IPsec w/ PSK, PKI, EAP -> IKEv2 > > So what existing, planned or potential GSS-API mechanisms might one > want to use with IPsec which isn't covered via KINK or IKEv2? > > Now, perhaps there is dissatisfaction with KINK. Or perhaps there's > a desire to mix Kerberos V and whatnot in one KE. If so, let's hear > it. If not, let's drop this. One potential reason I can think of is desire to use various IKEv2 features, either current (IP address configuration, MOBIKE) or proposed (AEAD ciphers, session resumption, gateway redirect, quick crash detection, etc.) with Kerberos authentication. (Adding these features to KINK would be a big effort.) Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 14 03:32:51 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 159553A6927; Wed, 14 May 2008 03:32:51 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522343A6927 for ; Wed, 14 May 2008 03:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.03 X-Spam-Level: X-Spam-Status: No, score=-6.03 tagged_above=-999 required=5 tests=[AWL=0.569, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86u1l35Tn1ax for ; Wed, 14 May 2008 03:32:48 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 6EF8F3A682A for ; Wed, 14 May 2008 03:32:47 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4EAUV95000557; Wed, 14 May 2008 13:30:58 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 13:30:23 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 13:30:22 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 13:30:22 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB729CB46A@vaebe104.NOE.Nokia.com> In-Reply-To: <30C65F3A3407B943826897E025135BE60120266A89D8@DF-GRTDANE-MSG.exchange.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPsec maintenance/extensions WG, summary so far Thread-index: AciwK8m/mwKUTwCXTrqgl2KHAdRjBwAQHWWQAU8IraA= References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <30C65F3A3407B943826897E025135BE60120266A89D8@DF-GRTDANE-MSG.exchange.corp.microsoft.com> From: To: , X-OriginalArrivalTime: 14 May 2008 10:30:22.0810 (UTC) FILETIME=[83F80BA0:01C8B5AD] X-Nokia-AV: Clean Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 Charlie Kaufman wrote: > While a tightly scoped charter is always a good idea, I don't think > we should send the message that "this is the last train for five > years... if you think you're going to want anything in IPsec ever, > lobby to get it into the charter now or forever hold your peace." We > should start with the highest priority non-controversial and mostly > completed items with the expectations that there will be time at > meetings to present proposals for less-well-known extensions and > have a decision made then as to whether to accept them as working > group items, suggest they be the basis of a new working group, > suggest they be individual submissions, or suggest they go away. My intention was not to say that this is the last train for five years, or anything like that -- certainly *after* the initial work items are completed, new work and rechartering can be considered. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 14 03:32: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 8A8163A6940; Wed, 14 May 2008 03:32: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 2D0313A6940 for ; Wed, 14 May 2008 03:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.054 X-Spam-Level: X-Spam-Status: No, score=-6.054 tagged_above=-999 required=5 tests=[AWL=0.545, 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 n9dwYqwmA7YX for ; Wed, 14 May 2008 03:32:56 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 0B4CC3A693B for ; Wed, 14 May 2008 03:32:54 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4EAUNqx021727; Wed, 14 May 2008 05:30:58 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 13:30:23 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 13:30:22 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 13:30:21 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB729CB469@vaebe104.NOE.Nokia.com> In-Reply-To: <873aouxsad.fsf@natisbad.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IPsec maintenance/extensions WG, summary so far Thread-index: AciwNkN0VVbnc/wKR1KcHif45/rpiQFcU9PQ References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <873aouxsad.fsf@natisbad.org> From: To: X-OriginalArrivalTime: 14 May 2008 10:30:22.0591 (UTC) FILETIME=[83D6A0F0:01C8B5AD] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 Arnaud Ebalard wrote: > Sorry for joigning the discussion a little bit late. I should have > posted to make a proposal for some work on MIPv6/IPsec/IKE > interactions as WG items before. > > The IPsec-related elements you cite in your P.S. for MEXT were *not* > taken as Working Group items during the recent recharter (decision > of the chairs) even if there were people interested by working on > it. Some other functionalities have been preferred. > > At the moment, even if MIPv6 specification expects interactions > between IPsec stack and MIPv6 module for IPSec to survive movement, > no interface is defined. The 2 proposals I am aware of on that > topic: > > - draft-sugimoto-mip6-pfkey-migrate-04 > - draft-qi-mip6-ikev2-interfacing-01 > > are still now simple external documents. > > IMO, the main issue here is that the topic crosses different WG or > is related to different subjects (IPsec, MIPv6, IKE, PF_KEY). As you > wrote for the IPsec WG "the intent is *not* to collect all > IPsec-related work to one WG". > > What is happening in practice is that IPsec and MIPv6 will be > *separately* added new features (probably useful in a sense) but > will not or badly work together. > > Where should associated efforts and discussions be handled? When I mentioned Mobile IP specific extensions to IPsec, I meant things like RFC 5026. As I wrote in my email, I think PF_KEY work does not fit within the scope of the possible WG charter (at least not now). Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 14 03:33: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 1BE0C3A6968; Wed, 14 May 2008 03:33: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 031393A6968 for ; Wed, 14 May 2008 03:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.077 X-Spam-Level: X-Spam-Status: No, score=-6.077 tagged_above=-999 required=5 tests=[AWL=0.522, 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 9Db+2sgr6zMD for ; Wed, 14 May 2008 03:33:38 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 061E23A67A2 for ; Wed, 14 May 2008 03:33:34 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4EASr4F020082; Wed, 14 May 2008 05:30:59 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 13:30:24 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 13:30:23 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 13:29:26 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB729CB470@vaebe104.NOE.Nokia.com> In-Reply-To: <791AFD5C-86BA-4B3F-B6D3-6DDF7CF6C08C@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IPsec maintenance/extensions WG, summary so far Thread-index: Aci1WFGePRt+5JlwRve75m/1U/sfcgAVBo4Q References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com><20080508205315.GD2207@sun.com><48298261.3080700@bbn.com><4E0A1558-D20D-49E2-9563-2B89345508AA@checkpoint.com><20080513140202.GZ13552@Sun.COM> <791AFD5C-86BA-4B3F-B6D3-6DDF7CF6C08C@checkpoint.com> From: To: X-OriginalArrivalTime: 14 May 2008 10:30:23.0880 (UTC) FILETIME=[849B5080:01C8B5AD] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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: > TCP over TCP is fun, and an experiment showed that two TCPs over the > same TCP is even more fun. UDP over TCP is also fun (think VoIP > going silent until that lost packet/segment gets retransmitted). > But still, when nothing else works, it lets you read your mail. The behavior of VoIP-over-TCP vs. TCP-over-TCP can actually be quite different: the VoIP application doesn't increase its sending rate until it gets packet loss. Here's an article that tested VoIP with various SSL VPN products, and found that it actually works quite OK with packet loss rates you'd usually expect to see: http://www.networkworld.com/reviews/2006/022006-ssl-voip-test.html Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 14 03:33: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 7F7BB3A69A2; Wed, 14 May 2008 03:33: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 AF9D53A67A2 for ; Wed, 14 May 2008 03:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-1.499, 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 CQdyy5a9XJzy for ; Wed, 14 May 2008 03:33:39 -0700 (PDT) Received: from mgw-fb01.nokia.com (mgw-fb01.nokia.com [192.100.122.235]) by core3.amsl.com (Postfix) with ESMTP id 9DED43A6955 for ; Wed, 14 May 2008 03:33:37 -0700 (PDT) Received: from mgw-mx03.nokia.com (mgw-mx03.nokia.com [192.100.122.230]) by mgw-fb01.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4EAWdpN015702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 14 May 2008 13:32:40 +0300 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4EAUXOj004804; Wed, 14 May 2008 13:30:38 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 13:30:25 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 May 2008 13:30:25 +0300 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 14 May 2008 13:30:22 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB729CB46E@vaebe104.NOE.Nokia.com> In-Reply-To: <48298261.3080700@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IPsec maintenance/extensions WG, summary so far Thread-index: Aci08OKhx3Ns8cuOQSKZhKq80PCa/gAucoxQ References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080508205315.GD2207@sun.com> <48298261.3080700@bbn.com> From: "Pasi.Eronen@nokia.com" To: , X-OriginalArrivalTime: 14 May 2008 10:30:25.0193 (UTC) FILETIME=[8563A990:01C8B5AD] X-Nokia-AV: Clean Cc: ipsec@ietf.org, danmcd@sun.com Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 Richard Barnes wrote: > > So have others. Sometimes I think this is the whole point > > of so-called "SSL VPN" > > This can also be done using RFC 3093. Well, I doubt that Mark and Scott thought back in April 1st, 2001 that people would actually ship products implementing that one. But today, VPN products *do* implement something that's very similar to RFC 3093, and this does provide value to some users. The question isn't anymore whether the joke was funny or not, but whether we care about interoperability of these products... Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 14 06:46: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 2472D3A6938; Wed, 14 May 2008 06:46: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 347A13A6837 for ; Wed, 14 May 2008 06:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 XVOZhy0-jZXQ for ; Wed, 14 May 2008 06:46:30 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 2D0403A67F7 for ; Wed, 14 May 2008 06:46:30 -0700 (PDT) Received: from [128.89.252.50] (helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JwGby-0006Nf-5G; Wed, 14 May 2008 09:01:38 -0400 Message-ID: <482AE2B0.1050508@bbn.com> Date: Wed, 14 May 2008 09:01:36 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Yoav Nir References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080508205315.GD2207@sun.com> <48298261.3080700@bbn.com> <4E0A1558-D20D-49E2-9563-2B89345508AA@checkpoint.com> <20080513140202.GZ13552@Sun.COM> <791AFD5C-86BA-4B3F-B6D3-6DDF7CF6C08C@checkpoint.com> <20080513194521.GK13552@Sun.COM> In-Reply-To: Cc: ipsec@ietf.org, Nicolas Williams Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 So your real goal is still to circumvent the provider's policy; this is the same use case that RFC 3093 addresses for TCP. (Note that poorly-designed equipment is indistinguishable from poorly-chosen policy.) While I appreciate that you want to be able to connect securely, these networks don't allow it; the solution is simply to use networks that allow IPsec, not to hack IPsec to run over whatever pinhole is available. Note also that if you're running something non-HTTP through port 80 or 443, the proxy can see that through deep packet inspection and deny it (I have no doubt that firewall vendors would sell this as a feature), so there's no real net gain to running IPsec over 80/443 anyway. But the DNS port is still open, and allowed to go to any host on the Internet, not just to a proxy. Maybe we could run IPsec over that? --RLB Yoav Nir wrote: > On May 13, 2008, at 10:45 PM, Nicolas Williams wrote: > >> On Tue, May 13, 2008 at 10:33:52PM +0300, Yoav Nir wrote: >>> On May 13, 2008, at 5:02 PM, Nicolas Williams wrote: >>>> FWIW, in the several years that I have been using an IPsec-based VPN >>>> I've not have had any trouble with hotel or coffee shop wifi >>>> filtering >>>> out IPsec. >>> I've never had that in coffee shops, but I have had that in hotels >>> and >>> airports, mostly in Europe. You usually find this kind of mandatory >>> proxy where they want to charge you for using the Wifi. >> Well, yes, but if there's any way to get VPN to work without paying >> then >> presumably that's a bug in the hotel/airport/whatever wifi. So this >> is >> a non-issue for IPsec. > > The issue is not to avoid paying. The airport has an HTTP/HTTPS proxy > and the wifi has a policy that says: > - Allow DNS > - Allow port 80 to the proxy > - Allow port 443 to the proxy > - Drop everything else > > The proxy is needed, so that the first time you try to access anything > it redirects you to the billing page. Once you've paid, you still > can't get anything out unless it's through the proxy, so what the VPN > client does, is route IKE and IPsec over a TCP connection that looks > like HTTPS and goes through the proxy. It's tough to get straight > IPsec to run through an HTTP proxy. > > _______________________________________________ > 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 May 14 06:48: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 ABED53A68F4; Wed, 14 May 2008 06:48: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 940153A68F4 for ; Wed, 14 May 2008 06:48:29 -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 Dwwt48QStYhL for ; Wed, 14 May 2008 06:48:28 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 64BC93A68BB for ; Wed, 14 May 2008 06:48:28 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1A1B3294002; Wed, 14 May 2008 16:47:37 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 39239294001; Wed, 14 May 2008 16:47:36 +0300 (IDT) Received: from MBP.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m4EDlZfU017886; Wed, 14 May 2008 16:47:35 +0300 (IDT) Message-Id: <2BC8721C-B50F-4D06-A093-CDBC16CF7432@checkpoint.com> From: Yoav Nir To: Richard Barnes In-Reply-To: <482AE2B0.1050508@bbn.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 14 May 2008 16:47:35 +0300 References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080508205315.GD2207@sun.com> <48298261.3080700@bbn.com> <4E0A1558-D20D-49E2-9563-2B89345508AA@checkpoint.com> <20080513140202.GZ13552@Sun.COM> <791AFD5C-86BA-4B3F-B6D3-6DDF7CF6C08C@checkpoint.com> <20080513194521.GK13552@Sun.COM> <482AE2B0.1050508@bbn.com> X-Mailer: Apple Mail (2.919.2) Cc: ipsec@ietf.org, Nicolas Williams Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 May 14, 2008, at 4:01 PM, Richard Barnes wrote: > So your real goal is still to circumvent the provider's policy; this > is the same use case that RFC 3093 addresses for TCP. (Note that > poorly-designed equipment is indistinguishable from poorly-chosen > policy.) While I appreciate that you want to be able to connect > securely, these networks don't allow it; the solution is simply to > use networks that allow IPsec, not to hack IPsec to run over > whatever pinhole is available. Their policy is that everyone pays and everything except DNS goes through the proxy. We don't circumvent either of these "rules". In a corporate setting, where the rules are actually there to prevent stuff they can't inspect, it really is circumventing the policy. > > Note also that if you're running something non-HTTP through port 80 > or 443, the proxy can see that through deep packet inspection and > deny it (I have no doubt that firewall vendors would sell this as a > feature), so there's no real net gain to running IPsec over 80/443 > anyway. Of course firewall vendors sell this as a feature. There's a whole arms race around this: - first things like IPsec clients and Skype went over port 80, but the firewalls learned to spot this irregular HTTP. - Then they went over port 443, because firewalls don't try to decipher SSL, but the firewalls learned to stop connections with an invalid Client Hello - Some (like Skype) returned to port 80, but made their connection look like real HTTP (That's pretty much what you have in RFC 3093) - Others made a better effort with port 443, and sent regular TLS handshakes, but then they didn't need IPsec anymore, and SSL VPN was born. > But the DNS port is still open, and allowed to go to any host on the > Internet, not just to a proxy. Maybe we could run IPsec over that? I actually saw this demonstrated by some hacker. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 15 09:24: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 CEB913A6888; Thu, 15 May 2008 09:24: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 9478F3A6888 for ; Thu, 15 May 2008 09:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6S7zaX4IG9r for ; Thu, 15 May 2008 09:24:54 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id 39D663A67F5 for ; Thu, 15 May 2008 09:24:50 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so337890tib.25 for ; Thu, 15 May 2008 09:23:35 -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=DCAaVhMoodfQhbVDL1rxDmnmAKSNoqF20V12zNWcYdo=; b=RjA5exhuJI0/QeTBUW/94wWKY6/PZxmuyIpdxQW0NXtylv6q6AcJSQ0blLhpJHc7RDe+zA/O3QD7A1eyrNmVguJsKsBQtjp9hTPISjmx2MsVApCAq6IMf6XFV0j9FqK/mJdy/VXdQK6kLiS78FBAA8FtZo1G9CjOiYeCmxHEPvg= 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=I4lZFdS8vEpaOUAv0i6OiheZFt9+gPDOgLj9CkbjogthIx0kfsGz4jEpF1nsxixy3hx50RPDJeCl7+PUI+IWBLw0Hn1mT4mMrDZSYRn5aMayd079w5RF23wtcU38RmkuKYQ0DFtrobUaz2oT67JLoV2G+5raYPP0hkmft3LcPw0= Received: by 10.110.70.5 with SMTP id s5mr337571tia.27.1210868229792; Thu, 15 May 2008 09:17:09 -0700 (PDT) Received: by 10.110.93.4 with HTTP; Thu, 15 May 2008 09:17:09 -0700 (PDT) Message-ID: <1d38a3350805150917y507f0194u20f636f04e3a82fc@mail.gmail.com> Date: Fri, 16 May 2008 00:17:09 +0800 From: "Hui Deng" To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB729CB469@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <873aouxsad.fsf@natisbad.org> <1696498986EFEC4D9153717DA325CB729CB469@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, mext@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 thanks Pasi's elaboration, see inline with ==> Please allow me to cc MEXT, 2008/5/14 : > Arnaud Ebalard wrote: > >> Sorry for joigning the discussion a little bit late. I should have >> posted to make a proposal for some work on MIPv6/IPsec/IKE >> interactions as WG items before. >> >> The IPsec-related elements you cite in your P.S. for MEXT were *not* >> taken as Working Group items during the recent recharter (decision >> of the chairs) even if there were people interested by working on >> it. Some other functionalities have been preferred. >> >> At the moment, even if MIPv6 specification expects interactions >> between IPsec stack and MIPv6 module for IPSec to survive movement, >> no interface is defined. The 2 proposals I am aware of on that >> topic: >> >> - draft-sugimoto-mip6-pfkey-migrate-04 >> - draft-qi-mip6-ikev2-interfacing-01 >> >> are still now simple external documents. >> >> IMO, the main issue here is that the topic crosses different WG or >> is related to different subjects (IPsec, MIPv6, IKE, PF_KEY). As you >> wrote for the IPsec WG "the intent is *not* to collect all >> IPsec-related work to one WG". >> >> What is happening in practice is that IPsec and MIPv6 will be >> *separately* added new features (probably useful in a sense) but >> will not or badly work together. >> >> Where should associated efforts and discussions be handled? > > When I mentioned Mobile IP specific extensions to IPsec, I meant > things like RFC 5026. ==> So here you mean that it will be in the scope of Mobile IP WG? after that, it need Security review for this kind of work? thanks -Hui > > As I wrote in my email, I think PF_KEY work does not fit within > the scope of the possible WG charter (at least not now). > > Best regards, > Pasi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 15 10:09: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 907103A6804; Thu, 15 May 2008 10:09: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 1C1B33A6804 for ; Thu, 15 May 2008 10:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97g9Vrxbx84r for ; Thu, 15 May 2008 10:09:02 -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 D83953A67B6 for ; Thu, 15 May 2008 10:07:03 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4FH6EE2022895 for ; Thu, 15 May 2008 17:06:14 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m4FH6EAo046277 for ; Thu, 15 May 2008 11:06:14 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m4FH6EtA027057; Thu, 15 May 2008 12:06:14 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m4FH6Ega027056; Thu, 15 May 2008 12:06:14 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 15 May 2008 12:06:14 -0500 From: Nicolas Williams To: Pasi.Eronen@nokia.com Message-ID: <20080515170613.GQ26388@Sun.COM> Mail-Followup-To: Pasi.Eronen@nokia.com, ipsec@ietf.org References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080507192010.GL13552@Sun.COM> <1696498986EFEC4D9153717DA325CB729CB46B@vaebe104.NOE.Nokia.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <1696498986EFEC4D9153717DA325CB729CB46B@vaebe104.NOE.Nokia.com> User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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, May 14, 2008 at 01:30:22PM +0300, Pasi.Eronen@nokia.com wrote: > Nicolas Williams wrote: > > I think this item: > > > > > o GSS-API (or Kerberos) authentication for IKEv2 > > > > seems unnecessary. Keep in mind that I once thought the > > opposite. But let's consider: > > One potential reason I can think of is desire to use various IKEv2 > features, either current (IP address configuration, MOBIKE) or > proposed (AEAD ciphers, session resumption, gateway redirect, > quick crash detection, etc.) with Kerberos authentication. > > (Adding these features to KINK would be a big effort.) Ah, good point. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 15 10:32: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 B6EA33A684E; Thu, 15 May 2008 10:32: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 B9F1F3A684E for ; Thu, 15 May 2008 10:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.046 X-Spam-Level: X-Spam-Status: No, score=-3.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6h+AmXC8yFz for ; Thu, 15 May 2008 10:32:39 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id D62893A6804 for ; Thu, 15 May 2008 10:32:38 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4FH8AAu029047 for ; Thu, 15 May 2008 17:08:10 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m4FH892X047627 for ; Thu, 15 May 2008 11:08:09 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m4FH89SD027064; Thu, 15 May 2008 12:08:09 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m4FH89Ft027063; Thu, 15 May 2008 12:08:09 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 15 May 2008 12:08:09 -0500 From: Nicolas Williams To: Yoav Nir Message-ID: <20080515170809.GR26388@Sun.COM> Mail-Followup-To: Yoav Nir , ipsec@ietf.org References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <20080508205315.GD2207@sun.com> <48298261.3080700@bbn.com> <4E0A1558-D20D-49E2-9563-2B89345508AA@checkpoint.com> <20080513140202.GZ13552@Sun.COM> <791AFD5C-86BA-4B3F-B6D3-6DDF7CF6C08C@checkpoint.com> <20080513194521.GK13552@Sun.COM> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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, May 14, 2008 at 09:37:26AM +0300, Yoav Nir wrote: > The issue is not to avoid paying. The airport has an HTTP/HTTPS proxy > and the wifi has a policy that says: > - Allow DNS > - Allow port 80 to the proxy > - Allow port 443 to the proxy > - Drop everything else > > The proxy is needed, so that the first time you try to access anything > it redirects you to the billing page. Once you've paid, you still > can't get anything out unless it's through the proxy, so what the VPN > client does, is route IKE and IPsec over a TCP connection that looks > like HTTPS and goes through the proxy. It's tough to get straight > IPsec to run through an HTTP proxy. I've never had this problem. To be fair I never use airport wifi. But I've used plenty of hotel and coffee shop wifis and never, ever ran into this. (Before paying or clicking through the registration page, of course, IPsec bits don't move, but afterwards they do.) Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 15 11:19: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 E13143A69FB; Thu, 15 May 2008 11:19: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 2AC893A6972 for ; Thu, 15 May 2008 11:19:11 -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 UY7ETT2AMrCn for ; Thu, 15 May 2008 11:19:10 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.233]) by core3.amsl.com (Postfix) with ESMTP id E25613A6A1D for ; Thu, 15 May 2008 11:18:14 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so525530rvf.49 for ; Thu, 15 May 2008 11:18:09 -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=2CMVTYBXXqGwQTPVBMcOyU7loEPG7CjUvtCLAK10WAc=; b=hQpHbzMKV3IFCzSRbcONW/yGRHHy43b0DmUAd3B4FdGm1JntLwnBDnlLr/1KrjN8Qdx95LCFCbJPSsK00XYX6p5hpiml7Qanu82W7t0iY7gnrqKcnHlv3ExTnNSg9wBc6g1qvi6gM/PGVJYq6MqwuGuxKLJz1CvcgJht33UVt8s= 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=xhGZWJoudp5Wu8025JsaFbpDCoWpuAqQlqxhUtm6YhQNr34rOukCqcN9gFaanlsHHTpRJc0xUhYut3CFEShW1RdgI3R0qJ3m1EJQSnlT7MKR6vleDeoErk30v9ekqGXjcz6mFoW+NdjBOV2m+XDadZIOa0uQSmsp0gAbPydPZig= Received: by 10.141.88.3 with SMTP id q3mr1270847rvl.94.1210875489701; Thu, 15 May 2008 11:18:09 -0700 (PDT) Received: by 10.141.19.5 with HTTP; Thu, 15 May 2008 11:18:09 -0700 (PDT) Message-ID: <729b68be0805151118t5480841ay697ebd4f8c19faef@mail.gmail.com> Date: Thu, 15 May 2008 20:18:09 +0200 From: "Jean-Michel Combes" To: "Pasi.Eronen@nokia.com" In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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, 2008/5/7, Pasi.Eronen@nokia.com : [R] o IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) By the way, what do you mean by a "same peer/cluster of peers"? Same administrative domain? Security gateways from a same constructor? [R] o Redirecting a VPN client from one gateway to another (in a cluster of gateways) [R] o Authentication with Cryptographically Generated Addresses (CGA) (possible starting point: draft-laganier-ike-ipv6-cga) [R] o Better IPv6 configuration payloads (possible starting point: draft-eronen-ipsec-ikev2-ipv6-config) Best regards. JMC. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 15 13:00: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 D72093A680A; Thu, 15 May 2008 13:00: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 B35FA3A68D9; Thu, 15 May 2008 13:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.061 X-Spam-Level: X-Spam-Status: No, score=-6.061 tagged_above=-999 required=5 tests=[AWL=0.538, 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 9G1Z8gp1FZl5; Thu, 15 May 2008 13:00:22 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 9B32C3A67FB; Thu, 15 May 2008 13:00:21 -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 m4FK0762017170; Thu, 15 May 2008 23:00:12 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 May 2008 23:00:11 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 May 2008 23:00:10 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 May 2008 23:00:10 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72A13653@vaebe104.NOE.Nokia.com> In-Reply-To: <1d38a3350805150917y507f0194u20f636f04e3a82fc@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] IPsec maintenance/extensions WG, summary so far Thread-Index: Aci2py1E5qlFgPFNTAW5RIzgqvYfLgAHeLTg References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <873aouxsad.fsf@natisbad.org> <1696498986EFEC4D9153717DA325CB729CB469@vaebe104.NOE.Nokia.com> <1d38a3350805150917y507f0194u20f636f04e3a82fc@mail.gmail.com> From: To: X-OriginalArrivalTime: 15 May 2008 20:00:10.0810 (UTC) FILETIME=[480499A0:01C8B6C6] X-Nokia-AV: Clean Cc: ipsec@ietf.org, mext@ietf.org Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 wrote: > >> Sorry for joigning the discussion a little bit late. I should have > >> posted to make a proposal for some work on MIPv6/IPsec/IKE > >> interactions as WG items before. > >> > >> The IPsec-related elements you cite in your P.S. for MEXT were > >> *not* taken as Working Group items during the recent recharter > >> (decision of the chairs) even if there were people interested by > >> working on it. Some other functionalities have been preferred. > >> > >> At the moment, even if MIPv6 specification expects interactions > >> between IPsec stack and MIPv6 module for IPSec to survive movement, > >> no interface is defined. The 2 proposals I am aware of on that > >> topic: > >> > >> - draft-sugimoto-mip6-pfkey-migrate-04 > >> - draft-qi-mip6-ikev2-interfacing-01 > >> > >> are still now simple external documents. > >> > >> IMO, the main issue here is that the topic crosses different WG or > >> is related to different subjects (IPsec, MIPv6, IKE, > >> PF_KEY). As you wrote for the IPsec WG "the intent is *not* to > >> collect all IPsec-related work to one WG". > >> > >> What is happening in practice is that IPsec and MIPv6 will be > >> *separately* added new features (probably useful in a sense) but > >> will not or badly work together. > >> > >> Where should associated efforts and discussions be handled? > > > > When I mentioned Mobile IP specific extensions to IPsec, I meant > > things like RFC 5026. > > ==> So here you mean that it will be in the scope of Mobile IP WG? > after that, it need Security review for this kind of work? I'm not taking any opinion on whether these drafts should be in the scope of MEXT WG or not. (But as I said earlier, nothing in the IPsec maintenance/extensions WG discussion is intended to prevent other WGs from working on IPsec-related topics, if they choose to do so.) Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 15 14:50: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 AECE728C0FC; Thu, 15 May 2008 14:50: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 498DE3A6921 for ; Thu, 15 May 2008 14:50: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 1Lkuq9UQfBdo for ; Thu, 15 May 2008 14:50:27 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.232]) by core3.amsl.com (Postfix) with ESMTP id 11EE13A6872 for ; Thu, 15 May 2008 14:50:26 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 50so331622wra.13 for ; Thu, 15 May 2008 14:50:21 -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:mime-version:content-type:content-transfer-encoding:content-disposition; bh=hvirITz9SPErrWgkpt7zy190dypx7dlOZ7J2P6geAic=; b=Q/S2429hgA45GoQZTlH+X9g8eti2It6iwCKYUcoIzefhmyDThCkacIJ1Z+EQhBc3HCS5sMITiZvT7U7ylzwqBYGyoaVIRf86bTsrXnDPlPiQuua93vKVuZ8Ie8vT5uAmUvFCU70KBWlAGIcBWWa/7mbJrzQoiUZbtVCqkhVvtdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=XIJGdQBVkbHxyBRkfDbazGAssg6rrsASzwej0Xcmhttec7gVS4YcBm4iT2GVTn42QnwtPuLDS1526qKNhQwDkLj4qpjTvO7Pno6q6ipbEocTO/5WPg9KVR/85Kc7wVfR87Gj5A2fNlBDMembWbGDWmgwO/x1tpvfj5Eprw9Saaw= Received: by 10.142.230.11 with SMTP id c11mr1195194wfh.334.1210888220619; Thu, 15 May 2008 14:50:20 -0700 (PDT) Received: by 10.142.200.13 with HTTP; Thu, 15 May 2008 14:50:20 -0700 (PDT) Message-ID: Date: Thu, 15 May 2008 14:50:20 -0700 From: "Vijay Devarapallli" To: ipsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [IPsec] Redirect mechanism 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 Hello, The draft at the URL below describes a mechanism for re-directing an IKEv2 initiator to another gateway during the IKE_SA_INIT exchange. This could be used for Mobile IPv6 also for a home agent to re-direct a mobile node to another home agent. Comments/reviews are welcome. Vijay ---------- Forwarded message ---------- From: Date: 2008/5/15 Subject: I-D Action:draft-devarapalli-ipsec-ikev2-redirect-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Re-direct Mechanism for IKEv2 Author(s) : V. Devarapalli, et al. Filename : draft-devarapalli-ipsec-ikev2-redirect-00.txt Pages : 11 Date : 2008-05-15 IKEv2 is a popular protocol for setting up VPN tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently there is no standard mechanism specified that allows an overloaded VPN gateway to re- direct the VPN client to attach to another gateway. This document proposes a re-direct mechanism for IKEv2. The proposed mechanism can also be used for Mobile IPv6 to enable the home agent to re-direct the mobile node to another home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-devarapalli-ipsec-ikev2-redirect-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 16 02:44: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 1ED3328C174; Fri, 16 May 2008 02:44: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 5517728C157; Fri, 16 May 2008 02:44: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=[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 soGXJg4NewSb; Fri, 16 May 2008 02:44:30 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 5894428C15B; Fri, 16 May 2008 02:44:30 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JwwU3-0000Hn-Fq; Fri, 16 May 2008 11:44:15 +0200 X-Hashcash: 1:20:080516:mext@ietf.org::YLRgfCTlUECeNlg3:00001SBo From: arno@natisbad.org (Arnaud Ebalard) To: "Vijay Devarapallli" References: X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080516:dvijay@gmail.com::wDenXdoey4TJUQtG:05aJJ X-Hashcash: 1:20:080516:ipsec@ietf.org::fvm/lR22ZBp33lGO:0008Snx Date: Fri, 16 May 2008 11:44:05 +0200 Message-ID: <87r6c2r3bu.fsf@natisbad.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: ipsec@ietf.org, mext@ietf.org Subject: Re: [IPsec] Redirect mechanism 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="===============0389701204==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0389701204== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi Vijay, "Vijay Devarapallli" writes: > The draft at the URL below describes a mechanism for re-directing an > IKEv2 initiator to another gateway during the IKE_SA_INIT exchange. > This could be used for Mobile IPv6 also for a home agent to re-direct > a mobile node to another home agent. > > Comments/reviews are welcome. Some comments below, with quoted parts from the draft. Sorry for cross-posting but the discussion probably belongs to both ML.=20 Mostly, the idea of the mechanim and the coverage looks ok to me but the relationships with MIPv6 does not. To summarize most of my comments, the draft makes the redirect mechanism happen at the IKE level and expects that it has no impact on the work of the MIPv6 part. In practice, the address of the Home Agent being also the address of the IKE GW and the IPsec SA (even if the negotiation could be modified to be for different addresses regarding the IPsec SA and the IKE GW), there is a need for synchronization between IKE and MIPv6. IMHO, this is missing in the draft and should be stated.=20 Note that this summary and some of my comments/questions below can also be applied to Section 9 of RFC 4877, which describes Dynamic Home Address configuration using IKEv2. For me, the redirect mechanism described in the draft is in some way the dual of the Dynamic HoA configuration using IKE described in section 9 of RFC 4877.=20 Basically: =2D triggering event: IKE seems to initiate connections just like that, without real triggering events, i.e. some packets being sent that require protection and match some selector of a SPD entry. =2D communications/synchronization: IKE is used (addresses here and in 4877) for configuring/negotiating MIPv6 parameters but the synchronization of those elements is not covered. I would also include the IPsec in the picture. In practice, the MIPv6 modules, the IKE daemon and the IPsec stack must work *together*. At the moment, some draft and RFC on those elements have expectation but do not cover the interactions between those elements.=20 If I missed some reference document or something obvious, don't hesitate to correct me. From=20the introduction: > Mobile IPv6 [3] uses IKEv2 for mutual authentication between the > mobile node and the home agent. IKEv2 is also used for home address > configuration and setting up IPsec security associations for > protecting Mobile IPv6 signaling messages [4]." uses -> may/can use. The mechanism is not required. IKEv1 is also usable, so using IKE without any version might be better here. > The IKEv2 exchange precedes the exchange of Mobile IPv6 signaling > messages. In practice, AFAICT, the IKE exchange is *triggered* by the emission of the BU. It seems that RFC 4877 has started to take a different direction where IKE is used to configure MIPv6, but the details are missing. > Therefore the mechanism described in this document can be also be=20 > used by a Mobile IPv6 home agent to re-direct a mobile node to > another home agent. Collusion between Key Manager and HA operation. > There is a Home Agent Switch mechanism available for re-directing a > mobile node to another home agent, described in [5]. The Home Agent > Switch mechanism can only be used after the binding cache had been > created at the home agent for the mobile node. The disadvantage with > this is that quite a bit of state is created on the home agent before > the mobile node can be re-directed to another home agent. The > mechanism described in this document can be used for re-directing a > mobile node before any state is created on the home agent. IMHO, there is a difference between IKE and MIPv6 operations: 1) A Home Agent is overloaded and start redirecting MN to another HA: for instance, it is already using all its available upload bandwidth for registered MN (which is unrelated to IPsec/IKE). 2) There are too many IKE peers connecting at the same time on an IKE daemon (for the setup of IPsec SA between MN and HA or common clients) and the IKE daemon starts redirecting clients to another IKE daemon. What I mean is that, AFAICT, the two mechanism solve different problems, through different channels. In section 3 > When the VPN client receives the IKE_SA_INIT response with the > REDIRECT payload, it initiates a new IKE_SA_INIT exchange with the > VPN gateway listed in the REDIRECT payload. The VPN client includes > the IP address of the original VPN gateway that re-directed the > client. The IKEv2 exchange then proceeds as normal with the selected > VPN gateway. IMHO, the last sentence simply does not cover the possible associated issues and how things should be done, *how* the associated users (IPsec stack, MIPv6 module) are notified (on both sides). I am considering that MIPv6 is used to cover all cases.=20 =2D address of the IKE GW on the remote side =2D the address of the HA used by the client =2D the remote address of currently negotiated transport mode SA protecting MIPv6 signaling=20 =2D endpoints of negotiated tunnel mode SA protecting data traffic if any I imagine that they will be set to the new IP. AFAICT, if the negotiation was triggered by a BU, there will be a mismatch between the triggering packet and the new destination. > When this mechanism is used with Mobile IPv6, a mobile node's > security associations with its home agent may expire while it still > has a valid binding cache entry at the home agent. In this case, the > mobile node MUST NOT use an anycast address as the destination > address in the IKE_SA_INIT exchange to setup new security > associations. It MUST try to setup security associations with its > existing home agent. How does the MN knows the address is anycast? Here, I do not understand well the MIPv6 scenario. Can you clarify what you mean. > Section 4. Perhaps the previous point regarding interactions of MIPv6 clients with IKE daemons that are part of an anycast domain belong here. You should probably add some clear statements regarding the use of anycast addresses for IKE daemon for MIPv6 clients. More precisely, what are the conditions for a MIPv6 client to be configured with an anycast address (or a name resolving to an anycast address) for the IKE daemon of its HA. Can you tell me if I am wrong on this summary: you expect that a MIPv6 client can be configured with an anycast address (or a name resolving to an anycast address) for the IKE daemon of its HA if: =2D its local IKE Daemon support the Redirect =2D it is redirected to a non-anycast unicast address when it connects the first time=20 =2D it uses the address for all future connections to the remote IKE daemon while it is registered with its HA. > 5. I skipped it at the moment but will review in a future version of the draft.=20 > 6. Security Considerations ok. Cheers, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILVdsAlWVfAR6UCYRAnsFAJ9qcSg0Y9aLLn89CDE+ikvogyNUNQCfehu1 okqMo8QM7WgtTDcABQ8ptpM= =LUYf -----END PGP SIGNATURE----- --=-=-=-- --===============0389701204== 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 --===============0389701204==-- From ipsec-bounces@ietf.org Sun May 18 11:43: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 948E93A6DB4; Sun, 18 May 2008 11:43: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 3341E3A695B for ; Sun, 18 May 2008 11:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Af68akPvtmz8 for ; Sun, 18 May 2008 11:43:39 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 4AA513A6DB4 for ; Sun, 18 May 2008 11:43:39 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7B504294006; Sun, 18 May 2008 21:43:38 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8EB71294003; Sun, 18 May 2008 21:43:37 +0300 (IDT) Received: from [172.16.10.249] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m4IIhajI027779; Sun, 18 May 2008 21:43:36 +0300 (IDT) Message-ID: <483078D8.3080309@checkpoint.com> Date: Sun, 18 May 2008 21:43:36 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Vijay Devarapallli References: In-Reply-To: Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect mechanism 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 Vijay, thanks, this is a simple and effective load balancing solution. But I do have a few comments on the implementation you have chosen. - In addition to IP addresses, I propose to allow an FQDN in the redirect, both to make it more flexible (you don't need to configure all your gateways' IP addresses into each of your gateways) and also because the gateway's secure identity can be a DNS name, not just an address. - Also on this field: it is not a very clean solution to parse the address type (whether it's IPv4 or v6) based on the payload's length. - The REDIRECTED_FROM payload discloses unnecessary information (the "peer" gateways of each gateway) while providing very little security in return. I would prefer to remove it (making it optional is effectively the same as removing it). - The Security Considerations section mentions the case when "all clients need to be moved to another Home Agent/VPN server" which is obviously not solved by this solution - only *new* sessions will be moved. Thanks, Yaron Vijay Devarapallli wrote: > Hello, > > The draft at the URL below describes a mechanism for re-directing an > IKEv2 initiator to another gateway during the IKE_SA_INIT exchange. > This could be used for Mobile IPv6 also for a home agent to re-direct > a mobile node to another home agent. > > Comments/reviews are welcome. > > Vijay > > ---------- Forwarded message ---------- > From: > Date: 2008/5/15 > Subject: I-D Action:draft-devarapalli-ipsec-ikev2-redirect-00.txt > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Re-direct Mechanism for IKEv2 > Author(s) : V. Devarapalli, et al. > Filename : draft-devarapalli-ipsec-ikev2-redirect-00.txt > Pages : 11 > Date : 2008-05-15 > > IKEv2 is a popular protocol for setting up VPN tunnels from a remote > location to a gateway so that the VPN client can access services in > the network behind the gateway. Currently there is no standard > mechanism specified that allows an overloaded VPN gateway to re- > direct the VPN client to attach to another gateway. This document > proposes a re-direct mechanism for IKEv2. The proposed mechanism can > also be used for Mobile IPv6 to enable the home agent to re-direct > the mobile node to another home agent. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-devarapalli-ipsec-ikev2-redirect-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 19 05:16: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 8F6AD28C524; Mon, 19 May 2008 05:16: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 C61D428C611 for ; Mon, 19 May 2008 05:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.874 X-Spam-Level: X-Spam-Status: No, score=-5.874 tagged_above=-999 required=5 tests=[AWL=0.725, 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 3Gi5qtrCBGLO for ; Mon, 19 May 2008 05:16:41 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 8704F28C612 for ; Mon, 19 May 2008 05:16:41 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4JCGOew000325; Mon, 19 May 2008 15:16:34 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 15:16:20 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 15:16:20 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 May 2008 15:16:19 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72A539CF@vaebe104.NOE.Nokia.com> In-Reply-To: <483078D8.3080309@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Redirect mechanism for IKEv2 Thread-Index: Aci5FyZDZSssW/ChRIm7Az9P+k905QAkUbFg References: <483078D8.3080309@checkpoint.com> From: To: , X-OriginalArrivalTime: 19 May 2008 12:16:20.0575 (UTC) FILETIME=[258EBEF0:01C8B9AA] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect mechanism 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 Yaron Sheffer wrote: > Hi Vijay, > > thanks, this is a simple and effective load balancing solution. But > I do have a few comments on the implementation you have chosen. > > - In addition to IP addresses, I propose to allow an FQDN in the > redirect, both to make it more flexible (you don't need to configure > all your gateways' IP addresses into each of your gateways) and also > because the gateway's secure identity can be a DNS name, not just an > address. Since the REDIRECT payload is unauthenticated, it can't be used to update the "expected" responder identity -- so it should work fine even if gateways use DNS names in the IDr payload/certificate. > - Also on this field: it is not a very clean solution to parse the > address type (whether it's IPv4 or v6) based on the payload's length. I agree, separate type would be cleaner. > - The REDIRECTED_FROM payload discloses unnecessary information (the > "peer" gateways of each gateway) while providing very little > security in return. I would prefer to remove it (making it optional > is effectively the same as removing it). The reason for the REDIRECTED_FROM payload is to allow simpler countermeasures for the threat described in Section 6 (if a gateway gets an IKE_SA_INIT request that was redirected from some unknown address, it can reject it without starting the IKE exchange). About the information disclosure: are you worried about disclosing the source gateway address to the target gateway, or to eavesdroppers? (The eavesdroppers can already see it since REDIRECT is not encrypted, and most likely the gateways in a cluster don't need to hide their addresses from each other.) > - The Security Considerations section mentions the case when "all > clients need to be moved to another Home Agent/VPN server" which is > obviously not solved by this solution - only *new* sessions > will be moved. True, that should be clarified. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 19 08:28: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 B86253A6B1C; Mon, 19 May 2008 08:28: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 CCF7728C1C7 for ; Mon, 19 May 2008 08:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, 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 CLf0qvgxTBWa for ; Mon, 19 May 2008 08:28:02 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 498CD28C19C for ; Mon, 19 May 2008 08:28:02 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 74F08294010; Mon, 19 May 2008 18:27:58 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 91528294003; Mon, 19 May 2008 18:27:57 +0300 (IDT) Received: from [91.90.139.89] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m4JFRujI010936; Mon, 19 May 2008 18:27:57 +0300 (IDT) Message-ID: <48319C77.2010501@checkpoint.com> Date: Mon, 19 May 2008 18:27:51 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <483078D8.3080309@checkpoint.com> <1696498986EFEC4D9153717DA325CB72A539CF@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72A539CF@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, dvijay@gmail.com Subject: Re: [IPsec] Redirect mechanism 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="===============1532530815==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1532530815== Content-Type: multipart/alternative; boundary="------------050005040202050108050600" This is a multi-part message in MIME format. --------------050005040202050108050600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Yaron Sheffer wrote: > > [...] >> - In addition to IP addresses, I propose to allow an FQDN in the >> redirect, both to make it more flexible (you don't need to configure >> all your gateways' IP addresses into each of your gateways) and also >> because the gateway's secure identity can be a DNS name, not just an >> address. >> > > Since the REDIRECT payload is unauthenticated, it can't be used to > update the "expected" responder identity -- so it should work fine > even if gateways use DNS names in the IDr payload/certificate. > > Agreed. But operationally, of course, DNS is a very useful option. > [...] >> - The REDIRECTED_FROM payload discloses unnecessary information (the >> "peer" gateways of each gateway) while providing very little >> security in return. I would prefer to remove it (making it optional >> is effectively the same as removing it). >> > > The reason for the REDIRECTED_FROM payload is to allow simpler > countermeasures for the threat described in Section 6 (if a gateway > gets an IKE_SA_INIT request that was redirected from some unknown > address, it can reject it without starting the IKE exchange). > > This is indeed a threat, but probably not an important one: an attacker can initiate regular (non-redirected) IKE_SA_INIT from spoofed addresses, or from a botnet. This would be easier than intercepting legal IKE traffic and redirecting it. > About the information disclosure: are you worried about disclosing the > source gateway address to the target gateway, or to eavesdroppers? > (The eavesdroppers can already see it since REDIRECT is not > encrypted, and most likely the gateways in a cluster don't need > to hide their addresses from each other.) > > You are right, REDIRECT already advertises the information. > [...] --------------050005040202050108050600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote:
Yaron Sheffer wrote:

[...]
- In addition to IP addresses, I propose to allow an FQDN in the
redirect, both to make it more flexible (you don't need to configure
all your gateways' IP addresses into each of your gateways) and also
because the gateway's secure identity can be a DNS name, not just an
address.
    

Since the REDIRECT payload is unauthenticated, it can't be used to
update the "expected" responder identity -- so it should work fine
even if gateways use DNS names in the IDr payload/certificate.
Agreed. But operationally, of course, DNS is a very useful option.
[...]
- The REDIRECTED_FROM payload discloses unnecessary information (the 
"peer" gateways of each gateway) while providing very little 
security in return. I would prefer to remove it (making it optional 
is effectively the same as removing it).
    

The reason for the REDIRECTED_FROM payload is to allow simpler
countermeasures for the threat described in Section 6 (if a gateway
gets an IKE_SA_INIT request that was redirected from some unknown
address, it can reject it without starting the IKE exchange).
This is indeed a threat, but probably not an important one: an attacker can initiate regular (non-redirected) IKE_SA_INIT from spoofed addresses, or from a botnet. This would be easier than intercepting legal IKE traffic and redirecting it.
About the information disclosure: are you worried about disclosing the
source gateway address to the target gateway, or to eavesdroppers?
(The eavesdroppers can already see it since REDIRECT is not
encrypted, and most likely the gateways in a cluster don't need
to hide their addresses from each other.)
You are right, REDIRECT already advertises the information.
[...]
--------------050005040202050108050600-- --===============1532530815== 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 --===============1532530815==-- From ipsec-bounces@ietf.org Mon May 19 08:49: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 87EE628C63E; Mon, 19 May 2008 08:49: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 0CEF828C64D for ; Mon, 19 May 2008 08:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiFzTULwtbox for ; Mon, 19 May 2008 08:49:43 -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 1641028C4FE for ; Mon, 19 May 2008 08:49:43 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4JFnhpx002410 for ; Mon, 19 May 2008 15:49:43 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m4JFnhKh012318 for ; Mon, 19 May 2008 09:49:43 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m4JFnhhp001697; Mon, 19 May 2008 10:49:43 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m4JFngPg001696; Mon, 19 May 2008 10:49:42 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 19 May 2008 10:49:42 -0500 From: Nicolas Williams To: Pasi.Eronen@nokia.com Message-ID: <20080519154942.GG26388@Sun.COM> Mail-Followup-To: Pasi.Eronen@nokia.com, yaronf@checkpoint.com, dvijay@gmail.com, ipsec@ietf.org References: <483078D8.3080309@checkpoint.com> <1696498986EFEC4D9153717DA325CB72A539CF@vaebe104.NOE.Nokia.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <1696498986EFEC4D9153717DA325CB72A539CF@vaebe104.NOE.Nokia.com> User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org, dvijay@gmail.com Subject: Re: [IPsec] Redirect mechanism 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 Mon, May 19, 2008 at 03:16:19PM +0300, Pasi.Eronen@nokia.com wrote: > Yaron Sheffer wrote: > > - Also on this field: it is not a very clean solution to parse the > > address type (whether it's IPv4 or v6) based on the payload's length. > > I agree, separate type would be cleaner. I agree that it *would* have been cleaner. Adding encoding redundancy now would not be cleaner, but it would likely spawn bugs. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 19 11:45: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 806673A6B50; Mon, 19 May 2008 11:45: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 F201E3A6B4E for ; Mon, 19 May 2008 11:45:52 -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 ngLQVkH7d1k4 for ; Mon, 19 May 2008 11:45:48 -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 9420A3A6B50 for ; Mon, 19 May 2008 11:45:47 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so1849094fga.41 for ; Mon, 19 May 2008 11:45:47 -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:mime-version:content-type; bh=wP8MCWSKQ5pyWqmobxG0fVQVGdF7JWvFsc+B/VtpTC0=; b=yGoh1fwueERYblmRzVMmiTcC/x0bZS+Nm6iEC4XqvHoAGXATOXM7OQ73DKRt0yow2dKKZsX6JiEc14YUkoERHJqkwMXeZgkGksQkgVxPJ1N0KppBciJkfn36S726nbaLS6iD/KOCaPiZcsuoOyDNlSm9Aw5OCqEe3umqaNDZIL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=ENYSC1xAYm/b9WmJnQSU1djOROHiXHHEwfdNyqeB6pgs2m2YXbMUTptTcKPW9vKxDfWMXxMW3p83QX2gTt8KvN20kVq0TyyrcVBM2ioPoKnorGx6D4GqcwsPNT4biPCMD60p2u+kxhFQZe77Ns8FF//Z+WT0sr34wOXBR9P+8CM= Received: by 10.78.204.7 with SMTP id b7mr2070378hug.27.1211222747456; Mon, 19 May 2008 11:45:47 -0700 (PDT) Received: by 10.78.177.15 with HTTP; Mon, 19 May 2008 11:45:44 -0700 (PDT) Message-ID: <82c331830805191145ja1f2436ib934df64f33347@mail.gmail.com> Date: Tue, 20 May 2008 00:15:44 +0530 From: "sumit agarwal" To: ipsec@ietf.org MIME-Version: 1.0 Subject: [IPsec] Hash in NAT_DETECTION_SOURCE_IP 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="===============1861092034==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1861092034== Content-Type: multipart/alternative; boundary="----=_Part_14466_27330340.1211222747454" ------=_Part_14466_27330340.1211222747454 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I have a doubt on hash Calculation for NAT notification during IKE_SA_INIT exchange. While the IKEv2 RFC states NAT_DETECTION_SOURCE_IP 16388 This notification is used by its recipient to determine whether the source is behind a NAT box. *The data associated with this notification is a SHA-1 digest of the SPIs (in the order they appear in the header), IP address, and port on which this packet was sent.* Does it mean that while sending the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP in the first message of IKE_SA_INIT exchange, where the responder cookie is 0.The responder cookie should be kept out of Hash calculation or the Hash should be calculated with responder cookie as 0? With warm regards, Sumit ------=_Part_14466_27330340.1211222747454 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
I have a doubt on hash Calculation for NAT notification during IKE_SA_INIT exchange.
While the IKEv2 RFC states
 
NAT_DETECTION_SOURCE_IP                  16388

            This notification is used by its recipient to determine
            whether the source is behind a NAT box.  The data associated
            with this notification is a SHA-1 digest of the SPIs (in the
            order they appear in the header), IP address, and port on
            which this packet was sent. 
 
Does it mean that while sending the NAT_DETECTION_SOURCE_IP  or NAT_DETECTION_DESTINATION_IP in the first message of IKE_SA_INIT exchange,
where the responder cookie is 0.The responder cookie should be kept out of Hash calculation or the Hash should be calculated with responder cookie as 0?
 
With warm regards,
Sumit
 

 
------=_Part_14466_27330340.1211222747454-- --===============1861092034== 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 --===============1861092034==-- From ipsec-bounces@ietf.org Mon May 19 11:50:20 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 41CC93A6B2C; Mon, 19 May 2008 11:50: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 767ED3A6952 for ; Mon, 19 May 2008 11:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.942 X-Spam-Level: X-Spam-Status: No, score=-5.942 tagged_above=-999 required=5 tests=[AWL=0.657, 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 WA7zNX3hRWsj for ; Mon, 19 May 2008 11:50:14 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id CF3AA3A6ABE for ; Mon, 19 May 2008 11:50:13 -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 m4JInf69023032; Mon, 19 May 2008 13:50:09 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 21:50:03 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 May 2008 21:50:03 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 May 2008 21:50:02 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72A53D67@vaebe104.NOE.Nokia.com> In-Reply-To: <20080519154942.GG26388@Sun.COM> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Redirect mechanism for IKEv2 Thread-Index: Aci5x/rOuOYTIBY8TLKEA77p7rIGQQAGK8Ag References: <483078D8.3080309@checkpoint.com> <1696498986EFEC4D9153717DA325CB72A539CF@vaebe104.NOE.Nokia.com> <20080519154942.GG26388@Sun.COM> From: To: X-OriginalArrivalTime: 19 May 2008 18:50:03.0387 (UTC) FILETIME=[25D9CCB0:01C8B9E1] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect mechanism 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 Nicolas Williams wrote: > On Mon, May 19, 2008 at 03:16:19PM +0300, Pasi.Eronen@nokia.com wrote: > > Yaron Sheffer wrote: > > > - Also on this field: it is not a very clean solution to > > > parse the address type (whether it's IPv4 or v6) based on the > > > payload's length. > > > > I agree, separate type would be cleaner. > > I agree that it *would* have been cleaner. Adding encoding > redundancy now would not be cleaner, but it would likely spawn bugs. What do you mean by "would have been"? (certainly it isn't too late to change this draft -- the -00 version came out only couple of days ago, and I doubt we have any implementers who're that fast :-) Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 19 11:52:51 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 E59FF3A6ABE; Mon, 19 May 2008 11:52: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 EF5383A6ABF for ; Mon, 19 May 2008 11:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS+kP3wtYO1K for ; Mon, 19 May 2008 11:52:47 -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 7A37C3A68EB for ; Mon, 19 May 2008 11:52:47 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m4JIqkL0020474 for ; Mon, 19 May 2008 18:52:46 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m4JIqkZq010850 for ; Mon, 19 May 2008 12:52:46 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m4JIqkKH001879; Mon, 19 May 2008 13:52:46 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m4JIqkqC001878; Mon, 19 May 2008 13:52:46 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 19 May 2008 13:52:46 -0500 From: Nicolas Williams To: Pasi.Eronen@nokia.com Message-ID: <20080519185245.GN26388@Sun.COM> Mail-Followup-To: Pasi.Eronen@nokia.com, ipsec@ietf.org References: <483078D8.3080309@checkpoint.com> <1696498986EFEC4D9153717DA325CB72A539CF@vaebe104.NOE.Nokia.com> <20080519154942.GG26388@Sun.COM> <1696498986EFEC4D9153717DA325CB72A53D67@vaebe104.NOE.Nokia.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <1696498986EFEC4D9153717DA325CB72A53D67@vaebe104.NOE.Nokia.com> User-Agent: Mutt/1.5.7i Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect mechanism 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 Mon, May 19, 2008 at 09:50:02PM +0300, Pasi.Eronen@nokia.com wrote: > Nicolas Williams wrote: > > On Mon, May 19, 2008 at 03:16:19PM +0300, Pasi.Eronen@nokia.com wrote: > > > Yaron Sheffer wrote: > > > > - Also on this field: it is not a very clean solution to > > > > parse the address type (whether it's IPv4 or v6) based on the > > > > payload's length. > > > > > > I agree, separate type would be cleaner. > > > > I agree that it *would* have been cleaner. Adding encoding > > redundancy now would not be cleaner, but it would likely spawn bugs. > > What do you mean by "would have been"? (certainly it isn't too > late to change this draft -- the -00 version came out only couple > of days ago, and I doubt we have any implementers who're that fast :-) Ah, I thought this was about changing deployed stuff. Never mind then! :) _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 19 22:52: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 6BD903A69B6; Mon, 19 May 2008 22:52: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 171EE3A69B6 for ; Mon, 19 May 2008 22:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIA6Id95stwG for ; Mon, 19 May 2008 22:52:46 -0700 (PDT) Received: from barracuda.intoto.com (unknown [66.88.133.2]) by core3.amsl.com (Postfix) with ESMTP id 24DE03A685C for ; Mon, 19 May 2008 22:52:45 -0700 (PDT) Received: from brahma.hyd.intoto.com (unknown [172.16.1.10]) by barracuda.intoto.com (Spam Firewall) with ESMTP id BA5F11C7F4; Mon, 19 May 2008 22:52:32 -0700 (PDT) Received: from nsm.intoto.com (4mc90.hyd.intoto.com [172.16.4.90]) by brahma.hyd.intoto.com (8.13.1/8.13.1) with ESMTP id m4K5qfp8026325; Tue, 20 May 2008 11:22:43 +0530 Message-Id: <7.0.1.0.1.20080520110733.042980e0@intoto.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 20 May 2008 11:17:56 +0530 To: "sumit agarwal" , ipsec@ietf.org From: ns srinivasa murthy In-Reply-To: <82c331830805191145ja1f2436ib934df64f33347@mail.gmail.com> References: <82c331830805191145ja1f2436ib934df64f33347@mail.gmail.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.62 on 172.16.1.10 Subject: Re: [IPsec] Hash in NAT_DETECTION_SOURCE_IP 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="===============1244718470==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1244718470== Content-Type: multipart/alternative; boundary="=====================_6625343==.ALT" --=====================_6625343==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Responder cookie should be taken into account while calculating the Hash even if it zero. -nsmurthy At 12:15 AM 5/20/2008, sumit agarwal wrote: >Hi, > >I have a doubt on hash Calculation for NAT notification during >IKE_SA_INIT exchange. >While the IKEv2 RFC states > >NAT_DETECTION_SOURCE_IP 16388 > > This notification is used by its recipient to determine > whether the source is behind a NAT box. The data associated > with this notification is a SHA-1 digest of the SPIs (in the > order they appear in the header), IP address, and port on > which this packet was sent. > >Does it mean that while sending the NAT_DETECTION_SOURCE_IP or >NAT_DETECTION_DESTINATION_IP in the first message of IKE_SA_INIT exchange, >where the responder cookie is 0.The responder cookie should be kept >out of Hash calculation or the Hash should be calculated with >responder cookie as 0? > >With warm regards, >Sumit > > > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec ******************************************************************************** This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. --=====================_6625343==.ALT Content-Type: text/html; charset="us-ascii"
Responder cookie should be taken into account while calculating the Hash even if it zero.

-nsmurthy


At 12:15 AM 5/20/2008, sumit agarwal wrote:
Hi,
 
I have a doubt on hash Calculation for NAT notification during IKE_SA_INIT exchange.
While the IKEv2 RFC states
 
NAT_DETECTION_SOURCE_IP                  16388

            This notification is used by its recipient to determine
            whether the source is behind a NAT box.  The data associated
            with this notification is a SHA-1 digest of the SPIs (in the
            order they appear in the header), IP address, and port on
            which this packet was sent. 
 
Does it mean that while sending the NAT_DETECTION_SOURCE_IP  or NAT_DETECTION_DESTINATION_IP in the first message of IKE_SA_INIT exchange,
where the responder cookie is 0.The responder cookie should be kept out of Hash calculation or the Hash should be calculated with responder cookie as 0?
 
With warm regards,
Sumit
 

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

--=====================_6625343==.ALT-- --===============1244718470== 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 --===============1244718470==-- From ipsec-bounces@ietf.org Tue May 20 00:18: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 ADAEE3A6784; Tue, 20 May 2008 00:18: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 1E0803A69EC for ; Tue, 20 May 2008 00:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaN89rt6E0TB for ; Tue, 20 May 2008 00:18:07 -0700 (PDT) Received: from barracuda.intoto.com (unknown [66.88.133.2]) by core3.amsl.com (Postfix) with ESMTP id C74753A67FA for ; Tue, 20 May 2008 00:17:19 -0700 (PDT) Received: from brahma.hyd.intoto.com (unknown [172.16.1.10]) by barracuda.intoto.com (Spam Firewall) with ESMTP id 5F9E113EE for ; Tue, 20 May 2008 00:17:06 -0700 (PDT) Received: from nsm.intoto.com (4mc90.hyd.intoto.com [172.16.4.90]) by brahma.hyd.intoto.com (8.13.1/8.13.1) with ESMTP id m4K7HFrB017416 for ; Tue, 20 May 2008 12:47:16 +0530 Message-Id: <7.0.1.0.1.20080520125756.04a68188@intoto.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 20 May 2008 12:59:38 +0530 To: ipsec@ietf.org From: ns srinivasa murthy Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.62 on 172.16.1.10 Subject: [IPsec] New Version Notification for draft-intoto-simple-mobility-ipsec-clients-00 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="===============0426590033==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0426590033== Content-Type: multipart/alternative; boundary="=====================_11699281==.ALT" --=====================_11699281==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi all, Please send your comments. Thanks -nsmurthy A new version of I-D, draft-intoto-simple-mobility-ipsec-clients-00.txt has been successfuly submitted by Srinivasa Murthy and posted to the IETF repository. Filename: draft-intoto-simple-mobility-ipsec-clients Revision: 00 Title: Simple Mobility Solution for IPsec Clients Creation_date: 2008-05-18 WG ID: Independent Submission Number_of_pages: 7 Abstract: One very popular use of VPNs is to provide telecommuter access to the corporate Intranet. Remote clients that are behind NAT boxes can also access the corporate intranet with the help of the standard NAT Traversal feature. But this access may be disturbed in scenarios where a mobile user roams across different points of attachment and there by getting assigned with different IP Addresses. The access also fails in cases where the client roams across environments with NAT to environments without NAT and vice versa. In both the cases the tunnel may get re-established but it induces jitter in voice sessions. The IETF Secretariat. ******************************************************************************** This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. --=====================_11699281==.ALT Content-Type: text/html; charset="us-ascii" Hi all,
Please send your comments.
Thanks
-nsmurthy

A new version of I-D, draft-intoto-simple-mobility-ipsec-clients-00.txt has been successfuly submitted by Srinivasa Murthy and posted to the IETF repository.

Filename:        draft-intoto-simple-mobility-ipsec-clients
Revision:       00
Title:           Simple Mobility Solution for IPsec Clients
Creation_date:  2008-05-18
WG ID:           Independent Submission
Number_of_pages: 7

Abstract:
One very popular use of VPNs is to provide telecommuter access to
the corporate Intranet. Remote clients that are behind NAT boxes
can also access the corporate intranet with the help of the
standard NAT Traversal feature.

But this access may be disturbed in scenarios where a mobile user
roams across different points of attachment and there by getting
assigned with different IP Addresses. The access also fails in
cases where the client roams across environments with NAT
to environments without NAT and vice versa. In both the cases
the tunnel may get re-established but it induces jitter in voice
sessions.
                                                                                 


The IETF Secretariat.
--=====================_11699281==.ALT-- --===============0426590033== 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 --===============0426590033==-- From ipsec-bounces@ietf.org Tue May 20 00:30: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 8DB213A6B9C; Tue, 20 May 2008 00:30:36 -0700 (PDT) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13BA83A6B9C for ; Tue, 20 May 2008 00:30:35 -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 zNeY1QZ+tf2a for ; Tue, 20 May 2008 00:30:34 -0700 (PDT) Received: from tietoe03.tietoenator.com (datnt07.tieto.com [194.110.47.24]) by core3.amsl.com (Postfix) with ESMTP id 7A36F3A69DF for ; Tue, 20 May 2008 00:30:32 -0700 (PDT) X-AuditID: c26e2f18-000015f800000528-0c-48327e253fbe Received: from stingray.eu.tieto.com ([192.176.143.13]) by tietoe03.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 May 2008 10:30:45 +0300 Received: from corvette.eu.tieto.com ([192.176.143.143]) by stingray.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 May 2008 09:30:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 20 May 2008 09:30:30 +0200 Message-ID: In-Reply-To: <82c331830805191145ja1f2436ib934df64f33347@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Hash in NAT_DETECTION_SOURCE_IP thread-index: Aci54KvlZ3f9LaWkR9edna68lART5gAaEqqg References: <82c331830805191145ja1f2436ib934df64f33347@mail.gmail.com> From: To: X-OriginalArrivalTime: 20 May 2008 07:30:31.0241 (UTC) FILETIME=[622BCB90:01C8BA4B] X-Brightmail-Tracker: AAAAAA== Cc: ipsec@ietf.org Subject: Re: [IPsec] Hash in NAT_DETECTION_SOURCE_IP 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="===============0513316300==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0513316300== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8BA4B.61F5185D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8BA4B.61F5185D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When the IKE initiator includes a NAT_DETECTION_SOURCE_IP payload, that payload contains the SHA1 value (20 bytes) over a string consisting of 8 bytes of SPI-Initiator 8 bytes of SPI-Responder (which is zero in the IKE_SA_INIT request) 4 bytes of IPv4 source address (or 16 bytes of IPv6 source address) 2 bytes of UDP source port The COOKIE payload is not included in this calculation or in other calculations (as sender) or verifications (as receivers) for NAT_DETECTION_*_IP. =20 Christian =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of sumit agarwal Sent: 19. maj 2008 20:46 To: ipsec@ietf.org Subject: [IPsec] Hash in NAT_DETECTION_SOURCE_IP =09 =09 Hi, =20 I have a doubt on hash Calculation for NAT notification during IKE_SA_INIT exchange. While the IKEv2 RFC states=20 =20 NAT_DETECTION_SOURCE_IP 16388 =09 This notification is used by its recipient to determine whether the source is behind a NAT box. The data associated with this notification is a SHA-1 digest of the SPIs (in the order they appear in the header), IP address, and port on which this packet was sent. =20 =20 Does it mean that while sending the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP in the first message of IKE_SA_INIT exchange,=20 where the responder cookie is 0.The responder cookie should be kept out of Hash calculation or the Hash should be calculated with responder cookie as 0? =20 With warm regards, Sumit =20 =20 ------_=_NextPart_001_01C8BA4B.61F5185D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
When the IKE initiator includes a = NAT_DETECTION_SOURCE_IP=20 payload, that payload
contains the SHA1 value (20 bytes) over a = string=20 consisting of
    8 bytes of=20 SPI-Initiator
    8 bytes of SPI-Responder = (which is zero=20 in the IKE_SA_INIT request)
    4 bytes of IPv4 source = address (or 16=20 bytes of IPv6 source address)
    2 bytes of UDP source=20 port
The COOKIE payload is not included in this = calculation or=20 in other calculations (as sender) or
verifications (as receivers) for = NAT_DETECTION_*_IP.
 
Christian
 

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of sumit=20 agarwal
Sent: 19. maj 2008 20:46
To:=20 ipsec@ietf.org
Subject: [IPsec] Hash in=20 NAT_DETECTION_SOURCE_IP

Hi,
 
I have a doubt on hash Calculation for NAT notification during=20 IKE_SA_INIT exchange.
While the IKEv2 RFC states
 
=
NAT_DETECTION_SOURCE_IP       &nb= sp;         =20 = 16388

          =  =20 This notification is used by its recipient to=20 = determine
          =  =20 whether the source is behind a NAT box.  The data=20 = associated
          = ; =20 with this notification is a SHA-1 digest of the SPIs (in=20 = the
           = =20 order they appear in the header), IP address, and port=20 = on
            = which=20 this packet was sent. 
 
Does it mean that while sending the = NAT_DETECTION_SOURCE_IP  or=20 NAT_DETECTION_DESTINATION_IP in the first message of IKE_SA_INIT = exchange,=20
where the responder cookie is 0.The responder cookie should be = kept out=20 of Hash calculation or the Hash should be calculated with responder = cookie as=20 0?
 
With warm regards,
Sumit
 

 
------_=_NextPart_001_01C8BA4B.61F5185D-- --===============0513316300== 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 --===============0513316300==-- From ipsec-bounces@ietf.org Tue May 20 00:58: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 457E23A69FF; Tue, 20 May 2008 00:58: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 CDA473A68C1 for ; Tue, 20 May 2008 00: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 Euy-oGZXhe+6 for ; Tue, 20 May 2008 00:58:37 -0700 (PDT) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.226]) by core3.amsl.com (Postfix) with ESMTP id 7A2E73A69FF for ; Tue, 20 May 2008 00:58:37 -0700 (PDT) Received: by wx-out-0506.google.com with SMTP id i29so1951266wxd.31 for ; Tue, 20 May 2008 00:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=5ZO2cMbjwjy6IpSIcaGOSSzWtBOflf6jWnKg7gC2Tkw=; b=WQPW8pZ+BaIJIJhteAnQTfXXYgkFFJAnx7EaGmS++Rmxn+3cvRib3yPACt2dNapI64EkeYPDHJE86NgE4JyKSRL9JHpYByOT2rTxNfAJIwk+1Kg6bMrAp636YgSFvbrDedOYejr/7Ettf3Z0eZv0HTo+fJ1s5bvjZ0biy8YN0fI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=o/YI5yfeV6VoJV5zQ/fY56KI9Bldt5dFGYT/1Jb1LFkLvTBjIZRnMGZ24dOcVocRRYlLqLj8zQP8c8giQrBjC8eW9Aatwzzd1A7WzRMIbpbYcwQWevOUz7mFdYRaBBeWLkhYtxlw9Q4R4h7/YFlSSf2lIMR44G37bke3fnFdkic= Received: by 10.90.91.2 with SMTP id o2mr11224023agb.56.1211270318209; Tue, 20 May 2008 00:58:38 -0700 (PDT) Received: by 10.90.90.13 with HTTP; Tue, 20 May 2008 00:58:38 -0700 (PDT) Message-ID: <850df0c40805200058q74646093r7f2576c0690b73f0@mail.gmail.com> Date: Tue, 20 May 2008 09:58:38 +0200 From: "balaji raghavan" To: Christian.Kaas-Petersen@tietoenator.com In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <82c331830805191145ja1f2436ib934df64f33347@mail.gmail.com> Cc: ipsec@ietf.org, sumitjec@gmail.com Subject: Re: [IPsec] Hash in NAT_DETECTION_SOURCE_IP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: balaji.raghavan.t@gmail.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-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 RFC 4306 " The Internet Security Association and Key Management Protocol (ISAKMP) [MSST98] fixed message header includes two eight- octet fields titled "cookies", and that syntax is used by both IKEv1 and IKEv2 though in IKEv2 they are referred to as the IKE SPI and there is a new separate field in a Notify payload holding the cookie. " I guess by responder cookie you meant "SPI-responder" in IKEv1 lingo and not the notify (COOKIE) payload. :) -Balaji On Tue, May 20, 2008 at 9:30 AM, wrote: > When the IKE initiator includes a NAT_DETECTION_SOURCE_IP payload, that > payload > contains the SHA1 value (20 bytes) over a string consisting of > 8 bytes of SPI-Initiator > 8 bytes of SPI-Responder (which is zero in the IKE_SA_INIT request) > 4 bytes of IPv4 source address (or 16 bytes of IPv6 source address) > 2 bytes of UDP source port > The COOKIE payload is not included in this calculation or in other > calculations (as sender) or > verifications (as receivers) for NAT_DETECTION_*_IP. > > Christian > > > ________________________________ > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > sumit agarwal > Sent: 19. maj 2008 20:46 > To: ipsec@ietf.org > Subject: [IPsec] Hash in NAT_DETECTION_SOURCE_IP > > Hi, > > I have a doubt on hash Calculation for NAT notification during IKE_SA_INIT > exchange. > While the IKEv2 RFC states > > NAT_DETECTION_SOURCE_IP 16388 > > This notification is used by its recipient to determine > whether the source is behind a NAT box. The data associated > with this notification is a SHA-1 digest of the SPIs (in the > order they appear in the header), IP address, and port on > which this packet was sent. > > Does it mean that while sending the NAT_DETECTION_SOURCE_IP or > NAT_DETECTION_DESTINATION_IP in the first message of IKE_SA_INIT exchange, > where the responder cookie is 0.The responder cookie should be kept out of > Hash calculation or the Hash should be calculated with responder cookie as > 0? > > With warm regards, > Sumit > > > > _______________________________________________ > 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 May 20 01:35: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 29B7628C165; Tue, 20 May 2008 01:35: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 7BF153A6BC3 for ; Tue, 20 May 2008 01:35:42 -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 0C7Ii-rehMoQ for ; Tue, 20 May 2008 01:35:39 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 5DFD83A6B98 for ; Tue, 20 May 2008 01:35:38 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6CE32294006; Tue, 20 May 2008 11:35:38 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 38AC3294003; Tue, 20 May 2008 11:35:37 +0300 (IDT) Received: from MBP.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m4K8ZajI019932; Tue, 20 May 2008 11:35:36 +0300 (IDT) Message-Id: <478E71AE-05CD-4540-B188-90F0411EBC4E@checkpoint.com> From: Yoav Nir To: ns srinivasa murthy In-Reply-To: <7.0.1.0.1.20080520125756.04a68188@intoto.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 20 May 2008 11:35:35 +0300 References: <7.0.1.0.1.20080520125756.04a68188@intoto.com> X-Mailer: Apple Mail (2.919.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-intoto-simple-mobility-ipsec-clients-00 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="===============0574626574==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0574626574== Content-Type: multipart/signed; boundary=Apple-Mail-8-1037102042; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-8-1037102042 Content-Type: multipart/alternative; boundary=Apple-Mail-7-1037101957 --Apple-Mail-7-1037101957 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi I think this draft may be very useful, and I have a few comments: 1. NAT Detection payloads, as defined in the relevant RFCs have a payload that is the output of a SHA-1 function, so the payload length is 28 bytes. Implementations will verify this length as part of a packet sanity check. I suggest that you keep the payload with length 28, and fill it with something random-looking rather than sending a zero length payload. You may even want to specify a 20-byte string (maybe the SHA-1 hash of "draft-intoto-simple-mobility-ipsec-clients"). 2. There is no signaling in the protocol of compliance with this specification. Section 4 of your draft details some gateway behavior, but a compliant client has no way of knowing whether the gateway is compliant. Suppose I were now writing a client that should connect to any RFC4306- compliant gateway, but does not support MOBIKE. I might use a protocol such as STUN to detect when my IP address changes. When that happens, I would begin an INITIAL exchange, and tear down the previous tunnel. That would give me a working tunnel as quickly as possible. This is more cumbersome, but is necessary where gateways don't implement your draft. If some of the gateways in the world support your attribute, while some don't, clients need a way to tell them apart. A notification (SIMPLE-MOBILITY-SUPPORTED) could help here. Yoav On May 20, 2008, at 10:29 AM, ns srinivasa murthy wrote: > Hi all, > Please send your comments. > Thanks > -nsmurthy > > A new version of I-D, draft-intoto-simple-mobility-ipsec- > clients-00.txt has been successfuly submitted by Srinivasa Murthy > and posted to the IETF repository. > > Filename: draft-intoto-simple-mobility-ipsec-clients > Revision: 00 > Title: Simple Mobility Solution for IPsec Clients > Creation_date: 2008-05-18 > WG ID: Independent Submission > Number_of_pages: 7 > > Abstract: > One very popular use of VPNs is to provide telecommuter access to > the corporate Intranet. Remote clients that are behind NAT boxes > can also access the corporate intranet with the help of the > standard NAT Traversal feature. > > But this access may be disturbed in scenarios where a mobile user > roams across different points of attachment and there by getting > assigned with different IP Addresses. The access also fails in > cases where the client roams across environments with NAT > to environments without NAT and vice versa. In both the cases > the tunnel may get re-established but it induces jitter in voice > sessions. > > > > The IETF Secretariat. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-7-1037101957 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi

I think = this draft may be very useful, and I have a few = comments:

1. NAT Detection payloads, as defined = in the relevant RFCs have a payload that is the output of a SHA-1 = function, so the payload length is 28 bytes. Implementations will verify = this length as part of a packet sanity check.  I suggest that you = keep the payload with length 28, and fill it with something = random-looking rather than sending a zero length payload.  You may = even want to specify a 20-byte string (maybe the SHA-1 hash of = "draft-intoto-simple-mobility-ipsec-clients").

2.= There is no signaling in the protocol of compliance with this = specification.  Section 4 of your draft details some gateway = behavior, but a compliant client has no way of knowing whether the = gateway is compliant.

Suppose I were now = writing a client that should connect to any RFC4306-compliant gateway, = but does not support MOBIKE. I might use a protocol such as STUN to = detect when my IP address changes. When that happens, I would begin an = INITIAL exchange, and tear down the previous tunnel. That would give me = a working tunnel as quickly as possible. This is more cumbersome, but is = necessary where gateways don't implement your = draft.

If some of the gateways in the world = support your attribute, while some don't, clients need a way to tell = them apart.  A notification (SIMPLE-MOBILITY-SUPPORTED) could help = here.

Yoav

On May 20, = 2008, at 10:29 AM, ns srinivasa murthy wrote:

= Hi all,
Please send your comments.
Thanks
= -nsmurthy

A new version of I-D, = draft-intoto-simple-mobility-ipsec-clients-00.txt has been successfuly = submitted by Srinivasa Murthy and posted to the IETF repository.

= Filename:        = draft-intoto-simple-mobility-ipsec-clients
= Revision:       00
= Title:   =         Simple Mobility = Solution for IPsec Clients
= Creation_date:  2008-05-18
WG = ID:   =         Independent = Submission
Number_of_pages: 7

Abstract:
One very popular = use of VPNs is to provide telecommuter access to
the corporate = Intranet. Remote clients that are behind NAT boxes
can also access = the corporate intranet with the help of the
standard NAT Traversal = feature.

But this access may be disturbed in scenarios where a = mobile user
roams across different points of attachment and there by = getting
assigned with different IP Addresses. The access also fails = in
cases where the client roams across environments with NAT
to = environments without NAT and vice versa. In both the cases
the = tunnel may get re-established but it induces jitter in voice
= sessions.
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =        


The IETF = Secretariat.

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

= --Apple-Mail-7-1037101957-- --Apple-Mail-8-1037102042 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3 WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77 BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9 MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDUyMDA4 MzUzNlowIwYJKoZIhvcNAQkEMRYEFFuFju5WlDYlxzJkQBd8mDwb9LukMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQBOH11X7lb6 OynnWhw4IaDYbNQR2stj9sVE/nga7afQSiKfAVGo69+UHlJCbFKYdQVG8hoCIBcrWyRO8IE2LGNz Wmzszi8N+K5en+B0FsTfjML9sqmLHO9BMN3hYjb38yAGstUIGtZ2f6qKmdHChex4RMW3YtrNnTUB FZGNZUvo7ENN5W7I8oi0HssWuw9oRkP4+aIEddO1ITimNFS1z2jdlezW3gO0zHyaUykmCy42PuSP doGMsQE548Z8sFPt6Ii9ts8oQDO08oucYPRLn7CGkfxX1iOVR2aiSxV6LESXAeE66U/2wS+8fk/V 8daRYmyDVCzQwHItA7ju4/cIdvbaAAAAAAAA --Apple-Mail-8-1037102042-- --===============0574626574== 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 --===============0574626574==-- From ipsec-bounces@ietf.org Tue May 20 04:54: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 5BDE23A69E4; Tue, 20 May 2008 04:54: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 9D7943A68DD for ; Tue, 20 May 2008 04:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.649, 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 OFRzlEvmNqDw for ; Tue, 20 May 2008 04:54:15 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A56833A6A2F for ; Tue, 20 May 2008 04:54:14 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 099C5294016; Tue, 20 May 2008 14:54:15 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 93A6B294017; Tue, 20 May 2008 14:54:09 +0300 (IDT) Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id m4KBs9jL014809; Tue, 20 May 2008 14:54:09 +0300 (IDT) Message-ID: <4832BBD3.7020304@checkpoint.com> Date: Tue, 20 May 2008 14:53:55 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Yoav Nir References: <7.0.1.0.1.20080520125756.04a68188@intoto.com> <478E71AE-05CD-4540-B188-90F0411EBC4E@checkpoint.com> In-Reply-To: <478E71AE-05CD-4540-B188-90F0411EBC4E@checkpoint.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-intoto-simple-mobility-ipsec-clients-00 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="===============2023021414==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============2023021414== Content-Type: multipart/alternative; boundary="------------010300010303090008060008" This is a multi-part message in MIME format. --------------010300010303090008060008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One more: when a client detects that it has moved (e.g. it has a new IP address), it is important that it signals this fact, instead of waiting for the next "real" traffic to be sent over the tunnel. Otherwise the gateway will not know about the address change and the client will not be reachable from the network side, possibly for a long time. One option is for the client to generate a DPD message. RFC 4555, Sec. 2.1 has more background about movement detection. Thanks, Yaron Yoav Nir wrote: > Hi > > I think this draft may be very useful, and I have a few comments: > > 1. NAT Detection payloads, as defined in the relevant RFCs have a > payload that is the output of a SHA-1 function, so the payload length > is 28 bytes. Implementations will verify this length as part of a > packet sanity check. I suggest that you keep the payload with length > 28, and fill it with something random-looking rather than sending a > zero length payload. You may even want to specify a 20-byte string > (maybe the SHA-1 hash of "draft-intoto-simple-mobility-ipsec-clients"). > > 2. There is no signaling in the protocol of compliance with this > specification. Section 4 of your draft details some gateway behavior, > but a compliant client has no way of knowing whether the gateway is > compliant. > > Suppose I were now writing a client that should connect to any > RFC4306-compliant gateway, but does not support MOBIKE. I might use a > protocol such as STUN to detect when my IP address changes. When that > happens, I would begin an INITIAL exchange, and tear down the previous > tunnel. That would give me a working tunnel as quickly as possible. > This is more cumbersome, but is necessary where gateways don't > implement your draft. > > If some of the gateways in the world support your attribute, while > some don't, clients need a way to tell them apart. A notification > (SIMPLE-MOBILITY-SUPPORTED) could help here. > > Yoav > > On May 20, 2008, at 10:29 AM, ns srinivasa murthy wrote: > >> Hi all, >> Please send your comments. >> Thanks >> -nsmurthy >> >> A new version of I-D, >> draft-intoto-simple-mobility-ipsec-clients-00.txt has been >> successfuly submitted by Srinivasa Murthy and posted to the IETF >> repository. >> >> Filename: draft-intoto-simple-mobility-ipsec-clients >> Revision: 00 >> Title: Simple Mobility Solution for IPsec Clients >> Creation_date: 2008-05-18 >> WG ID: Independent Submission >> Number_of_pages: 7 >> >> Abstract: >> One very popular use of VPNs is to provide telecommuter access to >> the corporate Intranet. Remote clients that are behind NAT boxes >> can also access the corporate intranet with the help of the >> standard NAT Traversal feature. >> >> But this access may be disturbed in scenarios where a mobile user >> roams across different points of attachment and there by getting >> assigned with different IP Addresses. The access also fails in >> cases where the client roams across environments with NAT >> to environments without NAT and vice versa. In both the cases >> the tunnel may get re-established but it induces jitter in voice >> sessions. >> >> >> >> >> The IETF Secretariat. >> >> _______________________________________________ >> 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 > --------------010300010303090008060008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

One more: when a client detects that it has moved (e.g. it has a new IP address), it is important that it signals this fact, instead of waiting for the next "real" traffic to be sent over the tunnel. Otherwise the gateway will not know about the address change and the client will not be reachable from the network side, possibly for a long time. One option is for the client to generate a DPD message. RFC 4555, Sec. 2.1 has more background about movement detection.


Thanks,

    Yaron


Yoav Nir wrote:

Hi

I think this draft may be very useful, and I have a few comments:

1. NAT Detection payloads, as defined in the relevant RFCs have a payload that is the output of a SHA-1 function, so the payload length is 28 bytes. Implementations will verify this length as part of a packet sanity check.  I suggest that you keep the payload with length 28, and fill it with something random-looking rather than sending a zero length payload.  You may even want to specify a 20-byte string (maybe the SHA-1 hash of "draft-intoto-simple-mobility-ipsec-clients").

2. There is no signaling in the protocol of compliance with this specification.  Section 4 of your draft details some gateway behavior, but a compliant client has no way of knowing whether the gateway is compliant.

Suppose I were now writing a client that should connect to any RFC4306-compliant gateway, but does not support MOBIKE. I might use a protocol such as STUN to detect when my IP address changes. When that happens, I would begin an INITIAL exchange, and tear down the previous tunnel. That would give me a working tunnel as quickly as possible. This is more cumbersome, but is necessary where gateways don't implement your draft.

If some of the gateways in the world support your attribute, while some don't, clients need a way to tell them apart.  A notification (SIMPLE-MOBILITY-SUPPORTED) could help here.

Yoav

On May 20, 2008, at 10:29 AM, ns srinivasa murthy wrote:

Hi all,
Please send your comments.
Thanks
-nsmurthy

A new version of I-D, draft-intoto-simple-mobility-ipsec-clients-00.txt has been successfuly submitted by Srinivasa Murthy and posted to the IETF repository.

Filename:        draft-intoto-simple-mobility-ipsec-clients
Revision:       00
Title:           Simple Mobility Solution for IPsec Clients
Creation_date:  2008-05-18
WG ID:           Independent Submission
Number_of_pages: 7

Abstract:
One very popular use of VPNs is to provide telecommuter access to
the corporate Intranet. Remote clients that are behind NAT boxes
can also access the corporate intranet with the help of the
standard NAT Traversal feature.

But this access may be disturbed in scenarios where a mobile user
roams across different points of attachment and there by getting
assigned with different IP Addresses. The access also fails in
cases where the client roams across environments with NAT
to environments without NAT and vice versa. In both the cases
the tunnel may get re-established but it induces jitter in voice
sessions.
                                                                                 


The IETF Secretariat.

_______________________________________________
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
--------------010300010303090008060008-- --===============2023021414== 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 --===============2023021414==-- From ipsec-bounces@ietf.org Tue May 20 20:51: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 F16C628C249; Tue, 20 May 2008 20:51: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 EB08928C425 for ; Tue, 20 May 2008 20:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQ4EsifPl6Rq for ; Tue, 20 May 2008 20:51:02 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id C73873A7040 for ; Tue, 20 May 2008 11:35:54 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m4KIZrCi026061 for ; Tue, 20 May 2008 14:35:53 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m4KIZoOg145180 for ; Tue, 20 May 2008 14:35:50 -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 m4KIZo6k025164 for ; Tue, 20 May 2008 14:35:50 -0400 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m4KIZnY4025138; Tue, 20 May 2008 14:35:49 -0400 Received: from faith.austin.ibm.com (faith.austin.ibm.com [9.53.40.35]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id m4KIZnMU028176; Tue, 20 May 2008 13:35:49 -0500 Received: from faith.austin.ibm.com (localhost.localdomain [127.0.0.1]) by faith.austin.ibm.com (8.14.2/8.12.8) with ESMTP id m4KIAC8h024494; Tue, 20 May 2008 13:10:12 -0500 Received: (from jml@localhost) by faith.austin.ibm.com (8.14.2/8.14.2/Submit) id m4KIABdD024493; Tue, 20 May 2008 13:10:11 -0500 Date: Tue, 20 May 2008 13:10:11 -0500 From: Joy Latten Message-Id: <200805201810.m4KIABdD024493@faith.austin.ibm.com> To: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Here are my choices: [R] Update to IKEv2 base specification (possible starting point: draft-hoffman-ikev2bis) [R] IPsec document roadmap update (possible starting point: RFC 2411) [C] Labeled IPsec for RFC 430x IPsec I have already started on internet draft for labeled ipsec. If indiviual draft is more appropriate process mechanism I am fine with that. regards, Joy Latten IBM Linux Technology Center _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 20 21:06: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 25A463A7144; Tue, 20 May 2008 21:06: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 084CC3A701D for ; Tue, 20 May 2008 21:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 uxkEp-eXxMK4 for ; Tue, 20 May 2008 21:06:05 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 4C79C28E29D for ; Tue, 20 May 2008 13:17:03 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JyYGb-0007f2-6J; Tue, 20 May 2008 16:17:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <6525A993506152478BA085F87670DFF305E18FED@zcp4hxm0.corp.nortel.com> References: <6525A993506152478BA085F87670DFF305E18FED@zcp4hxm0.corp.nortel.com> Date: Tue, 20 May 2008 16:10:22 -0400 To: "Gaurav Nagare" From: Stephen Kent Cc: ipsec@ietf.org Subject: Re: [IPsec] VPN policy encrypts traffic between the router and the local network 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="===============1296746339==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1296746339== Content-Type: multipart/alternative; boundary="============_-1000807864==_ma============" --============_-1000807864==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C8B0F6.CA652E59" > >Hi, >Here is the setup for this issue > > ____ >_____ > | | >| | >192.168.0.0/16--------------- >|SGW1|-----------------------------------|SGW2|------------192.168.11.0/24 > (Network) |_____ |20.1.1.20 >20.1.1.21|_____| (network) > > > >There is a VPN policy in tunnel mode between SGW1 and SGW2. the VPN >tunnel is setup with two networks, 192.168.0.0/16(kind of supernet) >and 192.168.11.0/24. > >Now, once the IPsec policy in enabled, client on network >192.168.11.0/24 is not able to access the local router interface and >trafic between local network and router is also encrypted. However >the router allows IPsec traffic to pass to a peer on network >192.168.0.0/16. > >I am not sure if this behaviour is acceptable or the router should >be accessible from local network. Please let me know your comments. > > >Regards, >Gaurav If properly implemented and configured, the IPsec policy you described above should not affect the ability of a client on the /24 net to send traffic to any addresses on that local net. You say that traffic from the client to local router is encrypted. I assume u=you mean encrypted using IPsec. If so, that requires that the IPsec implementation in the client is enabled, and that the SPD in the client calls for such encryption. So, I think you have omitted a significant part of the description of the context above. Steve --============_-1000807864==_ma============ Content-Type: text/html; charset="us-ascii" Re: [IPsec] VPN policy encrypts traffic between the router
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
  boundary="----_=_NextPart_001_01C8B0F6.CA652E59"
Hi,
Here is the setup for this issue
                                       ____                                       _____
                                     |          |                                   |          |
192.168.0.0/16--------------- |SGW1|-----------------------------------|SGW2|------------192.168.11.0/24
 (Network)                       |_____ |20.1.1.20         20.1.1.21|_____|            (network)


There is a VPN policy in tunnel mode between SGW1 and SGW2. the VPN tunnel is setup with two networks, 192.168.0.0/16(kind of supernet) and 192.168.11.0/24.
Now, once the IPsec policy in enabled, client on network 192.168.11.0/24 is not able to access the local router interface and trafic between local network and router is also encrypted. However the router allows IPsec traffic to pass to a peer on network 192.168.0.0/16.
I am not sure if this behaviour is acceptable or the router should be accessible from local network. Please let me know your comments.

Regards,
Gaurav

If properly implemented and configured, the IPsec policy you described above should not affect the ability of a client on the /24 net to send traffic to any addresses on that local net.

You say that traffic from the client to local router is encrypted. I assume u=you mean encrypted using IPsec. If so, that requires that the IPsec implementation in the client is enabled, and that the SPD in the client calls for such encryption. So, I think you have omitted a significant part of the description of the context above.

Steve
--============_-1000807864==_ma============-- --===============1296746339== 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 --===============1296746339==-- From ipsec-bounces@ietf.org Tue May 20 22:22: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 DBB253A6854; Tue, 20 May 2008 22:22: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 5679D3A6857 for ; Tue, 20 May 2008 22:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOg+DI7fLSlV for ; Tue, 20 May 2008 22:21:59 -0700 (PDT) Received: from barracuda.intoto.com (unknown [66.88.133.2]) by core3.amsl.com (Postfix) with ESMTP id 36FE53A6842 for ; Tue, 20 May 2008 22:21:59 -0700 (PDT) Received: from brahma.hyd.intoto.com (unknown [172.16.1.10]) by barracuda.intoto.com (Spam Firewall) with ESMTP id AC5B11E080; Tue, 20 May 2008 22:22:00 -0700 (PDT) Received: from nsm.intoto.com (4mc90.hyd.intoto.com [172.16.4.90]) by brahma.hyd.intoto.com (8.13.1/8.13.1) with ESMTP id m4L5LvCU008653; Wed, 21 May 2008 10:51:58 +0530 Message-Id: <7.0.1.0.1.20080521104418.04d7dd88@intoto.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 21 May 2008 11:04:24 +0530 To: Yoav Nir From: ns srinivasa murthy In-Reply-To: <478E71AE-05CD-4540-B188-90F0411EBC4E@checkpoint.com> References: <7.0.1.0.1.20080520125756.04a68188@intoto.com> <478E71AE-05CD-4540-B188-90F0411EBC4E@checkpoint.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.62 on 172.16.1.10 Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-intoto-simple-mobility-ipsec-clients-00 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="===============1413573496==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1413573496== Content-Type: multipart/alternative; boundary="=====================_4893578==.ALT" --=====================_4893578==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Thanks for the feedback.Please find my responses embedded with nsmurthy> -nsmurthy At 02:05 PM 5/20/2008, Yoav Nir wrote: >Hi > >I think this draft may be very useful, and I have a few comments: > >1. NAT Detection payloads, as defined in the relevant RFCs have a >payload that is the output of a SHA-1 function, so the payload >length is 28 bytes. Implementations will verify this length as part >of a packet sanity check. I suggest that you keep the payload with >length 28, and fill it with something random-looking rather than >sending a zero length payload. You may even want to specify a >20-byte string (maybe the SHA-1 hash of >"draft-intoto-simple-mobility-ipsec-clients"). nsmurthy> My idea was to keep the payload length at 28 only but fill it up with zeroes to avoid any remote possibility of a match. >2. There is no signaling in the protocol of compliance with this >specification. Section 4 of your draft details some gateway >behavior, but a compliant client has no way of knowing whether the >gateway is compliant. > >Suppose I were now writing a client that should connect to any >RFC4306-compliant gateway, but does not support MOBIKE. I might use >a protocol such as STUN to detect when my IP address changes. When >that happens, I would begin an INITIAL exchange, and tear down the >previous tunnel. That would give me a working tunnel as quickly as >possible. This is more cumbersome, but is necessary where gateways >don't implement your draft. > >If some of the gateways in the world support your attribute, while >some don't, clients need a way to tell them apart. A notification >(SIMPLE-MOBILITY-SUPPORTED) could help here. nsmurthy> Yes you are right.In case of IKEv2,a notification (SIMPLE-MOBILITY-SUPPORTED) can be sent in messages 3 and 4 to announce the support. >Yoav > >On May 20, 2008, at 10:29 AM, ns srinivasa murthy wrote: > >>Hi all, >>Please send your comments. >>Thanks >>-nsmurthy >> >>A new version of I-D, >>draft-intoto-simple-mobility-ipsec-clients-00.txt has been >>successfuly submitted by Srinivasa Murthy and posted to the IETF repository. >> >>Filename: draft-intoto-simple-mobility-ipsec-clients >>Revision: 00 >>Title: Simple Mobility Solution for IPsec Clients >>Creation_date: 2008-05-18 >>WG ID: Independent Submission >>Number_of_pages: 7 >> >>Abstract: >>One very popular use of VPNs is to provide telecommuter access to >>the corporate Intranet. Remote clients that are behind NAT boxes >>can also access the corporate intranet with the help of the >>standard NAT Traversal feature. >> >>But this access may be disturbed in scenarios where a mobile user >>roams across different points of attachment and there by getting >>assigned with different IP Addresses. The access also fails in >>cases where the client roams across environments with NAT >>to environments without NAT and vice versa. In both the cases >>the tunnel may get re-established but it induces jitter in voice >>sessions. >> >> >> >> >>The IETF Secretariat. >> >>_______________________________________________ >>IPsec mailing list >>IPsec@ietf.org >>https://www.ietf.org/mailman/listinfo/ipsec > ******************************************************************************** This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. --=====================_4893578==.ALT Content-Type: text/html; charset="us-ascii"
Thanks for the feedback.Please find my responses embedded with nsmurthy>

-nsmurthy


At 02:05 PM 5/20/2008, Yoav Nir wrote:
Hi

I think this draft may be very useful, and I have a few comments:

1. NAT Detection payloads, as defined in the relevant RFCs have a payload that is the output of a SHA-1 function, so the payload length is 28 bytes. Implementations will verify this length as part of a packet sanity check.  I suggest that you keep the payload with length 28, and fill it with something random-looking rather than sending a zero length payload.  You may even want to specify a 20-byte string (maybe the SHA-1 hash of "draft-intoto-simple-mobility-ipsec-clients").

nsmurthy>
My idea was to keep the payload length at 28 only but fill it up with zeroes to avoid any remote possibility of a match.


2. There is no signaling in the protocol of compliance with this specification.  Section 4 of your draft details some gateway behavior, but a compliant client has no way of knowing whether the gateway is compliant.

Suppose I were now writing a client that should connect to any RFC4306-compliant gateway, but does not support MOBIKE. I might use a protocol such as STUN to detect when my IP address changes. When that happens, I would begin an INITIAL exchange, and tear down the previous tunnel. That would give me a working tunnel as quickly as possible. This is more cumbersome, but is necessary where gateways don't implement your draft.

If some of the gateways in the world support your attribute, while some don't, clients need a way to tell them apart.  A notification (SIMPLE-MOBILITY-SUPPORTED) could help here.

nsmurthy>
Yes you are right.In case of IKEv2,a notification             (SIMPLE-MOBILITY-SUPPORTED) can be sent in messages 3 and 4 to announce the support.


Yoav

On May 20, 2008, at 10:29 AM, ns srinivasa murthy wrote:

Hi all,
Please send your comments.
Thanks
-nsmurthy

A new version of I-D, draft-intoto-simple-mobility-ipsec-clients-00.txt has been successfuly submitted by Srinivasa Murthy and posted to the IETF repository.

Filename:        draft-intoto-simple-mobility-ipsec-clients
Revision:       00
Title:           Simple Mobility Solution for IPsec Clients
Creation_date:  2008-05-18
WG ID:           Independent Submission
Number_of_pages: 7

Abstract:
One very popular use of VPNs is to provide telecommuter access to
the corporate Intranet. Remote clients that are behind NAT boxes
can also access the corporate intranet with the help of the
standard NAT Traversal feature.

But this access may be disturbed in scenarios where a mobile user
roams across different points of attachment and there by getting
assigned with different IP Addresses. The access also fails in
cases where the client roams across environments with NAT
to environments without NAT and vice versa. In both the cases
the tunnel may get re-established but it induces jitter in voice
sessions.
                                                                                 


The IETF Secretariat.

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


--=====================_4893578==.ALT-- --===============1413573496== 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 --===============1413573496==-- From ipsec-bounces@ietf.org Tue May 20 22:31: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 B8B8C3A686A; Tue, 20 May 2008 22:31: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 BFA693A6823 for ; Tue, 20 May 2008 22:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtWCFbfsl5e4 for ; Tue, 20 May 2008 22:31:19 -0700 (PDT) Received: from barracuda.intoto.com (unknown [66.88.133.2]) by core3.amsl.com (Postfix) with ESMTP id 8925D3A67AB for ; Tue, 20 May 2008 22:31:19 -0700 (PDT) Received: from brahma.hyd.intoto.com (unknown [172.16.1.10]) by barracuda.intoto.com (Spam Firewall) with ESMTP id DB31A43BEE; Tue, 20 May 2008 22:31:20 -0700 (PDT) Received: from nsm.intoto.com (4mc90.hyd.intoto.com [172.16.4.90]) by brahma.hyd.intoto.com (8.13.1/8.13.1) with ESMTP id m4L5VHXU011579; Wed, 21 May 2008 11:01:18 +0530 Message-Id: <7.0.1.0.1.20080521110539.04d1dbd0@intoto.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 21 May 2008 11:13:44 +0530 To: Yaron Sheffer , Yoav Nir From: ns srinivasa murthy In-Reply-To: <4832BBD3.7020304@checkpoint.com> References: <7.0.1.0.1.20080520125756.04a68188@intoto.com> <478E71AE-05CD-4540-B188-90F0411EBC4E@checkpoint.com> <4832BBD3.7020304@checkpoint.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.62 on 172.16.1.10 Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-intoto-simple-mobility-ipsec-clients-00 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="===============2067987106==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2067987106== Content-Type: multipart/alternative; boundary="=====================_5454375==.ALT" --=====================_5454375==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed The draft listed this as a limitation and it assumes that "packets from server are lost until client sends atleast one packet with the new IP Address". To overcome this ,the client can send a notification with an empty payload whenever its IP Address changes.The notification pay load may be just empty as the server adapts the IP Address from the packet it received. Thank you -nsmurthy At 05:23 PM 5/20/2008, Yaron Sheffer wrote: >One more: when a client detects that it has moved (e.g. it has a new >IP address), it is important that it signals this fact, instead of >waiting for the next "real" traffic to be sent over the tunnel. >Otherwise the gateway will not know about the address change and the >client will not be reachable from the network side, possibly for a >long time. One option is for the client to generate a DPD message. >RFC 4555, Sec. 2.1 has more background about movement detection. > > >Thanks, > > Yaron > > >Yoav Nir wrote: >>Hi >> >>I think this draft may be very useful, and I have a few comments: >> >>1. NAT Detection payloads, as defined in the relevant RFCs have a >>payload that is the output of a SHA-1 function, so the payload >>length is 28 bytes. Implementations will verify this length as part >>of a packet sanity check. I suggest that you keep the payload with >>length 28, and fill it with something random-looking rather than >>sending a zero length payload. You may even want to specify a >>20-byte string (maybe the SHA-1 hash of >>"draft-intoto-simple-mobility-ipsec-clients"). >> >>2. There is no signaling in the protocol of compliance with this >>specification. Section 4 of your draft details some gateway >>behavior, but a compliant client has no way of knowing whether the >>gateway is compliant. >> >>Suppose I were now writing a client that should connect to any >>RFC4306-compliant gateway, but does not support MOBIKE. I might use >>a protocol such as STUN to detect when my IP address changes. When >>that happens, I would begin an INITIAL exchange, and tear down the >>previous tunnel. That would give me a working tunnel as quickly as >>possible. This is more cumbersome, but is necessary where gateways >>don't implement your draft. >> >>If some of the gateways in the world support your attribute, while >>some don't, clients need a way to tell them apart. A notification >>(SIMPLE-MOBILITY-SUPPORTED) could help here. >> >>Yoav >> >>On May 20, 2008, at 10:29 AM, ns srinivasa murthy wrote: >> >>>Hi all, >>>Please send your comments. >>>Thanks >>>-nsmurthy >>> >>>A new version of I-D, >>>draft-intoto-simple-mobility-ipsec-clients-00.txt has been >>>successfuly submitted by Srinivasa Murthy and posted to the IETF repository. >>> >>>Filename: draft-intoto-simple-mobility-ipsec-clients >>>Revision: 00 >>>Title: Simple Mobility Solution for IPsec Clients >>>Creation_date: 2008-05-18 >>>WG ID: Independent Submission >>>Number_of_pages: 7 >>> >>>Abstract: >>>One very popular use of VPNs is to provide telecommuter access to >>>the corporate Intranet. Remote clients that are behind NAT boxes >>>can also access the corporate intranet with the help of the >>>standard NAT Traversal feature. >>> >>>But this access may be disturbed in scenarios where a mobile user >>>roams across different points of attachment and there by getting >>>assigned with different IP Addresses. The access also fails in >>>cases where the client roams across environments with NAT >>>to environments without NAT and vice versa. In both the cases >>>the tunnel may get re-established but it induces jitter in voice >>>sessions. >>> >>> >>> >>> >>>The IETF Secretariat. >>> >>>_______________________________________________ >>>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 >> ******************************************************************************** This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. --=====================_5454375==.ALT Content-Type: text/html; charset="us-ascii"
The draft listed this as a limitation and it assumes that "packets from server are lost until client sends atleast one packet with the
new IP Address".

To overcome this ,the client can send a notification with an empty payload whenever its IP Address changes.The notification pay load may be just empty as the server adapts the IP Address from the packet it received.

Thank you
-nsmurthy

At 05:23 PM 5/20/2008, Yaron Sheffer wrote:

One more: when a client detects that it has moved (e.g. it has a new IP address), it is important that it signals this fact, instead of waiting for the next "real" traffic to be sent over the tunnel. Otherwise the gateway will not know about the address change and the client will not be reachable from the network side, possibly for a long time. One option is for the client to generate a DPD message. RFC 4555, Sec. 2.1 has more background about movement detection.


Thanks,

    Yaron


Yoav Nir wrote:
Hi

I think this draft may be very useful, and I have a few comments:

1. NAT Detection payloads, as defined in the relevant RFCs have a payload that is the output of a SHA-1 function, so the payload length is 28 bytes. Implementations will verify this length as part of a packet sanity check.  I suggest that you keep the payload with length 28, and fill it with something random-looking rather than sending a zero length payload.  You may even want to specify a 20-byte string (maybe the SHA-1 hash of "draft-intoto-simple-mobility-ipsec-clients").

2. There is no signaling in the protocol of compliance with this specification.  Section 4 of your draft details some gateway behavior, but a compliant client has no way of knowing whether the gateway is compliant.

Suppose I were now writing a client that should connect to any RFC4306-compliant gateway, but does not support MOBIKE. I might use a protocol such as STUN to detect when my IP address changes. When that happens, I would begin an INITIAL exchange, and tear down the previous tunnel. That would give me a working tunnel as quickly as possible. This is more cumbersome, but is necessary where gateways don't implement your draft.

If some of the gateways in the world support your attribute, while some don't, clients need a way to tell them apart.  A notification (SIMPLE-MOBILITY-SUPPORTED) could help here.

Yoav

On May 20, 2008, at 10:29 AM, ns srinivasa murthy wrote:

Hi all,
Please send your comments.
Thanks
-nsmurthy

A new version of I-D, draft-intoto-simple-mobility-ipsec-clients-00.txt has been successfuly submitted by Srinivasa Murthy and posted to the IETF repository.

Filename:        draft-intoto-simple-mobility-ipsec-clients
Revision:       00
Title:           Simple Mobility Solution for IPsec Clients
Creation_date:  2008-05-18
WG ID:           Independent Submission
Number_of_pages: 7

Abstract:
One very popular use of VPNs is to provide telecommuter access to
the corporate Intranet. Remote clients that are behind NAT boxes
can also access the corporate intranet with the help of the
standard NAT Traversal feature.

But this access may be disturbed in scenarios where a mobile user
roams across different points of attachment and there by getting
assigned with different IP Addresses. The access also fails in
cases where the client roams across environments with NAT
to environments without NAT and vice versa. In both the cases
the tunnel may get re-established but it induces jitter in voice
sessions.
                                                                                 


The IETF Secretariat.

_______________________________________________
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
 

--=====================_5454375==.ALT-- --===============2067987106== 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 --===============2067987106==-- From ipsec-bounces@ietf.org Wed May 21 00:12: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 8AE963A6924; Wed, 21 May 2008 00:12: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 2A9903A6931 for ; Wed, 21 May 2008 00:12:49 -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 PLwwFIlfjYd6 for ; Wed, 21 May 2008 00:12:45 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3198828C1DC for ; Wed, 21 May 2008 00:12:38 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 91FAF294002; Wed, 21 May 2008 10:12:36 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 42B07294003; Wed, 21 May 2008 10:12:30 +0300 (IDT) Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id m4L7CTjP024595; Wed, 21 May 2008 10:12:29 +0300 (IDT) Message-Id: From: Yoav Nir To: ns srinivasa murthy In-Reply-To: <7.0.1.0.1.20080521110539.04d1dbd0@intoto.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 21 May 2008 10:12:25 +0300 References: <7.0.1.0.1.20080520125756.04a68188@intoto.com> <478E71AE-05CD-4540-B188-90F0411EBC4E@checkpoint.com> <4832BBD3.7020304@checkpoint.com> <7.0.1.0.1.20080521110539.04d1dbd0@intoto.com> X-Mailer: Apple Mail (2.919.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-intoto-simple-mobility-ipsec-clients-00 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="===============0951589338==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0951589338== Content-Type: multipart/signed; boundary=Apple-Mail-2--1028971926; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-2--1028971926 Content-Type: multipart/alternative; boundary=Apple-Mail-1--1028972053 --Apple-Mail-1--1028972053 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit An empty informational with no payloads is exactly what's called a "liveness check" in IKEv2 and sometimes called DPD. On May 21, 2008, at 8:43 AM, ns srinivasa murthy wrote: > > The draft listed this as a limitation and it assumes that "packets > from server are lost until client sends atleast one packet with the > new IP Address". > > To overcome this ,the client can send a notification with an empty > payload whenever its IP Address changes.The notification pay load > may be just empty as the server adapts the IP Address from the > packet it received. > > Thank you > -nsmurthy > > At 05:23 PM 5/20/2008, Yaron Sheffer wrote: > >> One more: when a client detects that it has moved (e.g. it has a >> new IP address), it is important that it signals this fact, instead >> of waiting for the next "real" traffic to be sent over the tunnel. >> Otherwise the gateway will not know about the address change and >> the client will not be reachable from the network side, possibly >> for a long time. One option is for the client to generate a DPD >> message. RFC 4555, Sec. 2.1 has more background about movement >> detection. >> >> >> Thanks, >> >> Yaron >> >> >> Yoav Nir wrote: >>> Hi >>> >>> I think this draft may be very useful, and I have a few comments: >>> >>> 1. NAT Detection payloads, as defined in the relevant RFCs have a >>> payload that is the output of a SHA-1 function, so the payload >>> length is 28 bytes. Implementations will verify this length as >>> part of a packet sanity check. I suggest that you keep the >>> payload with length 28, and fill it with something random-looking >>> rather than sending a zero length payload. You may even want to >>> specify a 20-byte string (maybe the SHA-1 hash of "draft-intoto- >>> simple-mobility-ipsec-clients"). >>> >>> 2. There is no signaling in the protocol of compliance with this >>> specification. Section 4 of your draft details some gateway >>> behavior, but a compliant client has no way of knowing whether the >>> gateway is compliant. >>> >>> Suppose I were now writing a client that should connect to any >>> RFC4306-compliant gateway, but does not support MOBIKE. I might >>> use a protocol such as STUN to detect when my IP address changes. >>> When that happens, I would begin an INITIAL exchange, and tear >>> down the previous tunnel. That would give me a working tunnel as >>> quickly as possible. This is more cumbersome, but is necessary >>> where gateways don't implement your draft. >>> >>> If some of the gateways in the world support your attribute, while >>> some don't, clients need a way to tell them apart. A notification >>> (SIMPLE-MOBILITY-SUPPORTED) could help here. >>> >>> Yoav >>> >>> On May 20, 2008, at 10:29 AM, ns srinivasa murthy wrote: >>> >>>> Hi all, >>>> Please send your comments. >>>> Thanks >>>> -nsmurthy >>>> >>>> A new version of I-D, draft-intoto-simple-mobility-ipsec- >>>> clients-00.txt has been successfuly submitted by Srinivasa Murthy >>>> and posted to the IETF repository. >>>> >>>> Filename: draft-intoto-simple-mobility-ipsec-clients >>>> Revision: 00 >>>> Title: Simple Mobility Solution for IPsec Clients >>>> Creation_date: 2008-05-18 >>>> WG ID: Independent Submission >>>> Number_of_pages: 7 >>>> >>>> Abstract: >>>> One very popular use of VPNs is to provide telecommuter access to >>>> the corporate Intranet. Remote clients that are behind NAT boxes >>>> can also access the corporate intranet with the help of the >>>> standard NAT Traversal feature. >>>> >>>> But this access may be disturbed in scenarios where a mobile user >>>> roams across different points of attachment and there by getting >>>> assigned with different IP Addresses. The access also fails in >>>> cases where the client roams across environments with NAT >>>> to environments without NAT and vice versa. In both the cases >>>> the tunnel may get re-established but it induces jitter in voice >>>> sessions. >>>> >>>> >>>> >>>> The IETF Secretariat. >>>> >>>> _______________________________________________ >>>> 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 >>> > > > Scanned by Check Point Total Security Gateway. > > --Apple-Mail-1--1028972053 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable An empty informational with no = payloads is exactly what's called a "liveness check" in IKEv2 and = sometimes called DPD.

On May 21, 2008, at 8:43 AM, ns = srinivasa murthy wrote:

=
The draft listed this as a limitation and it = assumes that "packets from server are lost until client sends atleast = one packet with the
new IP Address".

To overcome this ,the = client can send a notification with an empty payload whenever its IP = Address changes.The notification pay load may be just empty as the = server adapts the IP Address from the packet it received.

Thank = you
-nsmurthy

At 05:23 PM 5/20/2008, Yaron Sheffer = wrote:

One more: when a client detects that it has = moved (e.g. it has a new IP address), it is important that it signals = this fact, instead of waiting for the next "real" traffic to be sent = over the tunnel. Otherwise the gateway will not know about the address = change and the client will not be reachable from the network side, = possibly for a long time. One option is for the client to generate a DPD = message. RFC 4555, Sec. 2.1 has more background about movement = detection.


Thanks,

    Yaron

=
Yoav Nir wrote:
Hi

I think this draft may be very = useful, and I have a few comments:

1. NAT Detection payloads, as = defined in the relevant RFCs have a payload that is the output of a = SHA-1 function, so the payload length is 28 bytes. Implementations will = verify this length as part of a packet sanity check.  I suggest = that you keep the payload with length 28, and fill it with something = random-looking rather than sending a zero length payload.  You may = even want to specify a 20-byte string (maybe the SHA-1 hash of = "draft-intoto-simple-mobility-ipsec-clients").

2. There is no = signaling in the protocol of compliance with this specification.  = Section 4 of your draft details some gateway behavior, but a compliant = client has no way of knowing whether the gateway is compliant.

= Suppose I were now writing a client that should connect to any = RFC4306-compliant gateway, but does not support MOBIKE. I might use a = protocol such as STUN to detect when my IP address changes. When that = happens, I would begin an INITIAL exchange, and tear down the previous = tunnel. That would give me a working tunnel as quickly as possible. This = is more cumbersome, but is necessary where gateways don't implement your = draft.

If some of the gateways in the world support your = attribute, while some don't, clients need a way to tell them = apart.  A notification (SIMPLE-MOBILITY-SUPPORTED) could help = here.

Yoav

On May 20, 2008, at 10:29 AM, ns srinivasa = murthy wrote:

Hi all,
Please send your comments.
Thanks
= -nsmurthy

A new version of I-D, = draft-intoto-simple-mobility-ipsec-clients-00.txt has been successfuly = submitted by Srinivasa Murthy and posted to the IETF repository.

= Filename:        = draft-intoto-simple-mobility-ipsec-clients
= Revision:       00
= Title:   =         Simple Mobility = Solution for IPsec Clients
= Creation_date:  2008-05-18
WG = ID:   =         Independent = Submission
Number_of_pages: 7

Abstract:
One very popular = use of VPNs is to provide telecommuter access to
the corporate = Intranet. Remote clients that are behind NAT boxes
can also access = the corporate intranet with the help of the
standard NAT Traversal = feature.

But this access may be disturbed in scenarios where a = mobile user
roams across different points of attachment and there by = getting
assigned with different IP Addresses. The access also fails = in
cases where the client roams across environments with NAT
to = environments without NAT and vice versa. In both the cases
the = tunnel may get re-established but it induces jitter in voice
= sessions.
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =        


The IETF = Secretariat.

_______________________________________________
= 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
 

=
Scanned by Check Point Total Security Gateway.


=

= --Apple-Mail-1--1028972053-- --Apple-Mail-2--1028971926 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3 WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77 BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9 MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDUyMTA3 MTIyNVowIwYJKoZIhvcNAQkEMRYEFG4YKO/PnWyf4xLS7Q9AN9Kv2yIuMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQBYMSZ1n4kz 6YZqWS5/kS18i0ovqSpY0i25VhcZBat98+v5PDjmewN4MdhLbV6VI41fwEsXZxTX8pENMc0TlhJZ 4Ba1l19gnynek4oE92f0EZCvkwUFMi7dUavv5QnV6P7v6UHUCH9RWDNZLjue0quyVLsaucdTecuT 8+dtMCXhgyw60Uvyn02xAGewwnaZqxlLWImSyyG11ioJ5wOFygcmDG1PluXTx73ib8G2sWQPGFzh XdhN18XtDVRBXsUlvbjPqKOkrYgJRdRsmxNAMUuvljodT8WlQlkbBp0xN27T9HI2KIYiVKyeu/io aXDoCc+d+j2wsQvbW1p44j+xLKtQAAAAAAAA --Apple-Mail-2--1028971926-- --===============0951589338== 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 --===============0951589338==-- From ipsec-bounces@ietf.org Wed May 21 00:17: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 899873A692A; Wed, 21 May 2008 00:17: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 2B36C3A68F5 for ; Wed, 21 May 2008 00:17:05 -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 ZCUy0YeVEtNi for ; Wed, 21 May 2008 00:17:04 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id CBB353A68BF for ; Wed, 21 May 2008 00:17:03 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1D5E9294003; Wed, 21 May 2008 10:17:06 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 10DA5294002; Wed, 21 May 2008 10:17:05 +0300 (IDT) Received: from MBP.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m4L7H4jI026459; Wed, 21 May 2008 10:17:04 +0300 (IDT) Message-Id: <862A3ED0-BEE5-427B-9395-9ACCCEDEE647@checkpoint.com> From: Yoav Nir To: ns srinivasa murthy In-Reply-To: <7.0.1.0.1.20080521104418.04d7dd88@intoto.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 21 May 2008 10:17:03 +0300 References: <7.0.1.0.1.20080520125756.04a68188@intoto.com> <478E71AE-05CD-4540-B188-90F0411EBC4E@checkpoint.com> <7.0.1.0.1.20080521104418.04d7dd88@intoto.com> X-Mailer: Apple Mail (2.919.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-intoto-simple-mobility-ipsec-clients-00 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="===============0090937048==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0090937048== Content-Type: multipart/signed; boundary=Apple-Mail-4--1028693626; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-4--1028693626 Content-Type: multipart/alternative; boundary=Apple-Mail-3--1028693720 --Apple-Mail-3--1028693720 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On May 21, 2008, at 8:34 AM, ns srinivasa murthy wrote: > > Thanks for the feedback.Please find my responses embedded with > nsmurthy> > > -nsmurthy > > > At 02:05 PM 5/20/2008, Yoav Nir wrote: >> Hi >> >> I think this draft may be very useful, and I have a few comments: >> >> 1. NAT Detection payloads, as defined in the relevant RFCs have a >> payload that is the output of a SHA-1 function, so the payload >> length is 28 bytes. Implementations will verify this length as part >> of a packet sanity check. I suggest that you keep the payload with >> length 28, and fill it with something random-looking rather than >> sending a zero length payload. You may even want to specify a 20- >> byte string (maybe the SHA-1 hash of "draft-intoto-simple-mobility- >> ipsec-clients"). > > nsmurthy> > My idea was to keep the payload length at 28 only but fill it up > with zeroes to avoid any remote possibility of a match. In that case, I suggest clarify that in the next version. Also it's possible to use an all-zeros NAT detection as an indication of protocol support. Yoav --Apple-Mail-3--1028693720 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On May 21, 2008, = at 8:34 AM, ns srinivasa murthy wrote:

=
Thanks for the feedback.Please find my responses = embedded with nsmurthy>

-nsmurthy


At 02:05 PM = 5/20/2008, Yoav Nir wrote:
Hi

I think this draft = may be very useful, and I have a few comments:

1. NAT Detection = payloads, as defined in the relevant RFCs have a payload that is the = output of a SHA-1 function, so the payload length is 28 bytes. = Implementations will verify this length as part of a packet sanity = check.  I suggest that you keep the payload with length 28, and = fill it with something random-looking rather than sending a zero length = payload.  You may even want to specify a 20-byte string (maybe the = SHA-1 hash of "draft-intoto-simple-mobility-ipsec-clients"). =

nsmurthy>
My idea was to keep the payload length = at 28 only but fill it up with zeroes to avoid any remote possibility of = a match.

In that case, I suggest = clarify that in the next version. Also it's possible to use an all-zeros = NAT detection as an indication of  protocol = support.

Yoav

= --Apple-Mail-3--1028693720-- --Apple-Mail-4--1028693626 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGJzCCAuAw ggJJoAMCAQICEAJIh/K+B1TMJ8nzoNjVff4wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDkwNDEzMzAzN1oXDTA4MDkwMzEzMzAz N1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAGCSqGSIb3DQEJARYTeW5p ckBjaGVja3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANk5dX7Jjgb3 WcWBXGkva0ksYj49cHGta9zLei/8L36hnOgHfChX7jMU1scWGg4fA6v43SGB32/bjtioMt4FDazd MR/yqYykPSZ82X6MIDd/hqXJy2kWlLEzELy4UymxoBtZV0Woea0gO4rObjgQDf2JsacEt9Qxi+77 BA3W931iG2sjue0KdRx6xX3U1pwgx0M81fZ54gFgAhMlCf8AVqCgL6bv+HYAc2j4XjSGFjODjNyp n2Pumc9TVkj2uxmV+mMtclIhbXPy/5z0wg83ttnIfcI9cTKI88407fHTaUKmXf4Vhdp/NhbuHZWH bCBOMP0AiefcmvdGfqJc7o3JOYsCAwEAAaMwMC4wHgYDVR0RBBcwFYETeW5pckBjaGVja3BvaW50 LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADEczlw8AJPiBRktBh113TwJrqL9 MeyaI+FB1yFUamAtd1i/Db0l9Xeb6iOK1M/MWwLbXTWBWxwhe3q7sayp8BZPJsLfBDyb1MYi8yGC ieBEatY6nP1Yy9KELX8frAfJ038FFw/rP2IqvUa2gxS0LW0vrgOg8hB1fRAUTlOr3MSDMIIDPzCC AqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDE pjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J 8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+n ttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4 oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmww CwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODAN BgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0 HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghO rvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhACSIfyvgdUzCfJ86DY1X3+MAkGBSsOAwIa BQCgggFvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDUyMTA3 MTcwNFowIwYJKoZIhvcNAQkEMRYEFIYQD2mZku7Cs8oZ7IDPYSeT/bdgMIGFBgkrBgEEAYI3EAQx eDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQAkiH8r4HVMwn yfOg2NV9/jCBhwYLKoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQAkiH8r4HVMwnyfOg2NV9/jANBgkqhkiG9w0BAQEFAASCAQBfjJ7Et4+s WU5JOT56lrCJYSGFDxEFXskOTLa5NSCAWBr4PSMrS5pqgsKED3pIWQKHYJq+Ej1PalRHzIkhoA1m CcXGGFUnSoQfu5r3KaSHV3qm0uoQgmAM5VTMcLnAqFPo7Cb8WlpS1VlvwX8z22BD5MJmIIEerQu3 ELFFeAccfZSBYp4IOIbYOaXhKPlSIahT064Tu9Ka8Uad2vpIoK5VFxx2zHAI8u89Eah+ASJ0XEgH lGSXoKhNE30h/fFDs3nN1ayP8qdyATNo5PFss6e03ufuvjcRtQwIGvg4tCBqyHyIr4Tltna4fgPV nc64cINkb2gk2OsHwEegKGruoSL8AAAAAAAA --Apple-Mail-4--1028693626-- --===============0090937048== 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 --===============0090937048==-- From ipsec-bounces@ietf.org Wed May 21 00:43: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 05ED83A6931; Wed, 21 May 2008 00:43: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 034F53A6931 for ; Wed, 21 May 2008 00:42: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=[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 bYCjUvDJ8uc3 for ; Wed, 21 May 2008 00:42:58 -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 DD51F3A6924 for ; Wed, 21 May 2008 00:42:57 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so2637192fkq.5 for ; Wed, 21 May 2008 00:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=UwXeTYRCzMFzygpMY0C6utjObudSyVDY3+k8EDuICvk=; b=OObNgYThcl77wVFEeG1wJ7FzLX5i4AI0aV7L4J1hxUq+Afp8qInUcjEyxtRdMSbXyCEpyEKOR2eg9mxdKAN/X+gFXdRSetUa0wDvzMZ8rHmEyJRN4UJ7KSd6HWvqGn9AgON6DmTIK63HTfLRUl0uBcvkInChNwdN6hbp446zIQY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=Ik/OKO9s8QJYqSu5UqkYTxz48TXWisikNc/Eg2RniCVQaNbSwMdPKfpBMv3Dw+9OIG/abdjqZde+LZOyI1uqvpyKp8iklfytdaFW+DlTW1jfW1cvnUN6CgX9QGWAE5NVRo6hDCCIMUKPBWCQAPdcoDESAkTZJUJBJaKzPZkjD7Q= Received: by 10.125.107.11 with SMTP id j11mr1967906mkm.179.1211355779798; Wed, 21 May 2008 00:42:59 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id g28sm2958274fkg.1.2008.05.21.00.42.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 May 2008 00:42:58 -0700 (PDT) From: Julien Laganier To: ipsec@ietf.org, Pasi.Eronen@nokia.com Date: Wed, 21 May 2008 09:43:24 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200805210943.24819.julien.IETF@laposte.net> Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 Pasi, Below is my list: [CR] Better IPv6 configuration payloads [CR] Update to IKEv2 base specification [ECR] Other work for making sure IKEv1 and IKEv2 work as well as possible with IPv6, both from standards and operations standpoint (please specify more details if you select this one) => Use of DHCPv6 within an IPsec tunnel to configure an address, DNS, etc. [R] IPsec document roadmap update [R] Running IPsec over TCP [R] IPsec "secure beacon", or detecting whether you need VPN or not [R] Authentication with Cryptographically Generated Addresses (CGA) => as it's been discussed already, a CGA does not provide 'authentication', the IKE and IPsec SA would be unauthenticated, but proof-of-ownership of the CGA could be verified. Thus, this item might fit better in the Better-Than-Nothing-Security WG, which develop exactly that: unauthenticated mode of IPsec. --julien _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 21 05:18: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 C44E73A6A3C; Wed, 21 May 2008 05:18: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 529C73A68BE for ; Wed, 21 May 2008 05:18:05 -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 JhfVRmw-xJeL for ; Wed, 21 May 2008 05:18:00 -0700 (PDT) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.184]) by core3.amsl.com (Postfix) with ESMTP id A5A6E3A69DE for ; Wed, 21 May 2008 05:17:59 -0700 (PDT) Received: by gv-out-0910.google.com with SMTP id e6so465366gvc.15 for ; Wed, 21 May 2008 05:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=jupV50KTAAHFdV8H1BlaZ2sT88QUpu002DI0KGuiwEg=; b=SEMsUewTAr70BWCk74YsXiP5LABsIs9po73m8tydJk6Ednbtr457WTWuBkmPs16C3kwckk5+l1sly2cHwkS9V7IRjj69CVNSgnCMZBkG7nDYwrH8wP6aMW1C42MkewhxY1Db7ON+DDdlfMpsWhNoMcTBr+K1yI1ELKhseh0WLig= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=wh4OSkNkjNOboIYiQThtezjd3Yo3GIT30wJCZbSPVc2/RQ9Af6q6L0j0/rgk+moIECM3OaowljLXXcePeMYFE9nG3OTxDYFEeWDJyXkFXF4YjVxAasNJ/ceLr3+KnQXoEt1Ol2lx3AnKOqnX8YSw9KqZHMewsSsWQuN1plT9hok= Received: by 10.125.68.6 with SMTP id v6mr8094733mkk.103.1211372278962; Wed, 21 May 2008 05:17:58 -0700 (PDT) Received: from ubik.local ( [212.119.9.178]) by mx.google.com with ESMTPS id 28sm3627124fkx.8.2008.05.21.05.17.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 May 2008 05:17:57 -0700 (PDT) From: Julien Laganier To: ipsec@ietf.org Date: Wed, 21 May 2008 14:18:22 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <1696498986EFEC4D9153717DA325CB728D5AF2@vaebe104.NOE.Nokia.com> <200805210943.24819.julien.IETF@laposte.net> In-Reply-To: <200805210943.24819.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200805211418.22317.julien.IETF@laposte.net> Cc: Pasi.Eronen@nokia.com Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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 Sorry for posting twice... On Wednesday 21 May 2008, Julien Laganier wrote: > [ECR] Other work for making sure IKEv1 and IKEv2 work as well as > possible with IPv6, both from standards and operations standpoint > (please specify more details if you select this one) > => Use of DHCPv6 within an IPsec tunnel to configure an address, DNS, > etc. and DHCPv6 Prefix Delegation. --julien _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 23 07:08: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 799713A6CB4; Fri, 23 May 2008 07:08: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 69E0D3A6CB3 for ; Fri, 23 May 2008 07:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 smLTZoiDslXB for ; Fri, 23 May 2008 07:08:04 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 7BBDE3A6CB4 for ; Fri, 23 May 2008 07:08:01 -0700 (PDT) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m4NE7uD2002199; Fri, 23 May 2008 10:07:56 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: <58DC945E-3BA0-415E-B282-F9DA701BBC4A@nist.gov> From: Tim Polk Date: Fri, 23 May 2008 10:07:56 -0400 To: ipsec@ietf.org X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Subject: [IPsec] pseudo Last Call: draft-black-ipsec-ikev2-aead-modes-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-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, I have agreed to sponsor publication of the Internet Draft "Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol". As the first step in this process, I am soliciting feedback from the ipsec community in lieu of an official working group Last Call. Assuming positive feedback from this community, I intend to request publication as a Proposed Standard. The current draft is available at http://www.ietf.org/internet-drafts/draft-black-ipsec-ikev2- aead-modes-01.txt Note: this document was subject of David McGrew's second SAAG presentation in Philadelphia. A two week Last Call would close June 6, 2008. I intend to assess the community feedback at that time and make a decision regarding the document's readiness for IETF Last Call. Thanks, Tim Polk _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 23 18:02: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 DA26528C32E; Fri, 23 May 2008 18:02: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 9673828C328 for ; Fri, 23 May 2008 18:02: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=[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 4F-ml5Yl-2aC for ; Fri, 23 May 2008 18:02:19 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id A93D528C32C for ; Fri, 23 May 2008 18:02:18 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so276560and.122 for ; Fri, 23 May 2008 18:02:03 -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=GXle6r0PiehtQ9jZYmQt5yRrlsg+JiFw2/DyyQd3HxA=; b=SbJ/PEPNK3sb6UCEKMEWvxroWouwjJpWQPeduZXx7W1RjXoO7l08W1qa6Lc/GlxbOEhn5FqB8ZAclghFkK9OxpDP0pikZwbqGqPCwV/qlfulNNlKeQe+bDiIRIhXHSZj3KqMes9ZyBfdUwiAyNzz74wM432C8sd/0xly3QbrOMs= 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=RXLse+bjORXKv0sA0+gIwfgZGOI/onCceApEOPoC+DiWS5RbGZwBqAvi/NFboMATSQCDmvPWBhNk4xRWfQCZRzRbpXntbwZUrbwieRksVVyzc+wN+Fg8kf/re+ZRvj0c+ri09zgNO44Tqms930A9UbdxGHz+Vi6iTM1NKdVz2Ck= Received: by 10.100.45.5 with SMTP id s5mr3175517ans.13.1211590923708; Fri, 23 May 2008 18:02:03 -0700 (PDT) Received: by 10.100.191.4 with HTTP; Fri, 23 May 2008 18:02:03 -0700 (PDT) Message-ID: Date: Fri, 23 May 2008 18:02:03 -0700 From: "fan zhao" To: "Vijay Devarapallli" MIME-Version: 1.0 Content-Disposition: inline Cc: ipsec@ietf.org Subject: [IPsec] Comments on re-direct mechanism 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 Dear authors, Thanks for writing this draft. Overall this is a very good and useful draft. Please see some comments below. Abstract "...Currently there is no standard mechanism specified that allows an overloaded VPN gateway to re-direct the VPN client to attach to another gateway...The proposed mechanism can also be used for Mobile IPv6 to enable the home agent to re-direct the mobile node to another home agent." Fan> Load-balancing is a good motivation for this work. The current version describes this issue very well in the following text. IMO, there are other motivation and scenarios that need this redirect mechanism as well, especially those related to Mobile IP operation. For example, re-direct mechanism is useful to ensure a MN to use the same HA/LMA during handover. Assume that a MN powers up and obtains connectivity in a PMIP domain, and later it may handover to another access network where it needs to use DSMIPv6. The MN runs HA discovery and then sets up an IPSec SA with this HA. In order to maintain session continuity, normally the entity that acts as a HA should be the same one that acts as a LMA before handover. This re-direct mechanism is useful in this case because it can reduce handover delay. Fan> Another example is related to multi-homing. For example, a VPN client/MN sets up connectivity to a first network through a VPN gateway/HA. Then the VPN client/MN wants to connect to a second network and discovers a different VPN gateway/HA; however the first VPN gateway/HA can be used for the VPN client/MN to access the second network. This redirect mechanism is useful to redirect the client/MN to the first VPN gateway/HA so that the same IPSec SA established before can be re-used, which reduces states and overhead. IMO, these should be captured in various sections, otherwise the usage of this mechanism may be unnecessarily limited to certain scenarios. 1. Introduction "...However, using DNS is not flexible when it comes to assigning a VPN gateway to the VPN client based on the load on the VPN gateways. ..." Fan> This sentence is not wrong; however I felt it may cause confusion because DNS can provide some sort of load-balancing, for example the DNS server can return the IP address of a server selected from a pool based on the round-robin fashion. The real issue IMO is that the DNS is a separate infrastructure and it is practical difficult for network operators to update and advertise additional information to help the VPN client to select an optimal VPN gateway to be used via DNS. Thererfore, such selection made by the client may not be optimal because the client may not have as complete information as the network. Fan> How about the following re-wording: "...Typically, the VPN client tries to connect to the IP address of the VPN gateways that appears first in the DNS response. However, this cannot guarantee a VPN gateway selected is optimal or prefered by the network. Therefore, when the setup of the VPN tunnel to the first VPN gateway fails, e.g. due to this reason, then the VPN client has to try to attach to the other VPN gateways returned in the DNS response, which results in significant delay." "...The re-direct is done during the IKE_SA_INIT exchange. " Fan> IMO, the re-direct can also be done during the IKE_AUTH exchange, during which the client and gateway perform mutual authentication, therefore the threats described in section 6 can be eliminated. Furthermore, to enable load balancing, some network may have policy, like allocating/dedicating certain VPN gateways based on the IDs of VPN clients. Therefore, the re-direct decision can only be made after the ID of VPN client is authenticated. Please see more comments about this below. "The re-direct mechanism can also be used in conjunction with anycast addresses." Fan> To make it clearer, I propose "Besides unicast addresses, the re-direct mechanism can also be used in conjunction with anycast addresses." 3. IKEv2 Exchange with Redirect "The VPN client indicates support for the IKEv2 redirect mechanism by including a REDIRECT_SUPPORTED notification message in the initial IKE_SA_INIT request. If the IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload, the responder MUST NOT send the REDIRECT payload to the VPN client." This REDIRECT_SUPPORTED notification can be useful for compatibility issue. However I am not sure it is needed. Rfc 4306 already describes how to handle un-recongized payload, i.e. if this is a critical payload (the C bit is set) and the payload type is unrecognized, the message MUST be rejected and the response MUST include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD; or if the critical flag is not set and the payload type is unsupported, that payload MUST be ignored. There are at least two cases to consider: an upgraded VPN client (i.e. a client supporting this re-direct mechanism) connects to a legacy VPN gateway (i.e. a gateway with no support of this re-direct mechanism) and a legacy client connects to an upgraded GW. In the following, I assume that if there are multiple VPN GWs in one network, all or none of them are upgraded. If a upgraded client sends to a legacy GW identified by a unicast address, if REDIRECT_SUPPORTED is used and the C bit is set, the legacy GW will reject this request and return UNSUPPORTED_CRITICAL_PAYLOAD. And then client will have to try again with the same or different GW, maybe without REDIRECT_SUPPORTED for this time. On the other hand, if the upgraded client does not include REDIRECT_SUPPORTED, the setup can proceed. Since in this case the GW cannot provide re-direct support anyway, without indicating REDIRECT_SUPPORTED, the signaling procedure can be shortened. If a upgraded client sends to a pool of legacy GWs identified by an anycast address, I think this case is not realistic because if VPN GWs do not support re-direct, then the anycast should not be advertised in the DNS anyway. If a legacy client sends to a upgraded GW identified by a unicast or anycast address, the GW can return the REDIRECT payload. If the C bit is set, the client does not understand; thus it will try another GW. If the C bit is not set, the client can ignore the REDIRECT payload and continue with the procedure. Whether the C bit in the REDIRECT payload should be set or not is up to the configuration of the GW. IMO, when using anycast address, the GW must return a REDIRECT payload with the C bit set in order to discourage the legacy client to continue with the next step. To summarize analysis of all cases, first, I do not think it is necessary to include the REDIRECT_SUPPORTED payload in the message from the client, which only introduces overhead. Second, if the IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload, if supported by the responder, the REDIRECT payload can be returned to the VPN client with the C bit set or unset. In the case the client sends to an anycast address, the C bit must be set. REDIRECTED_FROM I understand the purpose of using the REDIRECTED_FROM payload. However it does not help against potential attacks because an attacker can simply send the first IKE_SA_INIT message without the REDIRECTED_FROM payload, the VPN GW needs to process such a message because this message could be from a legitimate and legacy client. furthermore, this payload causes additional overhead. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 23 18:29: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 C29D928C342; Fri, 23 May 2008 18:29: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 E3D8828C335 for ; Fri, 23 May 2008 18:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id in3qevUtmuCK for ; Fri, 23 May 2008 18:29:50 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by core3.amsl.com (Postfix) with ESMTP id 74AFD28C342 for ; Fri, 23 May 2008 18:29:50 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so278638and.122 for ; Fri, 23 May 2008 18:29: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:content-transfer-encoding:content-disposition:references; bh=eSj/3hA4fN6hmnr/mjlddwUqQvsZ89XUL5LHjaQiUsE=; b=jVcQJA+Y/ettPD1SnfdDANiu15qZCMlO6DopS+5/Q2la1RrGLamIdHNr2V+uhvQNia/Gbf4kb5lNmla3UNLzr9mSKOvR8CoNjSfrsOBBVjrBAzlhe9mRaKNcn81AOPhhdTZjv+GvAzTvURwx6E1lHQWqFr54iy4LuzGzONzN+b0= 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=o3aqW2ZWiuU20N8AHhR6nTEK3pDWWlwF3d4LjUnBDKlwquxJ7phBPDAIm4jY0YOfuKSyPwEM6TQtxtU2Knn9RL/JxX4wMqNfZIkfna5Zm1JkLcGHA2CNKWK5w81E57tYWfCV9LDIgG3RHDBoTCHnAvokN226vBjR6xwYPOCaeZ4= Received: by 10.101.68.19 with SMTP id v19mr3188505ank.75.1211592589342; Fri, 23 May 2008 18:29:49 -0700 (PDT) Received: by 10.100.191.4 with HTTP; Fri, 23 May 2008 18:29:49 -0700 (PDT) Message-ID: Date: Fri, 23 May 2008 18:29:49 -0700 From: "fan zhao" To: "Vijay Devarapallli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: ipsec@ietf.org Subject: Re: [IPsec] Comments on re-direct mechanism 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 Dear all, I apologized for clicking the send button by mistake before I finish formatting/revising. Please ignore the previous email and see my comments below. ----------------------------------------------------------------------------------------------------------------------------- Dear authors, Thanks for writing this draft. Overall this is a very good and useful draft. Please see some comments below. Abstract "...Currently there is no standard mechanism specified that allows an overloaded VPN gateway to re-direct the VPN client to attach to another gateway...The proposed mechanism can also be used for Mobile IPv6 to enable the home agent to re-direct the mobile node to another home agent." Fan> Load-balancing is a good motivation for this work. The current version describes this issue very well in the following text. IMO, there are other motivation and scenarios that need this redirect mechanism as well, especially those related to Mobile IP operation. For example, re-direct mechanism is useful to ensure a MN to use the same HA/LMA during handover. Assume that a MN powers up and obtains connectivity in a PMIP domain, and later it may handover to another access network where it needs to use DSMIPv6. The MN runs HA discovery and then sets up an IPSec SA with this HA. In order to maintain session continuity, normally the entity that acts as a HA should be the same one that acts as a LMA before handover. This re-direct mechanism is useful in this case because it can reduce handover delay. Fan> Another example is related to multi-homing. For example, a VPN client/MN sets up connectivity to a first network through a VPN gateway/HA. Then the VPN client/MN wants to connect to a second network and discovers a different VPN gateway/HA; however the first VPN gateway/HA can be used for the VPN client/MN to access the second network. This redirect mechanism is useful to redirect the client/MN to the first VPN gateway/HA so that the same IPSec SA established before can be re-used, which reduces states and overhead. IMO, these should be captured in various sections, otherwise the usage of this mechanism may be unnecessarily limited to certain scenarios. 1. Introduction "...However, using DNS is not flexible when it comes to assigning a VPN gateway to the VPN client based on the load on the VPN gateways. ..." Fan> This sentence is not wrong; however I felt it may cause confusion because DNS can provide some sort of load-balancing, for example the DNS server can return the IP address of a server selected from a pool based on the round-robin fashion. IMO, DNS is a separate infrastructure and it is practical difficult for network operators to update and advertise additional information to help the VPN client to select an optimal VPN gateway to be used via DNS. Thererfore, such selection made by the client may not be optimal because the client may not have as complete information as the network. Fan> How about the following re-wording: "...Typically, the VPN client tries to connect to the IP address of the VPN gateways that appears first in the DNS response. However, this cannot guarantee a VPN gateway selected is optimal or prefered by the network. Therefore, when the setup of the VPN tunnel to the first VPN gateway fails, e.g. due to this reason, then the VPN client has to try to attach to the other VPN gateways returned in the DNS response, which results in significant delay." "...The re-direct is done during the IKE_SA_INIT exchange. " Fan> IMO, the re-direct can also be done during the IKE_AUTH exchange, during which the client and gateway perform mutual authentication, therefore the threats described in section 6 can be eliminated. Furthermore, to enable load balancing, some network may have policy, like allocating/dedicating certain VPN gateways based on the IDs of VPN clients. Therefore, the re-direct decision can only be made after the ID of VPN client is authenticated. The procedure can look like as follows: The Initiator The Responder HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, REDIRECT} "The re-direct mechanism can also be used in conjunction with anycast addresses." Fan> To make it clearer, I propose "Besides unicast addresses, the re-direct mechanism can also be used in conjunction with anycast addresses." 3. IKEv2 Exchange with Redirect "The VPN client indicates support for the IKEv2 redirect mechanism by including a REDIRECT_SUPPORTED notification message in the initial IKE_SA_INIT request. If the IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload, the responder MUST NOT send the REDIRECT payload to the VPN client." Fan> This REDIRECT_SUPPORTED notification can be useful for compatibility issue. However I am not sure it is needed. Fan> Rfc 4306 already describes how to handle un-recongized payload, i.e. if this is a critical payload (the C bit is set) and the payload type is unrecognized, the message MUST be rejected and the response MUST include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD; or if the critical flag is not set and the payload type is unsupported, that payload MUST be ignored. Fan> There are at least two cases worth further considering: an upgraded VPN client (i.e. a client supporting this re-direct mechanism) connects to a legacy VPN gateway (i.e. a gateway with no support of this re-direct mechanism) and a legacy client connects to an upgraded GW. Fan> In the following, I assume that if there are multiple VPN GWs in one network, all or none of them are upgraded. Fan> If a upgraded client sends to a legacy GW identified by a unicast address, if REDIRECT_SUPPORTED is used and the C bit is set, the legacy GW will reject this request and return UNSUPPORTED_CRITICAL_ PAYLOAD. And then client will have to try again with the same or different GW, maybe without REDIRECT_SUPPORTED for this time. On the other hand, if the upgraded client does not include REDIRECT_SUPPORTED, the setup can proceed. Since in this case the GW cannot provide re- direct support anyway, without indicating REDIRECT_SUPPORTED, the signaling procedure can be shortened. Fan> If a upgraded client sends to a pool of legacy GWs identified by an anycast address, I think this case is not realistic because if VPN GWs do not support re-direct, then the anycast should not be advertised in the DNS anyway. Fan> If a legacy client sends to a upgraded GW identified by a unicast or anycast address, the GW can return the REDIRECT payload. If the C bit is set, the client does not understand; thus it will try another GW. If the C bit is not set, the client can ignore the REDIRECT payload and continue with the procedure. Whether the C bit in the REDIRECT payload should be set or not is up to the configuration of the GW. IMO, when using anycast address, the GW must return a REDIRECT payload with the C bit set in order to discourage the legacy client to continue with the next step. Fan> To summarize analysis of all cases, first, I am not sure it is necessary to include the REDIRECT_SUPPORTED payload in the message from the client, which introduces overhead. Second, if the IKE_SA_INIT request did not include the REDIRECT_SUPPORTED payload, if supported by the responder, the REDIRECT payload can be returned to the VPN client with the C bit set or unset. In the case the client sends to an anycast address, the C bit must be set. REDIRECTED_FROM Fan> I understand the purpose of using the REDIRECTED_FROM payload. IMHO, it does not help against potential attacks because an attacker can simply send the first IKE_SA_INIT message without the REDIRECTED_ FROM payload, the VPN GW needs to process such a message because this message could be from a legitimate and legacy client. Furthermore, this payload causes additional overhead. Thanks again. Look forward to your reply. Sincerely, fan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 23 18:40: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 CFC4428C347; Fri, 23 May 2008 18:40: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 CCA8B28C347 for ; Fri, 23 May 2008 18:40: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 IY7-Z1crMZIZ for ; Fri, 23 May 2008 18:40:20 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id 4CB7F28C344 for ; Fri, 23 May 2008 18:40:19 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so279280and.122 for ; Fri, 23 May 2008 18:40:15 -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:mime-version:content-type:content-transfer-encoding:content-disposition; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=ruXs37Uc8qLP368BeZoyFpF8Wx2T1lj0gzvYQqDhxDvqQkKrDhpdWuRKEVVUr2za3ROT7Z65ptmvipLRcvHKqJCBHRIRNR7lbj8YTq3i1zrzm5FYxcqs6dRr1UyAUL+5yaXwCLNl/+Y3YQe9oiojiEVyzTPxP1rFL3L8vV/usGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=gAKC1LdNNnYqxfK32o60dRZqG8/We51kQmIa8NbYPX5CEvA3b1kHAeG3nzrM9t/JLKErSGcluF3ZSzXRpsmKvJoUxjDvptwdaCN69n7ktzIm1ipqZiM8Rf4OUsdI6bgYUgcAKT3YFO5vLd2NH2TOta61XMiRJT1ohOZw0Ff47wI= Received: by 10.100.33.11 with SMTP id g11mr76919ang.51.1211593215442; Fri, 23 May 2008 18:40:15 -0700 (PDT) Received: by 10.100.191.4 with HTTP; Fri, 23 May 2008 18:40:09 -0700 (PDT) Message-ID: Date: Fri, 23 May 2008 18:40:09 -0700 From: "fan zhao" To: ipsec@ietf.org MIME-Version: 1.0 Content-Disposition: inline Subject: [IPsec] test, please ignore it 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun May 25 23:41: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 2F9983A6A37; Sun, 25 May 2008 23:41: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 3537B3A6A37 for ; Sun, 25 May 2008 23:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+FP8IhiYSip for ; Sun, 25 May 2008 23:41:44 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 12C4D3A6964 for ; Sun, 25 May 2008 23:41:44 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1664208wfd.31 for ; Sun, 25 May 2008 23:41:43 -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:mime-version:content-type:content-transfer-encoding:content-disposition; bh=o8gzQ0L18j9y4Ws38aIAkSAR+SQ/uvwx31reH/HHV2I=; b=Z6q5LuC/VDpDreYqISzp8fiTQJrXBP3IfKzMEcq9pr/hE/a9d+hBOQx6O5RGGedR5j09Nfgim2AB0jG/pxif5lmVDnZJhLPkGLX0LG7lqe075PNK4LKpECNV858CcYTyqEORP9BYofeLINEJoUPkmGm3gk6reeTsB6X/q8EmTfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=wmnn/YCCIym2JaIRF5TAUE8h1g8NNnRTJIfCa0niDoMNl5+cJuet26g+XugU89+z4Ap6ZwCH0b47/3BaJsaXFIYAzN4CCKCK9h+lFmywGsRgzmyiK93gBiZWi5BqwgVLRjYxcIYInqrRcHIELlRNhHZq7WRJ1uF7X9N/UkAlN7c= Received: by 10.142.154.20 with SMTP id b20mr1848569wfe.150.1211784103825; Sun, 25 May 2008 23:41:43 -0700 (PDT) Received: by 10.142.211.11 with HTTP; Sun, 25 May 2008 23:41:43 -0700 (PDT) Message-ID: <4c5c7a6d0805252341r84994d3tf66505ee9ee1fdf9@mail.gmail.com> Date: Mon, 26 May 2008 14:41:43 +0800 From: "Peng Yang" To: ipsec@ietf.org, Pasi.Eronen@nokia.com MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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, Pasi and all: Sorry for late post. [ECR] IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) [ECR] MEXT: interaction between IPsec and Mobile IP, Mobile IP specific extensions to IPsec [ECR] Using GRE "key" header field as IPsec traffic selector (possible starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) Thanks a lot Cheers, Peny My interest list has following items. > > [CR] o Update to IKEv2 base specification (possible starting point: > draft-hoffman-ikev2bis) > > [ECR] o Redirecting a VPN client from one gateway to another > (in a cluster of gateways) > > [CR] o Better IPv6 configuration payloads (possible starting point: > draft-eronen-ipsec-ikev2-ipv6-config) Thanks. Sincerely, fan >>So far, we've had ~20 people who've expressed some form of support >>for creating a WG. This is good -- many current WGs have less than 20 >>people who regularly post to the WG mailing list. >>However, by my count, we've also had ~20 proposals for work items. >>That obviously does not add up. >>I agree with Paul's comment about the WG scope: the WG should work >>on things where having a WG is really needed, and we actually have a >>*group* of people interested on participating. >>Having a WG should not encourage people to develop extensions that >>would not have happened in the absence of a WG (this usually indicates >>they're not widely needed). For some work items that have been >>proposed, an individual draft is IMHO a more appropriate process >>mechanism, and forming a WG would not automatically prevent >>publication of non-WG documents the WG decided not to take. >>To get some idea on what work items we have most interest in, I've >>collected those proposed so far (with some things vendors are known to >>do in proprietary ways thrown in). Please select the items you think the WG should work on (less than ten, please), order them most important first, and for each item, indicate what you're willing to do: [E]dit: you're willing to edit the draft corresponding to the work item (note: even if we use an individual draft as a starting point, this does not automatically determine the editor of the WG item) [C]ontribute: you're willing to propose non-trivial amounts of text for the document during its development [R]eview: you're willing to review new revisions of the draft regularly (not just during WGLC) For example, [CR] AEAD algorithms in IKEv2 [R] IPsec document roadmap update would mean that AEAD algorithms is your first priority, and you volunteer to contribute and review; and IPsec document roadmap is your second priority, and you volunteer to review. You can also propose a work item that isn't on my list. However, for the time being, I think PF_KEY work does not fit within the scope of the possible WG charter. List follows: o Update to IKEv2 base specification (possible starting point: draft-hoffman-ikev2bis) o IPsec document roadmap update (possible starting point: RFC 2411) o Using AEAD algorithms in IKEv2 (possible starting point: draft-black-ipsec-ikev2-aead-modes) o Redirecting a VPN client from one gateway to another (in a cluster of gateways) o IPsec "secure beacon", or detecting whether you need VPN or not (possible starting point: draft-sheffer-ipsec-secure-beacon) o Detecting crashed peers faster (possible starting point: draft-nir-ike-qcd) o IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) o Authentication-only IPsec that simplifies packet inspection (possible starting points: draft-hoffman-esp-null-protocol, draft-grewal-ipsec-traffic-visibility) o Better IPv6 configuration payloads (possible starting point: draft-eronen-ipsec-ikev2-ipv6-config) o Other work for making sure IKEv1 and IKEv2 work as well as possible with IPv6, both from standards and operations standpoint (please specify more details if you select this one) o Running IPsec over TCP (so your VPN works even if the coffee shop Wi-Fi has stupid packet filtering) o GSS-API (or Kerberos) authentication for IKEv2 o Non-EAP-based one-time password authentication (possible starting point: draft-sunabhi-otp-ikev2) o Using GRE "key" header field as IPsec traffic selector (possible starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) o Authentication with Cryptographically Generated Addresses (CGA) (possible starting point: draft-laganier-ike-ipv6-cga) o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec (possible starting point: draft-bellovin-useipsec) o Labeled IPsec for RFC 430x IPsec o IKEv1/IKEv2 co-existence and transition (please specify more details if you select this one) o Setting up GRE tunnels with IKE (possible starting point: draft-wu-l3vpn-ipsec-gre-00) o Connecting IKEv2 peers behind NATs via a "mediation server" (possible starting point: draft-brunner-ikev2-mediation) o Anything that may be needed from IKE/IPsec with respect to routing protocol security (please specify more details if you select this one) o Documenting differences in IPsec usage in IETF vs. 3GPP vs. 3GPP2 vs. WiMAX vs. vendors etc. (please specify more details if you select this one) o IKEv2 CAPTCHA (possible starting point: draft-mutaf-spikev2-01.txt) Please reply (on the mailing list) within a week or so -- I will then summarize what we have. Best regards, Pasi --- P.S. It's good to note that we currently have several other WGs working on IPsec: o BMWG: benchmarking IPsec devices o BTNS: unauthenticated or leap-of-faith IPsec, channel bindings, IPsec APIs for applications (not key management daemons like PF_KEY) o MEXT: interaction between IPsec and Mobile IP, Mobile IP specific extensions to IPsec o MSEC: multicast IPsec o ROHC: header compression in IPsec tunnel mode SAs o SOFTWIRE: IPsec tunnels as a softwire, setting those up based on BGP etc. These WGs will continue as-is, and e.g. any changes to their charters are not in the scope of this discussion. Future work items could be considered case-by-case, but the intent is *not* to collect all IPsec-related work to one WG. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 26 00:31: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 F1A2528C106; Mon, 26 May 2008 00:31: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 F09913A67E9 for ; Mon, 26 May 2008 00:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.217 X-Spam-Level: X-Spam-Status: No, score=-6.217 tagged_above=-999 required=5 tests=[AWL=0.382, 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 XQYNjt3KOOLx for ; Mon, 26 May 2008 00:31:47 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id A859128C0F6 for ; Mon, 26 May 2008 00:31:46 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m4Q7VMck029968; Mon, 26 May 2008 10:31:41 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 10:31:30 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 May 2008 10:31:30 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 May 2008 10:31:29 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72B36638@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Comments on re-direct mechanism for IKEv2 Thread-Index: Aci9PbevGxnVcAJLQGutUCf/yvrLSABwvLhA References: From: To: , X-OriginalArrivalTime: 26 May 2008 07:31:30.0456 (UTC) FILETIME=[83F1C980:01C8BF02] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] Comments on re-direct mechanism 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 Fan Zhao wrote: > 3. IKEv2 Exchange with Redirect > "The VPN client indicates support for the IKEv2 redirect mechanism by > including a REDIRECT_SUPPORTED notification message in the initial > IKE_SA_INIT request. If the IKE_SA_INIT request did not include the > REDIRECT_SUPPORTED payload, the responder MUST NOT send the REDIRECT > payload to the VPN client." > > Fan> This REDIRECT_SUPPORTED notification can be useful for > compatibility issue. However I am not sure it is needed. > > Fan> Rfc 4306 already describes how to handle un-recongized payload, > i.e. if this is a critical payload (the C bit is set) and the payload > type is unrecognized, the message MUST be rejected and the response > MUST include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD; or if the > critical flag is not set and the payload type is unsupported, that > payload MUST be ignored. The 'C' bit operates at the payload type level (not at payload content level), so per RFC 4306, it's always zero for all Notify payloads. (But it would be, of course, possible to specify a new payload type.) > Fan> There are at least two cases worth further considering: > an upgraded VPN client (i.e. a client supporting this re-direct > mechanism) connects to a legacy VPN gateway (i.e. a gateway with no > support of this re-direct mechanism) and a legacy client connects > to an upgraded GW. > > Fan> In the following, I assume that if there are multiple VPN GWs > in one network, all or none of them are upgraded. > > Fan> If a upgraded client sends to a legacy GW identified by a unicast > address, if REDIRECT_SUPPORTED is used and the C bit is set, the > legacy GW will reject this request and return UNSUPPORTED_CRITICAL_ > PAYLOAD. And then client will have to try again with the same or > different GW, maybe without REDIRECT_SUPPORTED for this time. On the > other hand, if the upgraded client does not include > REDIRECT_SUPPORTED, > the setup can proceed. Since in this case the GW cannot provide re- > direct support anyway, without indicating REDIRECT_SUPPORTED, the > signaling procedure can be shortened. > > Fan> If a upgraded client sends to a pool of legacy GWs identified by > an anycast address, I think this case is not realistic because if VPN > GWs do not support re-direct, then the anycast should not be > advertised in the DNS anyway. > > Fan> If a legacy client sends to a upgraded GW identified by a unicast > or anycast address, the GW can return the REDIRECT payload. If the C > bit is set, the client does not understand; thus it will try another > GW. If the C bit is not set, the client can ignore the REDIRECT > payload and continue with the procedure. Whether the C bit in the > REDIRECT payload should be set or not is up to the configuration > of the GW. IMO, when using anycast address, the GW must return > a REDIRECT payload with the C bit set in order to discourage the > legacy client to continue with the next step. If the legacy client knows just one GW address, and it receives an IKE_SA_INIT response containing only the REDIRECT notification (and nothing else -- e.g. 2nd message in Section 3 of the draft), the VPN connection would failed. So if we don't have REDIRECT_SUPPORTED, the gateway needs to reply with a full IKE_SA_INIT response that's acceptable to legacy clients, too. That would require more processing and state for the gateway... > REDIRECTED_FROM > > Fan> I understand the purpose of using the REDIRECTED_FROM payload. > IMHO, it does not help against potential attacks because an attacker > can simply send the first IKE_SA_INIT message without the REDIRECTED_ > FROM payload, the VPN GW needs to process such a message because this > message could be from a legitimate and legacy client. Furthermore, > this payload causes additional overhead. The situation addressed by REDIRECTED_FROM is not a malicious initiator (who can indeed just remove the REDIRECTED_FROM payload), but a malicious responder who redirects a large number of honest clients to the victim. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 26 01:31: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 D1EB028C152; Mon, 26 May 2008 01:31: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 1BA7F3A6B82 for ; Mon, 26 May 2008 01:31:06 -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 L3wlwzEuP10y for ; Mon, 26 May 2008 01:31:05 -0700 (PDT) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.187]) by core3.amsl.com (Postfix) with ESMTP id 71AFF3A6B81 for ; Mon, 26 May 2008 01:31:04 -0700 (PDT) Received: by gv-out-0910.google.com with SMTP id e6so504072gvc.15 for ; Mon, 26 May 2008 01:31: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=0vT7c11lcDZ/ZtPQi4XPGoUfP4WxWmrAwVjrvXAqvnQ=; b=XGF58euLd3iOv50u+7fPEw8SheIaAB1hqgC2gXy1Rvq2sReDEsRbmPo49pC1TnnNHOyCqo4p0YbIihe1tca0KJMLl94nRVZp8+JEacTGcDUA827gy6fgwO5iirJ1XCAhrNQkieI9JkpRujPWRk06p6Zi9tKydpyArTUn+JaiByg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=uRB8Qpkq4ZJxdUPN9pdoIrXEsS3bQSAOCgkZj4QXPTfsGg8rO2hf0WLSZmqc4OoqG0iRCWfwMHsqK5F+EoJvIvHptO7Xfc86/4j5dmbp22kwnW21RWkgApKBzI8GRq5rg7BkBoOOHz/damgwWlP8+mmojaLmhFTJ9zQFYG04rNs= Received: by 10.142.98.18 with SMTP id v18mr1894251wfb.61.1211790663846; Mon, 26 May 2008 01:31:03 -0700 (PDT) Received: by 10.142.211.11 with HTTP; Mon, 26 May 2008 01:31:03 -0700 (PDT) Message-ID: <4c5c7a6d0805260131j7218f64byb139ded878d3103d@mail.gmail.com> Date: Mon, 26 May 2008 16:31:03 +0800 From: "Peng Yang" To: ipsec@ietf.org, Pasi.Eronen@nokia.com In-Reply-To: <4c5c7a6d0805252341r84994d3tf66505ee9ee1fdf9@mail.gmail.com> MIME-Version: 1.0 Content-Disposition: inline References: <4c5c7a6d0805252341r84994d3tf66505ee9ee1fdf9@mail.gmail.com> Subject: Re: [IPsec] IPsec maintenance/extensions WG, summary so far 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, Pasi and all: Sorry for late post. And sorry for Pasi if you received multiple copy of this mail. My interest list has following items. [ECR] IKEv2 session resumption / optimizing IKEv2 handshake when connecting again to same peer/cluster of peers (possible starting point: draft-sheffer-ipsec-failover) [ECR] MEXT: interaction between IPsec and Mobile IP, Mobile IP specific extensions to IPsec [ECR] Using GRE "key" header field as IPsec traffic selector (possible starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) Thanks a lot Cheers, Peny > >>So far, we've had ~20 people who've expressed some form of support > >>for creating a WG. This is good -- many current WGs have less than 20 > >>people who regularly post to the WG mailing list. > > >>However, by my count, we've also had ~20 proposals for work items. > >>That obviously does not add up. > > >>I agree with Paul's comment about the WG scope: the WG should work > >>on things where having a WG is really needed, and we actually have a > >>*group* of people interested on participating. > > >>Having a WG should not encourage people to develop extensions that > >>would not have happened in the absence of a WG (this usually indicates > >>they're not widely needed). For some work items that have been > >>proposed, an individual draft is IMHO a more appropriate process > >>mechanism, and forming a WG would not automatically prevent > >>publication of non-WG documents the WG decided not to take. > > >>To get some idea on what work items we have most interest in, I've > >>collected those proposed so far (with some things vendors are known to > >>do in proprietary ways thrown in). > > Please select the items you think the WG should work on (less than > ten, please), order them most important first, and for each item, > indicate what you're willing to do: > > [E]dit: you're willing to edit the draft corresponding to the work > item (note: even if we use an individual draft as a starting point, > this does not automatically determine the editor of the WG item) > > [C]ontribute: you're willing to propose non-trivial amounts of > text for the document during its development > > [R]eview: you're willing to review new revisions of the draft > regularly (not just during WGLC) > > For example, > > [CR] AEAD algorithms in IKEv2 > [R] IPsec document roadmap update > > would mean that AEAD algorithms is your first priority, and you > volunteer to contribute and review; and IPsec document roadmap is > your second priority, and you volunteer to review. > > You can also propose a work item that isn't on my list. > However, for the time being, I think PF_KEY work does not fit > within the scope of the possible WG charter. > > List follows: > > o Update to IKEv2 base specification (possible starting point: > draft-hoffman-ikev2bis) > > o IPsec document roadmap update (possible starting point: RFC 2411) > > o Using AEAD algorithms in IKEv2 (possible starting point: > draft-black-ipsec-ikev2-aead-modes) > > o Redirecting a VPN client from one gateway to another > (in a cluster of gateways) > > o IPsec "secure beacon", or detecting whether you need VPN or > not (possible starting point: draft-sheffer-ipsec-secure-beacon) > > o Detecting crashed peers faster (possible starting point: > draft-nir-ike-qcd) > > o IKEv2 session resumption / optimizing IKEv2 handshake when > connecting again to same peer/cluster of peers (possible > starting point: draft-sheffer-ipsec-failover) > > o Authentication-only IPsec that simplifies packet inspection > (possible starting points: draft-hoffman-esp-null-protocol, > draft-grewal-ipsec-traffic-visibility) > > o Better IPv6 configuration payloads (possible starting point: > draft-eronen-ipsec-ikev2-ipv6-config) > > o Other work for making sure IKEv1 and IKEv2 work as well as > possible with IPv6, both from standards and operations standpoint > (please specify more details if you select this one) > > o Running IPsec over TCP (so your VPN works even if the coffee > shop Wi-Fi has stupid packet filtering) > > o GSS-API (or Kerberos) authentication for IKEv2 > > o Non-EAP-based one-time password authentication (possible > starting point: draft-sunabhi-otp-ikev2) > > o Using GRE "key" header field as IPsec traffic selector (possible > starting point: draft-ma-softwire-ipsec-gre-demultiplexing-ps) > > o Authentication with Cryptographically Generated Addresses (CGA) > (possible starting point: draft-laganier-ike-ipv6-cga) > > o Guidelines for Mandating the Use of IPsec, for RFC430x IPsec > (possible starting point: draft-bellovin-useipsec) > > o Labeled IPsec for RFC 430x IPsec > > o IKEv1/IKEv2 co-existence and transition (please specify more > details if you select this one) > > o Setting up GRE tunnels with IKE (possible starting point: > draft-wu-l3vpn-ipsec-gre-00) > > o Connecting IKEv2 peers behind NATs via a "mediation server" > (possible starting point: draft-brunner-ikev2-mediation) > > o Anything that may be needed from IKE/IPsec with respect to > routing protocol security (please specify more details if > you select this one) > > o Documenting differences in IPsec usage in IETF vs. 3GPP vs. > 3GPP2 vs. WiMAX vs. vendors etc. (please specify more details > if you select this one) > > o IKEv2 CAPTCHA > (possible starting point: draft-mutaf-spikev2-01.txt) > > Please reply (on the mailing list) within a week or so -- I will > then summarize what we have. > > Best regards, > Pasi > > --- > > P.S. It's good to note that we currently have several other WGs > working on IPsec: > > o BMWG: benchmarking IPsec devices > > o BTNS: unauthenticated or leap-of-faith IPsec, channel bindings, > IPsec APIs for applications (not key management daemons like > PF_KEY) > > o MEXT: interaction between IPsec and Mobile IP, Mobile IP > specific extensions to IPsec > > o MSEC: multicast IPsec > > o ROHC: header compression in IPsec tunnel mode SAs > > o SOFTWIRE: IPsec tunnels as a softwire, setting those up > based on BGP etc. > > These WGs will continue as-is, and e.g. any changes to their charters > are not in the scope of this discussion. Future work items could be > considered case-by-case, but the intent is *not* to collect all > IPsec-related work to one WG. > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 27 18: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 9AF453A690F; Tue, 27 May 2008 18: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 6E39A3A690F for ; Tue, 27 May 2008 18:23: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 UiNycTEcYIyG for ; Tue, 27 May 2008 18:22:59 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.242]) by core3.amsl.com (Postfix) with ESMTP id 398B53A68D9 for ; Tue, 27 May 2008 18:22:58 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so890370and.122 for ; Tue, 27 May 2008 18:23: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=xQoRdTIVTInmhzTOX42GXhJwjtFh+JnlSR2EC3Fj/lo=; b=dePt+rueqehpxfOcmxmUVz0FINpa+7uHgsxRvh0RNHaS090pIz9L0mnX1iYBcOVBn3yJFfFdXRzolUk1W9mRI4SZ4UmoXxngeD4TU4fCJiEnwEI+jyU9WYAXfuzh2z/m5ICo2CK3JH9zn0Tddvn0XJEpZYLK55kNPItXulP4wpM= 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=CiHu+O6kXkr880hYBINTk2nJeY2HlVHz8dd0dRxaF0Rlk0PwEMUn5GAIBBH1M9aZf7iVOZRcPRssfIPMEG2ZpWyDS8xosg+QKB+KWPQ/1PwdwPuUS/rv/u2YfiU8Hlnd7syMDiM7AoDIcff6GnQyP2AMD9W6qFTx54i4rzAamZU= Received: by 10.100.127.15 with SMTP id z15mr2589793anc.61.1211937785112; Tue, 27 May 2008 18:23:05 -0700 (PDT) Received: by 10.100.141.11 with HTTP; Tue, 27 May 2008 18:23:05 -0700 (PDT) Message-ID: Date: Tue, 27 May 2008 18:23:05 -0700 From: "fan zhao" To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB72B36638@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB72B36638@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, dvijay@gmail.com Subject: Re: [IPsec] Comments on re-direct mechanism 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 Pasi, Sorry I could not reply earlier. Please see my reply below. On Mon, May 26, 2008 at 12:31 AM, wrote: > Fan Zhao wrote: > >> 3. IKEv2 Exchange with Redirect >> "The VPN client indicates support for the IKEv2 redirect mechanism by >> including a REDIRECT_SUPPORTED notification message in the initial >> IKE_SA_INIT request. If the IKE_SA_INIT request did not include the >> REDIRECT_SUPPORTED payload, the responder MUST NOT send the REDIRECT >> payload to the VPN client." >> >> Fan> This REDIRECT_SUPPORTED notification can be useful for >> compatibility issue. However I am not sure it is needed. >> >> Fan> Rfc 4306 already describes how to handle un-recongized payload, >> i.e. if this is a critical payload (the C bit is set) and the payload >> type is unrecognized, the message MUST be rejected and the response >> MUST include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD; or if the >> critical flag is not set and the payload type is unsupported, that >> payload MUST be ignored. > > The 'C' bit operates at the payload type level (not at payload content > level), so per RFC 4306, it's always zero for all Notify payloads. > (But it would be, of course, possible to specify a new payload type.) Fan> You are correct. Sorry for my mis-understanding on the meaning of the 'C' bit. I do not have strong oponion on whether to define a new type of payload for redirect information either, though such information could be "critical" in some sense. > >> Fan> There are at least two cases worth further considering: >> an upgraded VPN client (i.e. a client supporting this re-direct >> mechanism) connects to a legacy VPN gateway (i.e. a gateway with no >> support of this re-direct mechanism) and a legacy client connects >> to an upgraded GW. >> >> Fan> In the following, I assume that if there are multiple VPN GWs >> in one network, all or none of them are upgraded. >> >> Fan> If a upgraded client sends to a legacy GW identified by a unicast >> address, if REDIRECT_SUPPORTED is used and the C bit is set, the >> legacy GW will reject this request and return UNSUPPORTED_CRITICAL_ >> PAYLOAD. And then client will have to try again with the same or >> different GW, maybe without REDIRECT_SUPPORTED for this time. On the >> other hand, if the upgraded client does not include >> REDIRECT_SUPPORTED, >> the setup can proceed. Since in this case the GW cannot provide re- >> direct support anyway, without indicating REDIRECT_SUPPORTED, the >> signaling procedure can be shortened. >> >> Fan> If a upgraded client sends to a pool of legacy GWs identified by >> an anycast address, I think this case is not realistic because if VPN >> GWs do not support re-direct, then the anycast should not be >> advertised in the DNS anyway. >> >> Fan> If a legacy client sends to a upgraded GW identified by a unicast >> or anycast address, the GW can return the REDIRECT payload. If the C >> bit is set, the client does not understand; thus it will try another >> GW. If the C bit is not set, the client can ignore the REDIRECT >> payload and continue with the procedure. Whether the C bit in the >> REDIRECT payload should be set or not is up to the configuration >> of the GW. IMO, when using anycast address, the GW must return >> a REDIRECT payload with the C bit set in order to discourage the >> legacy client to continue with the next step. > > If the legacy client knows just one GW address, and it receives an > IKE_SA_INIT response containing only the REDIRECT notification (and > nothing else -- e.g. 2nd message in Section 3 of the draft), the > VPN connection would failed. > > So if we don't have REDIRECT_SUPPORTED, the gateway needs to reply > with a full IKE_SA_INIT response that's acceptable to legacy clients, > too. That would require more processing and state for the gateway... Fan> I agree. Using REDIRECT_SUPPORTED will be helpful in this case, if the VPN GW wants to redirect the VPN client immediately during the IKE_INIT_SA exchange. > > > >> REDIRECTED_FROM >> >> Fan> I understand the purpose of using the REDIRECTED_FROM payload. >> IMHO, it does not help against potential attacks because an attacker >> can simply send the first IKE_SA_INIT message without the REDIRECTED_ >> FROM payload, the VPN GW needs to process such a message because this >> message could be from a legitimate and legacy client. Furthermore, >> this payload causes additional overhead. > > The situation addressed by REDIRECTED_FROM is not a malicious > initiator (who can indeed just remove the REDIRECTED_FROM payload), > but a malicious responder who redirects a large number of honest > clients to the victim. Fan> I see. Nevertheless, attackers can frame an innocent VPN GW, by forging and sending many IKEv2 messages to the victim VPN GW with REDIRECTED_FROM payload indicating the IP address of the innocent VPN GW. Do I miss something? Thanks a lot. Sincerely, fan > > Best regards, > Pasi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec