From ipsec-bounces@ietf.org Mon Dec 1 05:23:43 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 1686A3A6B06; Mon, 1 Dec 2008 05:23:43 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 581453A6AEF for ; Mon, 1 Dec 2008 05:23:41 -0800 (PST) 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 HqAFCOABksET for ; Mon, 1 Dec 2008 05:23:40 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.171]) by core3.amsl.com (Postfix) with ESMTP id 30F3E28C2C7 for ; Mon, 1 Dec 2008 05:09:52 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2697984wfd.31 for ; Mon, 01 Dec 2008 05:09:48 -0800 (PST) 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=w1jmVhdwUXcmNl9Ekxy6arraxw16ObH6mtbXH8FqkuU=; b=IUwMfEmShAAI3xPvnd0qUoFLxt8ThwmPBMP/b45jlk/SQIIPezAQsXx4Y3oMTR8eYK KlIGf/QpXapYXd3FwAjKmZk6iz6Q70QYwVKcBCy5tH81rsV1t6FGDPwfs+8J4JtsS9I2 mVGag3b/xkVQlLJyt3B1+dI6JpRUClLBd02fc= 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=nWaCnsJeCo39RkN8Q76BteyPNbjhxPvLqFKn0KOJhIVRAFSolq5J1LVQ4wWnh5y5nh Y2VVMUV6u/nQQRTnBrSlmDPM6VRB9iGtibTd4COezKbzugX+auW9kh9t6L0vQOUerYhz R79q2GeqopnZ75BGWA2OUQBk1UeMcdL9p2sXw= Received: by 10.142.140.14 with SMTP id n14mr4498052wfd.201.1228136988038; Mon, 01 Dec 2008 05:09:48 -0800 (PST) Received: by 10.142.171.20 with HTTP; Mon, 1 Dec 2008 05:09:47 -0800 (PST) Message-ID: Date: Mon, 1 Dec 2008 18:39:47 +0530 From: "Jack Kohn" To: "Scott Fluhrer" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> Cc: ipsec@ietf.org, "Bhatia, Manav \(Manav\)" Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Scott, >> - To an intermediate device that isn't aware of this extension, it would >> look like an ESP packet except that the ESP sequence number doesn't >> increment; instead, it stays at one particular fixed value (until a rekey, >> when it abruptly switches to another fixed value). One possible concern is >> that firewalls that try to filter what they can for ESP traffic flows will >> reject this. > > Wow. You're saying that firewalls maintain state for each IPSec flow > and actually care about the sequence numbers? They'll have to maintain > state per . Why would you > do that? Are there firewalls that actually do that? I was hoping that somebody (Scott?) would answer this. Is this really a concern? Transit routers wouldnt care about the sequence number not incrementing when forwarding IPSec packets, and i would be extremely surprised if firewalls do. Jack > >> >> Neither is that difficult to fix... > > Absolutely. > > I think whats important at this point is whether we want a new > protocol or some method that extends ESP for our needs. I would rather > that we go with the latter. > > Jack > >> >>> >>> Since we're using the existing ESP protocol number, the >>> intermediary devices can still forward the packet and there >>> is little change required. Implementation of this extension >>> is *extremely* *extremely* easy as one only needs to add a >>> RSPI of 1 (or whatever is assigned by >>> IANA) for all ESP-NULL packets. >>> >>> An extended ESP packet using NULL encryption would thus look >>> like this: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Reserved Security Parameters Index (RSPI) = 1 | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Original Security Parameters Index (SPI) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Sequence Number | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Payload Data* (variable) | >>> ~ ~ >>> | | >>> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | Padding (0-255 bytes) | >>> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | Pad Length | Next Header | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Authentication Data (variable) | >>> ~ ~ >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Intermediaries (routers, firewalls, IDS, etc) interested in >>> inspecting the packets en route can look at the SPI value at >>> the start of the ESP header. If its 1 and if they are aware >>> of this extension, then they understand that what follows is >>> a normal ESP-NULL packet, which can be inspected. >>> Intermediaries that don't understand this extension of ESP >>> would treat this like a normal ESP packet >>> >>> This extension aware end nodes (routers) can similarly >>> inspect the packet. If the SPI value is 1, they can deep >>> inspect the packet and assign it to the right CPU >>> queue/remark/apply ACLs/filters, based on the kind of payload >>> the packet carries. >>> >>> Would like to hear from the folks on what they think about >>> this proposal? >>> >>> Cheers, Manav >>> >>> -- >>> Manav Bhatia, >>> IP Division, Alcatel-Lucent, >>> Bangalore - India >>> >>> >>> _______________________________________________ >>> 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 Mon Dec 1 05:27: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 B4CDA28DF97; Mon, 1 Dec 2008 05:12:11 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1565628CAD7 for ; Mon, 1 Dec 2008 05:11:27 -0800 (PST) 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 3nwlV-XlrEte for ; Mon, 1 Dec 2008 05:11:26 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 9CB4828CAAC for ; Mon, 1 Dec 2008 05:04:22 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so2696007wfd.31 for ; Mon, 01 Dec 2008 05:04:19 -0800 (PST) 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=wCTZUHMc9KwGlOXl4ihS9KA/kUEfM4AyH5/dwavxxY8=; b=QvWjB2w+OxdHkWDMKthIGFCfEPxh1bvCmokTGyVVtDwbAquAy3SnefnnAliGPDhJYl VRhqbdsiO5siXV/ZDLpc0aiGWNLr76VE3WFrY3DmXtSg6gjUsSHlT76/Fj7MTnXrqfnM XP2cBPCYBZxR3zP7sx/tDLTDbcQtvpdjMrwmQ= 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=a7WfOmBXbpSUTEiAC/36KNLv9ozxC9I+KoS4WpjgO5rQbWNdU2IVBXrD6ImZ77HQAU C2ar63Hclj0lCRrj/kSO1N7Xp0cRKK+F5ZeS2w7RLXrUp9YyB5GdZtb8ci1Y6XOTpcNv sZ8rKA2MriDhVD9YKRdtw3vrDg7WYJG1rwR1M= Received: by 10.142.14.20 with SMTP id 20mr4506108wfn.79.1228136658970; Mon, 01 Dec 2008 05:04:18 -0800 (PST) Received: by 10.142.171.20 with HTTP; Mon, 1 Dec 2008 05:04:18 -0800 (PST) Message-ID: Date: Mon, 1 Dec 2008 18:34:18 +0530 From: "Jack Kohn" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356C66@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <77ead0ec0811301039k1e279415tb4d5037b0c9e3a74@mail.gmail.com> <200812010354.mB13swc7019862@toshiba.co.jp> <6D26D1FE43A66F439F8109CDD424196502356C66@INEXC1U01.in.lucent.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org >> If I understand correctly, efforts has been paid to make protocol >> headers align at 4-octet word boundary. If the policy hasn't changed, >> the next protocol header should align at the word boundary inside ESP >> header as well. I dont think ESP needs to do this when its being used for integrity only. I always thought that padding was there to facilitate the encryption algorithms. > > Its easy to align it on a word boundary - just add two reserved bytes > after the header length; these would be set to zero when transmitting > and ignored on receipt. This also leaves room for further extensions. Extensibility and not alignment should be the reason for adding the two octets. Jack > > Cheers, Manav > >> >> >> FUKUMOTO Atsushi >> atsushi.fukumoto@toshiba.co.jp >> _______________________________________________ >> 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 Mon Dec 1 05:27: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 347C33A6CD7; Mon, 1 Dec 2008 05:27:38 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4183A6CD3 for ; Mon, 1 Dec 2008 05:27:36 -0800 (PST) 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 pPfUWaQ-pfxz for ; Mon, 1 Dec 2008 05:27:35 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.188]) by core3.amsl.com (Postfix) with ESMTP id A8BE728C4D4 for ; Mon, 1 Dec 2008 05:13:38 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id j77so1901751rne.18 for ; Mon, 01 Dec 2008 05:13:35 -0800 (PST) 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=brYbc8nChdNRGQPVH/dtI5Vv8RenVKRKKH5qRD8gCBg=; b=Cne+jmrMbo65T4V5jPU892p1GdEahjY4fh6XCUEFQ6C0FsaQGH9cltgcSv/7h0vEow hPr2lhtxuTlio5fmg4estxWegBTkbOr7Y912ZDCSkmdSN5HTxv+34fwwlErdHugr2po8 PQVUx82bYZ3cJyhQOTWqJs7KnXWeeOnRZNfjQ= 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=GGGF+zmd3cKkNCIeeNy2VMOt9rLvH3Ef2T78aDCpfoT/FqlO2Fk7cVVwmCou4mp5jh 3u3vc/5xsd6/kAXz64DCV5MLRFmhlW+i8iaeCGs9HL9zSeL1UAHadBL+MT49e54ocCcR Ca9bLh7EGhIdKvcoY/jdPASfhikdeutnkd66A= Received: by 10.142.44.11 with SMTP id r11mr4501883wfr.249.1228137214474; Mon, 01 Dec 2008 05:13:34 -0800 (PST) Received: by 10.142.171.20 with HTTP; Mon, 1 Dec 2008 05:13:34 -0800 (PST) Message-ID: Date: Mon, 1 Dec 2008 18:43:34 +0530 From: "Jack Kohn" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356C33@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356C33@INEXC1U01.in.lucent.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-bhatia-ipsecme-esp-null-00.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 Please use https://datatracker.ietf.org/idst/upload.cgi to upload the draft; let me know if you need some help in uploading the same. Jack On Mon, Dec 1, 2008 at 6:35 AM, Bhatia, Manav (Manav) wrote: > > Hi, > > I have written a small draft describing my proposal. It incorporates the > feedback that I received from the mailing list and offline. I think the > main difference between this draft and the WG draft is that while the > latter requires a new IP protocol number, mine uses one of the reserved > SPI values (keeping the protocol number intact) to disambiguate ESP-NULL > from the encrypted ESP packets. > > In my proposal nothing happens to the ESP packets on the noncompliant > intermediaries, while in case of the latter, they would probably get > dropped (as those packets would not be recognized). > > I have submitted a copy to internet-drafts and it should be available > online in a few days. The WG could meanwhile, review the attached draft. > Would appreciate comments and feedback! > > Thanks, Manav > > -- > Manav Bhatia, > IP Division, Alcatel-Lucent, > Bangalore - India > > > > _______________________________________________ > 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 Dec 1 05:54:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC4E3A693B; Mon, 1 Dec 2008 05:54:17 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38EBC3A693B for ; Mon, 1 Dec 2008 05:54:17 -0800 (PST) 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 gz4DteklvcWY for ; Mon, 1 Dec 2008 05:54:16 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 0D43C3A68DD for ; Mon, 1 Dec 2008 05:54:15 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so1748787fga.41 for ; Mon, 01 Dec 2008 05:54:11 -0800 (PST) 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=oGAcFqONd3obq6YXHnnWdXkN7ZzagX8cKikW+mdWWJI=; b=FVJ/dpd1xYBvz4zbGfWwDtZZ1ipF/JG8XUVZ/tVLmFcmTmRSMVt+r3wIW6UmPPeiUu A/mOKb7ufNLN+wXf/2E3rv8BHXQqlf1ndqTHRGLrzmPAWEIleudLiV3a25DKsCQRB2xd ivpHC+8+8fkdbEJUnuyD/xtFokhl7v69lfB54= 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=ZoWvKx8pJOdHCwhhLXT8KvakzFb9AK2dxqfjheUGY4m87iCCjbswHI4NQHY+fcXu0c y90MAH+/7MT6cqmL5hnbyNuwPG/n30q19NN3HmrYewH7gyfWRZZHl0tMjltafF5ALgGc FOpU20bU+saFI+YQwFaUo9YxBHWUgifE4XW3A= Received: by 10.181.145.7 with SMTP id x7mr3934544bkn.177.1228139651430; Mon, 01 Dec 2008 05:54:11 -0800 (PST) Received: by 10.180.205.7 with HTTP; Mon, 1 Dec 2008 05:54:11 -0800 (PST) Message-ID: <77ead0ec0812010554jc86bb07gd79285bb31437c3e@mail.gmail.com> Date: Mon, 1 Dec 2008 05:54:11 -0800 From: "Vishwas Manral" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356C2F@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> <6D26D1FE43A66F439F8109CDD424196502356BC5@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356C2B@INEXC1U01.in.lucent.com> <77ead0ec0811301039k1e279415tb4d5037b0c9e3a74@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356C2F@INEXC1U01.in.lucent.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Manav, > The transit routers would not care about this while the end routers > should ignore such packets. In this case, the latter behavior is > acceptable as end routers unaware of this extension would anyways be > unable able to parse this packet. How can we identify the difference between "unable to parse" a packet vs "wrongly parsing a packet"? Thanks, Vishwas On Sun, Nov 30, 2008 at 3:52 PM, Bhatia, Manav (Manav) wrote: > Hi Vishwas, > > [ .. ] > >> What would an IPsec router do in case it gets one of the reserved SPI >> values in the packet? > > The transit routers would not care about this while the end routers > should ignore such packets. In this case, the latter behavior is > acceptable as end routers unaware of this extension would anyways be > unable able to parse this packet. > > Cheers, Manav > >> >> Thanks again, >> Vishwas >> >> On Sun, Nov 30, 2008 at 7:57 AM, Bhatia, Manav (Manav) >> wrote: >> > Hi Jack, >> > >> >> > could look at the 5th octet to know what the next-header >> >> is. If you want >> >> > the firewalls to be able to parse the L4 info then you >> >> could include the >> >> > ESP header length too. This could be the 6th octet. >> Using this the >> >> >> >> I am assuming that you're mentioning ESP header length >> explicitly to >> >> account for the IV (if required, by the authentication >> algorithm), as >> >> otherwise its a fixed value and can always be inferred, right? >> > >> > Yes, that's correct. >> > >> > Cheers, Manav > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 1 06:03: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 A96E73A69D9; Mon, 1 Dec 2008 06:03:30 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D46C3A69D9 for ; Mon, 1 Dec 2008 06:03:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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 tqYPMmijARhM for ; Mon, 1 Dec 2008 06:03:29 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E32B73A689F for ; Mon, 1 Dec 2008 06:03:28 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 84C3A29C003; Mon, 1 Dec 2008 16:03:24 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A0D2B29C001; Mon, 1 Dec 2008 16:03:23 +0200 (IST) X-CheckPoint: {4933EDFF-10000-88241DC2-7B6} Received: from [91.90.139.118] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB1E3NfE001910; Mon, 1 Dec 2008 16:03:23 +0200 (IST) Message-Id: <5F52AEA4-2E20-4037-B42D-E2B8BE8D4B6F@checkpoint.com> From: Yoav Nir To: Jack Kohn In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 1 Dec 2008 16:03:23 +0200 References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org, "Bhatia, Manav \(Manav\)" , Scott Fluhrer Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Dec 1, 2008, at 3:09 PM, Jack Kohn wrote: > Hi Scott, > >>> - To an intermediate device that isn't aware of this extension, it >>> would >>> look like an ESP packet except that the ESP sequence number doesn't >>> increment; instead, it stays at one particular fixed value (until >>> a rekey, >>> when it abruptly switches to another fixed value). One possible >>> concern is >>> that firewalls that try to filter what they can for ESP traffic >>> flows will >>> reject this. >> >> Wow. You're saying that firewalls maintain state for each IPSec flow >> and actually care about the sequence numbers? They'll have to >> maintain >> state per . Why would >> you >> do that? Are there firewalls that actually do that? > > I was hoping that somebody (Scott?) would answer this. Is this really > a concern? > > Transit routers wouldnt care about the sequence number not > incrementing when forwarding IPSec packets, and i would be extremely > surprised if firewalls do. > > Jack Well, firewalls do keep state about sequence numbers in TCP connections. They sometimes collect an entire file transferred through HTTP, SMTP or FTP just to run an anti-virus or DLP on it. They do much more than just block ports. That said, TCP sequence enforcement is there because there have been some attacks based on sequence numbers, because TCP is not secure. IPsec, even with ESP-NULL is secure against packet injection, dropping and replay, so AFAIK no firewall actually goes to the trouble of inspecting sequence numbers. Yoav Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 1 06:18: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 DBA3F3A69D9; Mon, 1 Dec 2008 06:18:42 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2C53A693B for ; Mon, 1 Dec 2008 06:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 CzhLg1eM71tp for ; Mon, 1 Dec 2008 06:18:40 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 96DB43A6AAE for ; Mon, 1 Dec 2008 06:18:35 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB1EIAR7021387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Dec 2008 16:18:10 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB1EIAFr025700; Mon, 1 Dec 2008 16:18:10 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18739.61986.159403.750112@fireball.kivinen.iki.fi> Date: Mon, 1 Dec 2008 16:18:10 +0200 From: Tero Kivinen To: "Bhatia, Manav \(Manav\)" In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356BC5@INEXC1U01.in.lucent.com> References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> <6D26D1FE43A66F439F8109CDD424196502356BC5@INEXC1U01.in.lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: ipsec@ietf.org, Scott Fluhrer Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Bhatia, Manav \(Manav\) writes: > > - To an intermediate device that isn't aware of this extension, it > > would look like an ESP packet except that the ESP sequence number > > doesn't increment; instead, it stays at one particular fixed value > > (until a rekey, when it abruptly switches to another fixed value). > > One possible concern is that firewalls that try to filter what > > they can for ESP traffic flows will reject this. > > I am not sure how big a problem this is. However, if it needs to be > fixed then this can be easily done. > > You could send the original SPI and the next-header as part of the > payload, so the original ESP packet has the sequence number in the right > place. The receiver upon seeing the RSPI value of 1 would understand > that the first 4 octets give the actual SPI, while the intermediaries > could look at the 5th octet to know what the next-header is. If you want > the firewalls to be able to parse the L4 info then you could include the > ESP header length too. This could be the 6th octet. Using this the > intermediaries can determine the exact location from where the payload > starts. If there actually is firewalls which do inspect sequence numbers, then your solution does not work, as they will then verify sequence numbers for each separate SPI, and if you have multiple SAs with multiple SPIs their sequence numbers are not synced, and even with your modified version they would drop them. On the other hand, I do not think there are such firewalls around, but on the other hand your solution still requires changes to all IPsec end nodes and all deep inspection nodes. Heuristics require changes only to deep inspection nodes, thus are much easier to take in to use. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 1 06:51:35 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48CB43A69F9; Mon, 1 Dec 2008 06:51:35 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B29293A69F9 for ; Mon, 1 Dec 2008 06:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+uB+GAmokP0 for ; Mon, 1 Dec 2008 06:51:33 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 462D63A69D9 for ; Mon, 1 Dec 2008 06:51:33 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB1EpKTv019598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Dec 2008 16:51:20 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB1EpJpZ013444; Mon, 1 Dec 2008 16:51:19 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18739.63975.625276.269689@fireball.kivinen.iki.fi> Date: Mon, 1 Dec 2008 16:51:19 +0200 From: Tero Kivinen To: "Jack Kohn" In-Reply-To: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 24 min X-Total-Time: 33 min Cc: ipsec@ietf.org, manav@alcatel-lucent.com Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Jack Kohn writes: > Heuristics is probability and is at best just an educated guess. Not really. For ESP-NULL there is always at least few bytes of self describing padding, which is very easy to check. After checking those the next ones to check is either the inner IP header (in case of tunnel mode) or TCP/UDP headers (in case of transport mode). All that checking nedes to only be done for the FIRST few packets, after the heuristics have identified the ICV length (currently 5 possible values in total, and currently only 1 of them is widely sued) and IV length (2 possible values and currently only 1 of them is widely used) then the information can be stored along the other flow specific information and no heuristics is needed after that. > I think the stakes are high as you would be dropping/forwarding > packets based on the probability that your model returns you. There is 1 out of 2^96 probability that random packet will pass your HMAC-SHA1-96 message check, so that is also probabilistic approach... If you check 8 bytes of self-describing padding and 4 bytes from the inner IP header (for tunnel mode) you get same probability... > Also, do you propose to do this in HW or SW? Either way is doable. I think the actual initial heuristics that is run when unknown source IP, destination IP and SPI value is found, would most likely be run on the softpath, as it makes adding things in future easier, but the actual per packet processing would most likely be run on the hardware. Only changes there would require adding SPI as one of the keys used when looking up the state information and getting ICV_len and IV_len from the per flow state and use those to get the protocol number. > Is there a model that you have in mind? I posted a example pseudocode for this earlier to this list. http://www.ietf.org/mail-archive/web/ipsec/current/msg03385.html > Do you have a study that you can share with us that gives some > numbers on how well this model works? My earlier email listed some numbers, so check those. There are also ways to make this even better without modifying the ESP packet format, but that would require changes to the ESP-NULL senders. I.e. the ESP-NULL senders could send at least 8 bytes of self-describing padding instead of the minimal amount, and with that change the probability of detecting ESP-NULL packet versuis ESP-encrypted packet with just one packet would go over 2^72 (8 bits of self-describing padding length, and 64 bits of padding). This is change we could do without breaking existing implementations, and it would usually be one or two line change to the code, i.e. something like: ---------------------------------------------------------------------- /* ... calculate normal pad_len here ... */ if (cipher == ESP_NULL) { pad_len += 8; } ---------------------------------------------------------------------- On the other hand if the implementation is already doing deep inspection of the packet (i.e. verifying urls and such inside the packets) then it will be checking more than enough bytes from the packet, that we do not need the extra bytes for the self-describing padding. The self-describing padding already gives you 99.998% - 99.999999999999999994% probability for detecting whether the first packet is ESP-NULL packet or ESP with encryption packet (depending how many bytes of padding there is (2-8 bytes)). And even then it would detect encrypted ESP packets as ESP-NULL because they happened to have correct bytes which looked like self-describing padding in the encrypted part. The packet would then be passed to the deep inspection part, which could not do deep inspection because the packet is encrypted. This would just cause some extra resources wasted when deep inspection engine tries to inspect those encrypted packets. The heuristics would never get it wrong in the other way, i.e detecting ESP-NULL packet as being encrypted, thus all ESP-NULL packets would be passed to the deep inspection part. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 1 07:20: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 758043A6AD0; Mon, 1 Dec 2008 07:20:24 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 208AF3A6A8F for ; Mon, 1 Dec 2008 07:20:23 -0800 (PST) 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 v5DUYBqU4QBG for ; Mon, 1 Dec 2008 07:20:22 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7C6E63A69DE for ; Mon, 1 Dec 2008 07:20:22 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[69.58.70.106]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L7AZK-0005fA-AR; Mon, 01 Dec 2008 10:20:14 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356BC4@INEXC1U01.in.lucent.com> References: <6D26D1FE43A66F439F8109CDD424196502356BC4@INEXC1U01.in.lucent.com> Date: Mon, 1 Dec 2008 10:19:14 -0500 To: "Bhatia, Manav \(Manav\)" From: Stephen Kent Cc: ipsec@ietf.org, Jack Kohn Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Manav, If you have two SPIs (original and the new, reserved one) then the format is no longer ESP and thus cannot reuse the ESP protocol number. the same argument applies to the proposal that the original SPI be stuffed into the payload. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 1 08:10: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 4839C3A696B; Mon, 1 Dec 2008 08:10:49 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D983A696B for ; Mon, 1 Dec 2008 08:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.682 X-Spam-Level: X-Spam-Status: No, score=-2.682 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 nnxLqaT944H8 for ; Mon, 1 Dec 2008 08:10:46 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 122803A690A for ; Mon, 1 Dec 2008 08:10:45 -0800 (PST) Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id mB1GAUgH004776; Mon, 1 Dec 2008 10:10:36 -0600 (CST) Received: from inexp01.in.lucent.com ([135.254.223.65]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 10:10:32 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.27]) by inexp01.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 21:40:20 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 1 Dec 2008 21:40:19 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356D74@INEXC1U01.in.lucent.com> In-Reply-To: <77ead0ec0812010554jc86bb07gd79285bb31437c3e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclTvFw1CmB5541FS2y3UoR2tQkwOwAErimQ References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> <6D26D1FE43A66F439F8109CDD424196502356BC5@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356C2B@INEXC1U01.in.lucent.com> <77ead0ec0811301039k1e279415tb4d5037b0c9e3a74@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356C2F@INEXC1U01.in.lucent.com> <77ead0ec0812010554jc86bb07gd79285bb31437c3e@mail.gmail.com> From: "Bhatia, Manav \(Manav\)" To: "Vishwas Manral" X-OriginalArrivalTime: 01 Dec 2008 16:10:20.0753 (UTC) FILETIME=[4F1EE410:01C953CF] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: ipsec@ietf.org Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Vishwas, Let me reword my reply. A compliant implementation upon receiving the reserved value must accept it and process it accordingly. A non compliant implementation should drop this packet, as it comes with a reserved SPI. Cheers, Manav > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Monday, December 01, 2008 7.24 PM > To: Bhatia, Manav (Manav) > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > > Hi Manav, > > > The transit routers would not care about this while the end routers > > should ignore such packets. In this case, the latter behavior is > > acceptable as end routers unaware of this extension would anyways be > > unable able to parse this packet. > How can we identify the difference between "unable to parse" a packet > vs "wrongly parsing a packet"? > > Thanks, > Vishwas > > On Sun, Nov 30, 2008 at 3:52 PM, Bhatia, Manav (Manav) > wrote: > > Hi Vishwas, > > > > [ .. ] > > > >> What would an IPsec router do in case it gets one of the > reserved SPI > >> values in the packet? > > > > The transit routers would not care about this while the end routers > > should ignore such packets. In this case, the latter behavior is > > acceptable as end routers unaware of this extension would anyways be > > unable able to parse this packet. > > > > Cheers, Manav > > > >> > >> Thanks again, > >> Vishwas > >> > >> On Sun, Nov 30, 2008 at 7:57 AM, Bhatia, Manav (Manav) > >> wrote: > >> > Hi Jack, > >> > > >> >> > could look at the 5th octet to know what the next-header > >> >> is. If you want > >> >> > the firewalls to be able to parse the L4 info then you > >> >> could include the > >> >> > ESP header length too. This could be the 6th octet. > >> Using this the > >> >> > >> >> I am assuming that you're mentioning ESP header length > >> explicitly to > >> >> account for the IV (if required, by the authentication > >> algorithm), as > >> >> otherwise its a fixed value and can always be inferred, right? > >> > > >> > Yes, that's correct. > >> > > >> > Cheers, Manav > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nez@alicante-ayto.es Mon Dec 1 10:02:27 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B59043A6AA6 for ; Mon, 1 Dec 2008 10:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.132 X-Spam-Level: X-Spam-Status: No, score=-7.132 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_HELO_EQ_D_D_D_D=1.597, FH_RELAY_NODNS=1.451, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_MISMATCH_BR=2.4, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rgoy3ii9REgw for ; Mon, 1 Dec 2008 10:02:27 -0800 (PST) Received: from 189-30-251-163.paebv701.dsl.brasiltelecom.net.br (unknown [189.74.203.235]) by core3.amsl.com (Postfix) with SMTP id 4760A3A689E for ; Mon, 1 Dec 2008 10:02:23 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081201180225.4760A3A689E@core3.amsl.com> Date: Mon, 1 Dec 2008 10:02:23 -0800 (PST) Click here to view as a webpage. From ipsec-bounces@ietf.org Mon Dec 1 11:06: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 513CD3A6951; Mon, 1 Dec 2008 11:06:13 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2963A6951 for ; Mon, 1 Dec 2008 11:06:12 -0800 (PST) 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 GmfyB2cbVbX1 for ; Mon, 1 Dec 2008 11:06:11 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id D16D33A6843 for ; Mon, 1 Dec 2008 11:06:10 -0800 (PST) Received: by qyk4 with SMTP id 4so2916321qyk.13 for ; Mon, 01 Dec 2008 11:06:06 -0800 (PST) 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=hcN3Y9bPvzx/4U+P6FxBEgLrP4sMSggpxNqpmIHUP+A=; b=l7SiSo86zp/E0VCvuGxqWYDCupBlJDOCdr5nsQZTPQGWHKgchMgZpW6USHcUCIYwDh 2AZPRsWjKWHyzgiPI21cekTnOcBt1mphmiWdfRks3stM1Mc7NmiBLYqbrBvaKxeqej/T y/bHs6IXfNmAWYAyLu/IUQSnJayF2wPkr5/cU= 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=RqvNmvslcbizywGNbIVrKtjKLcYbsV27/GX2BH8QvijPBDzgNNt13T5XhaEwuj2aEH tPHg5JL0zxdzrjxjZUcMl8EREdLI7f0PnphYXmwEFXHaly1gGpb98+TnJg3p37EmY9Ri EBYrGIWU9pLVA2MIElzxHyEquaZgXT7xYvpbk= Received: by 10.142.11.20 with SMTP id 20mr3320862wfk.291.1228158365681; Mon, 01 Dec 2008 11:06:05 -0800 (PST) Received: by 10.142.169.18 with HTTP; Mon, 1 Dec 2008 11:06:05 -0800 (PST) Message-ID: Date: Mon, 1 Dec 2008 11:06:05 -0800 From: "Vijay Devarapalli" To: "fan zhao" MIME-Version: 1.0 Content-Disposition: inline Cc: ipsec@ietf.org Subject: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Fan, I am following up on the one open issue on allowing a re-direct during IKE_AUTH stage. Yaron mentioned during the meeting in Minneapolis that this is not really necessary. It just adds complexity to the state machine on both the client and the gateway. I agree with him. I think the current mechanisms, re-direct during the IKE_SA_INIT exchange and gateway-initiated re-direct, are sufficient. Vijay On Wed, Nov 5, 2008 at 2:33 PM, fan zhao wrote: > Hi Vijay, > > Thanks for your reply. Please see below. > > On Wed, Nov 5, 2008 at 2:23 PM, Vijay Devarapalli wrote: >> Hi Fan, >> >> On Tue, Nov 4, 2008 at 3:09 PM, fan zhao wrote: >>> Hi, Vijay and Killian, >>> >>> I have some comments on draft-ietf-ipsecme-ikev2-redirect-01. >>> >>> 1) The draft describes the redirection during the IKE_SA_INIT exchange >>> and during the informational exchange that is after the SA is established. >>> Please correct me if I am wrong. I think the redirection can be done during >>> the IKE_AUTH exchange, right? We have discussed this before. >> >> Yes, but this change has not been made yet. I had presented this issue >> at the last IETF, but there were no comments. I was looking for a >> little bit more discussion on this before adding this to the document. > OK. > >> >>> 2) Near the end of section 3: >>> >>> "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." >>> Based on RFC 4877, the lifetime of a dynamically assigned HoA is >>> the same as that of the SA. So if the SA expires, the HoA expires >>> and the BCE is invalid too, right? >> >> The home address and the binding cache entry are not marked invalid >> right away. If the SAs expire, the mobile node can run IKEv2 with the >> home agent again and request for the same home address. > OK. This can be done. > >> >>> "In this case, the >>> mobile node MUST NOT use the original home agent 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." >>> >>> If I understand correctly, in this case, the MN will use the anycast address >>> in the IKE_SA_INIT, and then is redirected to the original home agent. >>> Is this correct? >> >> No, we wanted to say that the mobile node should try running IKEv2 >> again with the existing home agent. Not use the anycast address as the >> destination address for the IKE_SA_INIT exchange. > > I agree with what you said. Somehow, I read the text differently. > > Thanks. > > Sincerely, > fan > >> >>> 3) Some editorial issues: >>> >>> Abstract: 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. >>> >>> Maybe it is better: >>> "The proposed mechanism can also be used in Mobile IPv6 ..." >>> >>> >>> 3. IKEv2 Exchange with Redirect >>> To redirect a IKEv2 session to >>> >>> s/a/an >> >> Thanks for catching these. >> >> Vijay >> >>> >>> Thanks. >>> >>> Sincerely, >>> fan >>> >>> >>> On Mon, Nov 3, 2008 at 4:22 PM, Vijay Devarapalli wrote: >>>> Hi, >>>> >>>> We just submitted a new draft version for the IKEv2 re-direct >>>> mechanism. Changes made in this version >>>> >>>> - Added a section on gateway-initiated re-direct. The earlier versions >>>> only spoke about re-direct during the IKE_SA_INIT exchange >>>> - Updated the reference to IKEv2bis draft >>>> - A few other minor fixes. >>>> >>>> Vijay >>>> >>>> >>>> 2008/11/3 : >>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>> This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. >>>>> >>>>> >>>>> Title : Re-direct Mechanism for IKEv2 >>>>> Author(s) : V. Devarapalli, K. Weniger >>>>> Filename : draft-ietf-ipsecme-ikev2-redirect-01.txt >>>>> Pages : 12 >>>>> Date : 2008-11-03 >>>>> >>>>> 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-ietf-ipsecme-ikev2-redirect-01.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. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Mon Dec 1 11:30: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 B6E6F28C0E2; Mon, 1 Dec 2008 11:30:59 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1787528C0E2 for ; Mon, 1 Dec 2008 11:30:58 -0800 (PST) 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 xadURM9ExGOR for ; Mon, 1 Dec 2008 11:30:57 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 438253A682E for ; Mon, 1 Dec 2008 11:30:56 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 90D6429C003; Mon, 1 Dec 2008 21:30:51 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8258229C001; Mon, 1 Dec 2008 21:30:50 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB1JUnfF024969; Mon, 1 Dec 2008 21:30:50 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 1 Dec 2008 21:30:49 +0200 From: Yaron Sheffer To: "Bhatia, Manav (Manav)" , Vishwas Manral Date: Mon, 1 Dec 2008 21:30:53 +0200 Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclTvFw1CmB5541FS2y3UoR2tQkwOwAErimQAAZb7OA= Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FBD7@il-ex01.ad.checkpoint.com> References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> <6D26D1FE43A66F439F8109CDD424196502356BC5@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356C2B@INEXC1U01.in.lucent.com> <77ead0ec0811301039k1e279415tb4d5037b0c9e3a74@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356C2F@INEXC1U01.in.lucent.com> <77ead0ec0812010554jc86bb07gd79285bb31437c3e@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356D74@INEXC1U01.in.lucent.com> In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356D74@INEXC1U01.in.lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2128472105==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2128472105== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0267_01C953FC.16ECEE20" ------=_NextPart_000_0267_01C953FC.16ECEE20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Manav, I think we are splitting hairs here. IMHO it's completely speculative to say what real-life routers/firewalls will do when faced with a reserved SPI value. And I agree with Steve that a new protocol requires a new protocol number. Also, it strikes me as strange that existing routers which can detect ESP (in hardware, say) cannot be configured to pass through any packet with the new protocol number X. Moreover, the security of this access control policy (in the absence of deep inspection on the same router), is very debatable. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Bhatia, Manav (Manav) Sent: Monday, December 01, 2008 18:10 To: Vishwas Manral Cc: ipsec@ietf.org Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets Hi Vishwas, Let me reword my reply. A compliant implementation upon receiving the reserved value must accept it and process it accordingly. A non compliant implementation should drop this packet, as it comes with a reserved SPI. Cheers, Manav > -----Original Message----- > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Monday, December 01, 2008 7.24 PM > To: Bhatia, Manav (Manav) > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > > Hi Manav, > > > The transit routers would not care about this while the end routers > > should ignore such packets. In this case, the latter behavior is > > acceptable as end routers unaware of this extension would anyways be > > unable able to parse this packet. > How can we identify the difference between "unable to parse" a packet > vs "wrongly parsing a packet"? > > Thanks, > Vishwas > > On Sun, Nov 30, 2008 at 3:52 PM, Bhatia, Manav (Manav) > wrote: > > Hi Vishwas, > > > > [ .. ] > > > >> What would an IPsec router do in case it gets one of the > reserved SPI > >> values in the packet? > > > > The transit routers would not care about this while the end routers > > should ignore such packets. In this case, the latter behavior is > > acceptable as end routers unaware of this extension would anyways be > > unable able to parse this packet. > > > > Cheers, Manav > > > >> > >> Thanks again, > >> Vishwas > >> > >> On Sun, Nov 30, 2008 at 7:57 AM, Bhatia, Manav (Manav) > >> wrote: > >> > Hi Jack, > >> > > >> >> > could look at the 5th octet to know what the next-header > >> >> is. If you want > >> >> > the firewalls to be able to parse the L4 info then you > >> >> could include the > >> >> > ESP header length too. This could be the 6th octet. > >> Using this the > >> >> > >> >> I am assuming that you're mentioning ESP header length > >> explicitly to > >> >> account for the IV (if required, by the authentication > >> algorithm), as > >> >> otherwise its a fixed value and can always be inferred, right? > >> > > >> > Yes, that's correct. > >> > > >> > Cheers, Manav > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0267_01C953FC.16ECEE20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwMTE5MzA1M1owIwYJKoZIhvcNAQkEMRYEFGpQ+TK0MBcJ qnqqBgbRY0+nNxCfMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Jh2lUW5AunD3xgUQdyajiP/LIzrLKTHt7k0KMW0oIQhlBiso0xvtMXbbLiYzxLcPc914ywFTJ+qQ TH3aUWcOnUnNeoBLRsCtvq+KKG49VyS0qb+jZBWBIrTGk6n4HLEhWBQpVwBV3ajSecob5IRvm1qy FkR+nYRC2BjNP3JQksB2FDQ0h9p8yrHwTJfKZ02qcDUNhVaL7m2ob9PohFBUkZK8v8g83XVSJ8hK CZyzKPXN/DMEUn9/l0krYrKJZpqxvniuHrq7p/DEGNFiU3k5oKNkTIp9GlxtvtAkVPygYBmMjNmt X7nMaSAPpIopmqQbS6TrUsQAP+C8yo5UgzTezAAAAAAAAA== ------=_NextPart_000_0267_01C953FC.16ECEE20-- --===============2128472105== 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 --===============2128472105==-- From modinl@amada.com Mon Dec 1 13:27:50 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A451328C0F9 for ; Mon, 1 Dec 2008 13:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.387 X-Spam-Level: X-Spam-Status: No, score=-22.387 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax-3zgsJeEKy for ; Mon, 1 Dec 2008 13:27:50 -0800 (PST) Received: from aii.edu (87.68.81.42.cable.012.net.il [87.68.81.42]) by core3.amsl.com (Postfix) with SMTP id DCEE728C0F2 for ; Mon, 1 Dec 2008 13:27:48 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081201212748.DCEE728C0F2@core3.amsl.com> Date: Mon, 1 Dec 2008 13:27:48 -0800 (PST) Click here to view as a webpage. From ipsec-bounces@ietf.org Mon Dec 1 13:44: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 CB0283A67AD; Mon, 1 Dec 2008 13:44:30 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3743D3A67AD for ; Mon, 1 Dec 2008 13:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-+UqqGdK8IR for ; Mon, 1 Dec 2008 13:44:28 -0800 (PST) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by core3.amsl.com (Postfix) with ESMTP id 5E0163A67A4 for ; Mon, 1 Dec 2008 13:44:28 -0800 (PST) Received: from G6W0640.americas.hpqcorp.net (g6w0640.atlanta.hp.com [16.230.34.76]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id 71D74385D2 for ; Mon, 1 Dec 2008 21:44:24 +0000 (UTC) Received: from G6W0173.americas.hpqcorp.net (16.230.33.182) by G6W0640.americas.hpqcorp.net (16.230.34.76) with Microsoft SMTP Server (TLS) id 8.1.263.0; Mon, 1 Dec 2008 21:43:55 +0000 Received: from GVW0538EXC.americas.hpqcorp.net ([16.228.8.54]) by G6W0173.americas.hpqcorp.net ([16.230.33.182]) with mapi; Mon, 1 Dec 2008 21:43:55 +0000 From: "He, Wenxiao" To: Dan McDonald Date: Mon, 1 Dec 2008 21:43:53 +0000 Thread-Topic: [IPsec] [Ipsec] RFC 4301 and ICMP processing Thread-Index: AclOa/NrQYPHXMfzQmK8RwOVpBz7cwFkJJMw Message-ID: <769907F0D19EFA45BD6F04FC6E896D6D1EC0A0784F@GVW0538EXC.americas.hpqcorp.net> References: <4c5c7a6d0811172219j96ce787qd265ded48f4c60b6@mail.gmail.com> <18723.8781.499111.51370@fireball.kivinen.iki.fi> <4c5c7a6d0811181416h4ec9f7bew9579dbcf56f424bf@mail.gmail.com> <18724.14284.263786.286763@fireball.kivinen.iki.fi> <769907F0D19EFA45BD6F04FC6E896D6D1EBF8468A7@GVW0538EXC.americas.hpqcorp.net> <769907F0D19EFA45BD6F04FC6E896D6D1EC07E8312@GVW0538EXC.americas.hpqcorp.net> <20081124192837.GH2019@kebe.East.Sun.COM> In-Reply-To: <20081124192837.GH2019@kebe.East.Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [Ipsec] RFC 4301 and ICMP processing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Dan, Thanks for sharing that OpenSolaris has that feature. And sorry for late response (I am just back from vacation). Regards, Wenxiao > -----Original Message----- > From: Dan McDonald [mailto:danmcd@sun.com] > Sent: Monday, November 24, 2008 11:29 AM > To: He, Wenxiao > Cc: ipsec@ietf.org > Subject: Re: [IPsec] [Ipsec] RFC 4301 and ICMP processing > > On Mon, Nov 24, 2008 at 07:10:24PM +0000, He, Wenxiao wrote: > > > Now, consider a simple end-to-end case between host A and host B. > > > The SPD between A and B only specifies a SA for UDP, and > there is no > > > SPD to cover ICMP traffic. When host A sends a UDP > message to host > > > B, a SA pair is negotiated. And the > > > A->B UDP message triggers host B to send back an ICMP > error message. > > So far, so good. > > > > A) If I apply section 6.2 "Processing Protected, Transit > ICMP Error > > > Messages" to the B->A ICMP error message, the icmp error message > > > will be carried by the extant SA pair generated by UDP message. > > > > > > B) If I donot apply the process specified in section 6.2, > then the > > > ICMP ERROR message will be discarded because no SPD is found. > > > > > Which of the above two approaches is the expected behavior for an > > > IPsec end host? Does section 6 apply to IPsec end host? > > I can't say what everyone else does, but in {,Open}Solaris > we've always had ICMP errors reflect back with the same > policy (and SA) used by the traffic. > It makes sense from a not-leaking-information point-of-view. > > In fact, you've helped me find a bug with inbound ICMP > processing -- if an SA is tied to a protocol or port, ICMP > SPD checking needs to apply the *inner* packet selectors. > > Dan > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 00:40: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 1FBB83A6BF4; Tue, 2 Dec 2008 00:40:19 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1AA3A6BF4 for ; Tue, 2 Dec 2008 00:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.813 X-Spam-Level: X-Spam-Status: No, score=-2.813 tagged_above=-999 required=5 tests=[AWL=-0.214, 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 Rdn8mkrFYAN1 for ; Tue, 2 Dec 2008 00:40:16 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id 2F8F03A6AEB for ; Tue, 2 Dec 2008 00:40:16 -0800 (PST) Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id mB28e9vL012256; Tue, 2 Dec 2008 02:40:10 -0600 (CST) Received: from inexp02.in.lucent.com ([135.254.223.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 02:40:09 -0600 Received: from INEXC1U01.in.lucent.com ([135.254.223.27]) by inexp02.in.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 Dec 2008 14:10:03 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 2 Dec 2008 14:10:03 +0530 Message-ID: <6D26D1FE43A66F439F8109CDD424196502356E81@INEXC1U01.in.lucent.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclTyFbWSLmltVgxRnasTMXoFcPTEgAkRWmw References: <6D26D1FE43A66F439F8109CDD424196502356BC4@INEXC1U01.in.lucent.com> From: "Bhatia, Manav \(Manav\)" To: "Stephen Kent" X-OriginalArrivalTime: 02 Dec 2008 08:40:03.0998 (UTC) FILETIME=[924AFBE0:01C95459] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: ipsec@ietf.org Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Steve, We're just changing how the packet needs to be parsed when using the new SPI - the protocol still remains ESP! :-) This isn't as you already know, new in IETF, and a lot of proposals do this - they extend and change how an existing protocol packet needs to be parsed/formatted. Look at OSPFv2 and OSPFv3 - you parse the packet based on the version field that you have at the beginning. Packet formats are different, and but they still use the same protocol number - 89. To cite another example, you could look at the latest cryptographic authentication draft in IS-IS. It changes how the authentication data needs to be parsed, but continues to use the same Authentication TLV 10. It does not introduce a new TLV within IS-IS. In this case you differentiate between the different formats based on the SPI value, while, the underlying protocol still remains ESP! All rules applicable to ESP apply here too. We could have gone down the new proto-number path if there was *no* other alternative around. However, we seem to have an easy way out without using up a new number. How else do we otherwise intend to use the reserved values of SPI? Last but not the least, the protocol number field is of one byte and we have already taken up most of the numbers (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt). The only available range is from 140-252, which is quite narrow. I believe we must be chary in requesting for new numbers, otherwise we'll have a new extension tomorrow that expands this range from one octet to two octets! ;-) Cheers, Manav > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Monday, December 01, 2008 8.49 PM > To: Bhatia, Manav (Manav) > Cc: Jack Kohn; ipsec@ietf.org > Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > > Manav, > > If you have two SPIs (original and the new, reserved one) then the > format is no longer ESP and thus cannot reuse the ESP protocol number. > > the same argument applies to the proposal that the original SPI be > stuffed into the payload. > > Steve > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 05:13:33 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E9493A69E3; Tue, 2 Dec 2008 05:13:33 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EDB73A68E1; Tue, 2 Dec 2008 05:13:32 -0800 (PST) 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 BRiBIgmQfkf6; Tue, 2 Dec 2008 05:13:31 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id BF49C3A69B2; Tue, 2 Dec 2008 05:13:30 -0800 (PST) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB2DC1Il010683; Tue, 2 Dec 2008 06:12:01 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB2DDFNL192558; Tue, 2 Dec 2008 06:13:19 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB2DDEFS014346; Tue, 2 Dec 2008 06:13:15 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB2DDE7Y014340; Tue, 2 Dec 2008 06:13:14 -0700 In-Reply-To: <18739.63975.625276.269689@fireball.kivinen.iki.fi> References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 29BA5A43:B902C4E1-85257513:00464C5D; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 12/02/2008 08:05:04 AM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 12/02/2008 08:05:04 AM, Serialize complete at 12/02/2008 08:05:04 AM, S/MIME Sign failed at 12/02/2008 08:05:04 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_10262008HFIGS1|October 26, 2008) at 12/02/2008 06:13:14, Serialize complete at 12/02/2008 06:13:14 Message-ID: Date: Tue, 2 Dec 2008 08:13:14 -0500 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, manav@alcatel-lucent.com, Jack Kohn Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0644443125==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0644443125== Content-Type: multipart/alternative; boundary="=_alternative 0047E01985257513_=" This is a multipart message in MIME format. --=_alternative 0047E01985257513_= Content-Type: text/plain; charset="US-ASCII" Tero, I wanted to chime in briefly in support of your suggested heuristic approach over against the proposed drafts to modify the ESP protocol with new formats and/or protocol numbers. I prefer recommending a heuristic approach for the following reasons: 1) Creating new protocols and different formats places an undue burden on end-node implementations when there is already a viable heuristic approach that would require no end-node retooling. 2) Considering that end-node adoption of these drafts is realistically going to be slow and incomplete, a heuristic approach will be necessary in any case for any intermediate-node implementation that wishes to remain competitive. 3) Finally, considering industry, regulatory and governmental moves to adopt end-to-end encryption, I suspect that in the long term the use of ESP-NULL may be insignificant compared to using encryption. This would limit the usefulness of these drafts (or indeed any form of deep-packet inspection), and also make it harder for end-node implementations to justify spending resources to implement and support a new protocol. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: "Jack Kohn" Cc: ipsec@ietf.org, manav@alcatel-lucent.com Date: 12/01/2008 09:52 AM Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets Jack Kohn writes: > Heuristics is probability and is at best just an educated guess. Not really. For ESP-NULL there is always at least few bytes of self describing padding, which is very easy to check. After checking those the next ones to check is either the inner IP header (in case of tunnel mode) or TCP/UDP headers (in case of transport mode). All that checking nedes to only be done for the FIRST few packets, after the heuristics have identified the ICV length (currently 5 possible values in total, and currently only 1 of them is widely sued) and IV length (2 possible values and currently only 1 of them is widely used) then the information can be stored along the other flow specific information and no heuristics is needed after that. > I think the stakes are high as you would be dropping/forwarding > packets based on the probability that your model returns you. There is 1 out of 2^96 probability that random packet will pass your HMAC-SHA1-96 message check, so that is also probabilistic approach... If you check 8 bytes of self-describing padding and 4 bytes from the inner IP header (for tunnel mode) you get same probability... > Also, do you propose to do this in HW or SW? Either way is doable. I think the actual initial heuristics that is run when unknown source IP, destination IP and SPI value is found, would most likely be run on the softpath, as it makes adding things in future easier, but the actual per packet processing would most likely be run on the hardware. Only changes there would require adding SPI as one of the keys used when looking up the state information and getting ICV_len and IV_len from the per flow state and use those to get the protocol number. > Is there a model that you have in mind? I posted a example pseudocode for this earlier to this list. http://www.ietf.org/mail-archive/web/ipsec/current/msg03385.html > Do you have a study that you can share with us that gives some > numbers on how well this model works? My earlier email listed some numbers, so check those. There are also ways to make this even better without modifying the ESP packet format, but that would require changes to the ESP-NULL senders. I.e. the ESP-NULL senders could send at least 8 bytes of self-describing padding instead of the minimal amount, and with that change the probability of detecting ESP-NULL packet versuis ESP-encrypted packet with just one packet would go over 2^72 (8 bits of self-describing padding length, and 64 bits of padding). This is change we could do without breaking existing implementations, and it would usually be one or two line change to the code, i.e. something like: ---------------------------------------------------------------------- /* ... calculate normal pad_len here ... */ if (cipher == ESP_NULL) { pad_len += 8; } ---------------------------------------------------------------------- On the other hand if the implementation is already doing deep inspection of the packet (i.e. verifying urls and such inside the packets) then it will be checking more than enough bytes from the packet, that we do not need the extra bytes for the self-describing padding. The self-describing padding already gives you 99.998% - 99.999999999999999994% probability for detecting whether the first packet is ESP-NULL packet or ESP with encryption packet (depending how many bytes of padding there is (2-8 bytes)). And even then it would detect encrypted ESP packets as ESP-NULL because they happened to have correct bytes which looked like self-describing padding in the encrypted part. The packet would then be passed to the deep inspection part, which could not do deep inspection because the packet is encrypted. This would just cause some extra resources wasted when deep inspection engine tries to inspect those encrypted packets. The heuristics would never get it wrong in the other way, i.e detecting ESP-NULL packet as being encrypted, thus all ESP-NULL packets would be passed to the deep inspection part. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0047E01985257513_= Content-Type: text/html; charset="US-ASCII"
Tero, I wanted to chime in briefly in support of your suggested heuristic approach over against the proposed drafts to modify the ESP protocol with new formats and/or protocol numbers.  I prefer recommending a heuristic approach for the following reasons:

1) Creating new protocols and different formats places an undue burden on end-node implementations when there is already a viable heuristic approach that would require no end-node retooling.
2) Considering that end-node adoption of these drafts is realistically going to be slow and incomplete, a heuristic approach will be necessary in any case for any intermediate-node implementation that wishes to remain competitive.
3) Finally, considering industry, regulatory and governmental moves to adopt end-to-end encryption, I suspect that in the long term the use of ESP-NULL may be insignificant compared to using encryption.  This would limit the usefulness of these drafts (or indeed any form of deep-packet inspection), and also make it harder for end-node implementations to justify spending resources to implement and support a new protocol.


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


From: Tero Kivinen <kivinen@iki.fi>
To: "Jack Kohn" <kohn.jack@gmail.com>
Cc: ipsec@ietf.org, manav@alcatel-lucent.com
Date: 12/01/2008 09:52 AM
Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets




Jack Kohn writes:
> Heuristics is probability and is at best just an educated guess.

Not really. For ESP-NULL there is always at least few bytes of self
describing padding, which is very easy to check. After checking those
the next ones to check is either the inner IP header (in case of
tunnel mode) or TCP/UDP headers (in case of transport mode). All that
checking nedes to only be done for the FIRST few packets, after the
heuristics have identified the ICV length (currently 5 possible values
in total, and currently only 1 of them is widely sued) and IV length
(2 possible values and currently only 1 of them is widely used) then
the information can be stored along the other flow specific
information and no heuristics is needed after that.

> I think the stakes are high as you would be dropping/forwarding
> packets based on the probability that your model returns you.

There is 1 out of 2^96 probability that random packet will pass your
HMAC-SHA1-96 message check, so that is also probabilistic approach...
If you check 8 bytes of self-describing padding and 4 bytes from the
inner IP header (for tunnel mode) you get same probability...

> Also, do you propose to do this in HW or SW?

Either way is doable. I think the actual initial heuristics that is
run when unknown source IP, destination IP and SPI value is found,
would most likely be run on the softpath, as it makes adding things in
future easier, but the actual per packet processing would most likely
be run on the hardware. Only changes there would require adding SPI as
one of the keys used when looking up the state information and getting
ICV_len and IV_len from the per flow state and use those to get the
protocol number.

> Is there a model that you have in mind?

I posted a example pseudocode for this earlier to this list.
http://www.ietf.org/mail-archive/web/ipsec/current/msg03385.html

> Do you have a study that you can share with us that gives some
> numbers on how well this model works?

My earlier email listed some numbers, so check those.

There are also ways to make this even better without modifying the ESP
packet format, but that would require changes to the ESP-NULL senders.
I.e. the ESP-NULL senders could send at least 8 bytes of
self-describing padding instead of the minimal amount, and with that
change the probability of detecting ESP-NULL packet versuis
ESP-encrypted packet with just one packet would go over 2^72 (8 bits
of self-describing padding length, and 64 bits of padding).

This is change we could do without breaking existing implementations,
and it would usually be one or two line change to the code, i.e.
something like:
----------------------------------------------------------------------
 /* ... calculate normal pad_len here ... */
 if (cipher == ESP_NULL) {
    pad_len += 8;
 }
----------------------------------------------------------------------

On the other hand if the implementation is already doing deep
inspection of the packet (i.e. verifying urls and such inside the
packets) then it will be checking more than enough bytes from the
packet, that we do not need the extra bytes for the self-describing
padding. The self-describing padding already gives you 99.998% -
99.999999999999999994% probability for detecting whether the first
packet is ESP-NULL packet or ESP with encryption packet (depending
how many bytes of padding there is (2-8 bytes)).

And even then it would detect encrypted ESP packets as ESP-NULL
because they happened to have correct bytes which looked like
self-describing padding in the encrypted part. The packet would then
be passed to the deep inspection part, which could not do deep
inspection because the packet is encrypted. This would just cause some
extra resources wasted when deep inspection engine tries to inspect
those encrypted packets.

The heuristics would never get it wrong in the other way, i.e
detecting ESP-NULL packet as being encrypted, thus all ESP-NULL
packets would be passed to the deep inspection part.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 0047E01985257513_=-- --===============0644443125== 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 --===============0644443125==-- From ipsec-bounces@ietf.org Tue Dec 2 07:40: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 167783A6902; Tue, 2 Dec 2008 07:40:06 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68FC03A6897 for ; Tue, 2 Dec 2008 07:40:04 -0800 (PST) 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 FUIElt0HT8wY for ; Tue, 2 Dec 2008 07:39:57 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id 2F21B3A6902 for ; Tue, 2 Dec 2008 07:39:57 -0800 (PST) Received: by an-out-0708.google.com with SMTP id b6so1257446ana.4 for ; Tue, 02 Dec 2008 07:39:52 -0800 (PST) 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=04lQ8k2r6JAc9S7uNsysGYEqni2T4haHyIxIO8qj0f4=; b=cZ7Czuf/WpIUloPAmJ+1wGJWjoRwk/egFoS69FOy/KXpZh1Zx2YXsmn2r0pP35qf5/ VeLF28cW5//v9EvltGrefj/KYM7K0DMUsYvoWD2RyjKFv1uKm8nAgGzim5Q8LaNvsZSN uIJlGFV12jFQ0EiFGiWvz0nEr4vqwZHTIvF5Y= 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=RFQi4ayy1OiU1eWJRlIvrJ9wy8PC77j5FgXcXA3+Dgs/7lVilsqgYvOFMllIB43CR1 zPL/20Z9iWlL35pWTN9+0UA7L86VA2v+Sy8irIh8vbmteSwrg0XbmhgG9cwXjQEqJ60X XFlE4zTgri/GbCmeBmXqAbQzA0RUrjFZPprUc= Received: by 10.142.162.5 with SMTP id k5mr4265195wfe.15.1228232392350; Tue, 02 Dec 2008 07:39:52 -0800 (PST) Received: by 10.142.171.20 with HTTP; Tue, 2 Dec 2008 07:39:52 -0800 (PST) Message-ID: Date: Tue, 2 Dec 2008 21:09:52 +0530 From: "Jack Kohn" To: "Bhatia, Manav (Manav)" In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356E81@INEXC1U01.in.lucent.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356BC4@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356E81@INEXC1U01.in.lucent.com> Cc: ipsec@ietf.org, Stephen Kent Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt). > The only available range is from 140-252, which is quite narrow. I > believe we must be chary in requesting for new numbers, otherwise we'll > have a new extension tomorrow that expands this range from one octet to > two octets! ;-) :D Oh dont worry, its going to take some while before we exhaust all these numbers; then there are some left that can be reused .. > In this case you differentiate between the different formats based on > the SPI value, while, the underlying protocol still remains ESP! All > rules applicable to ESP apply here too. We could have gone > down the new > proto-number path if there was *no* other alternative around. However, > we seem to have an easy way out without using up a new I agree with the above sentiment - i dont think using a reserved SPI value makes the underlying protocol any different from the base ESP. > number. How else > do we otherwise intend to use the reserved values of SPI? The chairs and ADs could perhaps guide us here? Jack > Cheers, Manav > >> -----Original Message----- >> From: Stephen Kent [mailto:kent@bbn.com] >> Sent: Monday, December 01, 2008 8.49 PM >> To: Bhatia, Manav (Manav) >> Cc: Jack Kohn; ipsec@ietf.org >> Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets >> >> Manav, >> >> If you have two SPIs (original and the new, reserved one) then the >> format is no longer ESP and thus cannot reuse the ESP protocol number. >> >> the same argument applies to the proposal that the original SPI be >> stuffed into the payload. >> >> Steve >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 08:32: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 2761C28C124; Tue, 2 Dec 2008 08:32:02 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45013A6403 for ; Tue, 2 Dec 2008 08:32:00 -0800 (PST) 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 eQqDG7Fx8XYS for ; Tue, 2 Dec 2008 08:32:00 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 46C623A6902 for ; Tue, 2 Dec 2008 08:31:19 -0800 (PST) Received: from [10.20.30.158] (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 mB2GV9Q7094552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 09:31:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> Date: Tue, 2 Dec 2008 08:31:05 -0800 To: Scott C Moonen , Tero Kivinen From: Paul Hoffman Cc: ipsec@ietf.org Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 8:13 AM -0500 12/2/08, Scott C Moonen wrote: >Tero, I wanted to chime in briefly in support of your suggested heuristic approach over against the proposed drafts to modify the ESP protocol with new formats and/or protocol numbers. If you want this to be a serious consideration of the WG, we need more than brief chimes. Asking us to look in the archives for multiple messages listing some heuristics is a bit challenging. Could one or both of you put together an Internet Draft that lists all of the heuristics that you consider sufficient for detecting most ESP-NULL traffic? That would help the WG greatly! --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 08:38: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 932C33A6B7A; Tue, 2 Dec 2008 08:38:01 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58BFE3A6B7A for ; Tue, 2 Dec 2008 08:38:00 -0800 (PST) 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 KXZupZgq98tP for ; Tue, 2 Dec 2008 08:37:59 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 99F363A6924 for ; Tue, 2 Dec 2008 08:37:58 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A196E29C002; Tue, 2 Dec 2008 18:37:53 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5F0F129C001; Tue, 2 Dec 2008 18:37:52 +0200 (IST) X-CheckPoint: {493563AA-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB2GbpfE005669; Tue, 2 Dec 2008 18:37:51 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 2 Dec 2008 18:37:51 +0200 From: Yaron Sheffer To: Jack Kohn , "Bhatia, Manav (Manav)" Date: Tue, 2 Dec 2008 18:37:49 +0200 Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclUlEHnbyO0bQQZS8OXwX7Fo5h0jwABpfJQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FD1F@il-ex01.ad.checkpoint.com> References: <6D26D1FE43A66F439F8109CDD424196502356BC4@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356E81@INEXC1U01.in.lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Stephen Kent Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2051859916==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2051859916== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02E1_01C954AD.13D102B0" ------=_NextPart_000_02E1_01C954AD.13D102B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jack, In fact, I cannot imagine any good use for the reserved SPI values. But I don't think that when you use a "magic" SPI value, you are allowed to change the header format drastically. And shifting everything by 2 or 4 bytes is certainly drastic (e.g. to protocol analyzers, deep inspection engines, load balancers). Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Jack Kohn Sent: Tuesday, December 02, 2008 17:40 To: Bhatia, Manav (Manav) Cc: ipsec@ietf.org; Stephen Kent Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt). > The only available range is from 140-252, which is quite narrow. I > believe we must be chary in requesting for new numbers, otherwise we'll > have a new extension tomorrow that expands this range from one octet to > two octets! ;-) :D Oh dont worry, its going to take some while before we exhaust all these numbers; then there are some left that can be reused .. > In this case you differentiate between the different formats based on > the SPI value, while, the underlying protocol still remains ESP! All > rules applicable to ESP apply here too. We could have gone > down the new > proto-number path if there was *no* other alternative around. However, > we seem to have an easy way out without using up a new I agree with the above sentiment - i dont think using a reserved SPI value makes the underlying protocol any different from the base ESP. > number. How else > do we otherwise intend to use the reserved values of SPI? The chairs and ADs could perhaps guide us here? Jack > Cheers, Manav > >> -----Original Message----- >> From: Stephen Kent [mailto:kent@bbn.com] >> Sent: Monday, December 01, 2008 8.49 PM >> To: Bhatia, Manav (Manav) >> Cc: Jack Kohn; ipsec@ietf.org >> Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets >> >> Manav, >> >> If you have two SPIs (original and the new, reserved one) then the >> format is no longer ESP and thus cannot reuse the ESP protocol number. >> >> the same argument applies to the proposal that the original SPI be >> stuffed into the payload. >> >> Steve >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. ------=_NextPart_000_02E1_01C954AD.13D102B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwMjE2Mzc0OVowIwYJKoZIhvcNAQkEMRYEFF+BHEth1kEq VZ8Tn0dBp6rrQy/HMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA YHDt/MbansoPl4umRnU92LLRQhDBX8cKZd5w0X2zty2PiABd4OSCs+Ht1EHzt106dhuUVDrCWu0E 2wITV1e11jZ7dQkM6PbQic+M0GFK/7rrrzW1Zj+2uNA2ksC+zII6TCJRx0y756XcLqvVNi/M1GV0 OtgWZW0MGlUgypa1WyeL4Z1CuCjHcvOwX6G2vjcMD0M0Jx9OEVqNvhtqLjiybUksQmVNDY9BbLQ9 2Fq8URMVkyO3nag7r7Afw+IrfxSIT72k14Lht6xjJJ3/IcT31p9Dnh6LankuVNe34I/GV+TEZUAx WHDIcT2GO8ImBF1DYxodHHxEH+Qt1L3tXmg7WAAAAAAAAA== ------=_NextPart_000_02E1_01C954AD.13D102B0-- Email secured by Check Point --===============2051859916== 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 --===============2051859916==-- Email secured by Check Point From ipsec-bounces@ietf.org Tue Dec 2 08:52:37 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1297A3A67D0; Tue, 2 Dec 2008 08:52:37 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343BF3A67D0 for ; Tue, 2 Dec 2008 08:52:36 -0800 (PST) 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 jwtoPyrkuTmY for ; Tue, 2 Dec 2008 08:52:35 -0800 (PST) Received: from web81908.mail.mud.yahoo.com (web81908.mail.mud.yahoo.com [68.142.207.187]) by core3.amsl.com (Postfix) with SMTP id 379F03A6774 for ; Tue, 2 Dec 2008 08:52:35 -0800 (PST) Received: (qmail 61260 invoked by uid 60001); 2 Dec 2008 16:52:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=kxukgfe6DAOwWYX85b2UfEjRgO287uYLFb8/qS7sN3DVl6b9837awcMTAsnATWRzrogU5JcD9mqNIdUfGQsklywu/O3gopDF1xDqSSFOMr9s2NmyN69rgxD1FUKYHjrj2iZjOpF3qP6RM0GxzHGx3WqwEUOvkHiIgXu9/DyTM1Q=; X-YMail-OSG: Kp8PfvUVM1mFmGcn8Q7IOhBAmYqOmzAxLSRD4vYlWf7uvYPqzcVPHjB96cu47unwBArqNMLZaTHUzVK8aRQvXwDj.xwgwJ2Tg88i5ZmkV6yO1a.fyli5ANEAUukOrPda.OYiGnx2sPdWIVRkG30tyXBcUzbKKw2DK3AALHDP3rD.UuJ2jeETmpR.uA-- Received: from [24.16.88.165] by web81908.mail.mud.yahoo.com via HTTP; Tue, 02 Dec 2008 08:52:30 PST X-Mailer: YahooMailRC/1155.20 YahooMailWebService/0.7.218.2 Date: Tue, 2 Dec 2008 08:52:30 -0800 (PST) From: g_e_montenegro@yahoo.com To: Jack Kohn , "Bhatia, Manav \(Manav\)" MIME-Version: 1.0 Message-ID: <727584.61133.qm@web81908.mail.mud.yahoo.com> Cc: ipsec@ietf.org, Stephen Kent Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org VGhpcyBpZGVhIHdhcyBwcm9wb3NlZCBkdXJpbmcgdGhlIElFVEYgd2Vlay4gRmlyc3QgaW4gYW4g ZW1haWwgYnkgSmFtZXMgR29vZHdpbjoKCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9pcHNlYy9jdXJyZW50L21zZzAzMzU3Lmh0bWwKCmFuZCB0aGVuIGR1cmluZyB0aGUgbWVl dGluZyBpbiB0aGUgamFiYmVyIHJvb20gKGJ5IE1pY2hhZWwgUmljaGFyZHNvbiwgSSBiZWxpZXZl KS4gClRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gdGhhdCB3ZWVrIHdpdGggZGlmZmVyZW50IGZv bGtzIGFzIHdlbGwuIApUaGUgaWRlYSBpcyB0byBlZmZlY3QgdGhlIG1pbmltdW0gcG9zc2libGUg Y2hhbmdlcyB0byBJUHNlYyBpbiBvcmRlciB0byBhY2NvbW1vZGF0ZSB0aGUgbmV3IHVzYWdlLiBU aGF0IGlzIGEgd29ydGh5IGdvYWwuIEJ1dCB1c2luZyBzdWNoIGEgZml4ZWQgU1BJIG9ubHkgcmVz b2x2ZXMgdGhlIOKAnGRldGVybWluYXRpb27igJ0gcHJvYmxlbSAod2hldGhlciB0aGUgcGFja2V0 IGlzIEVTUC1OVUxMIG9yIGVuY3J5cHRlZCBFU1ApLiAKUmVzb2x2aW5nIHRoZSBwYXlsb2FkIOKA nGxvY2F0aW9u4oCdIGluIGEgaGFyZHdhcmUtZnJpZW5kbHkgbWFubmVyIHdvdWxkIGVuZCB1cCB3 aXRoIApzb21ldGhpbmcgbGlrZSB0aGUgV0VTUCBoZWFkZXIgaW1tZWRpYXRlbHkgZm9sbG93aW5n IHRoZSBmaXhlZCBTUEkgYW55d2F5cy4gIAoKVW5mb3J0dW5hdGVseSwgaGlqYWNraW5nIHRoZSBl eGlzdGluZyBFU1AgaW4gc3VjaCBhIG1hbm5lciBpcyBhIG1vcmUgc2lnbmlmaWNhbnQgCmNoYW5n ZSB0byB0aGUgSVBzZWMgYXJjaGl0ZWN0dXJlIHRoYW4gc2ltcGx5IGFkZGluZyBhIG5ldyBwcm90 b2NvbCBudW1iZXIuIApJbnRlcm1lZGlhdGUgZGV2aWNlcyB0aGF0IHdvdWxkIGRyb3AgdGhpcyB0 b2RheSB3b3VsZCBuZWVkIHRvIGJlIHJlY29uZmlndXJlZCwgeWVzLiAKQnV0IHRoZXNlIGZpbHRl cnMgYXJlIG5vdCBzdGF0aWMsIGFuZCBhcmUgYmVpbmcgbW9kaWZpZWQgYW5kIHR3ZWFrZWQgb24g YW4gb25nb2luZyAKYmFzaXMgYW55d2F5cywgYWRhcHRpbmcgdG8gdHJhZmZpYyBwYXR0ZXJucy4g SeKAmWQgYmUgc3VycHJpc2VkIGlmIHRoaXMgd2VyZSBhIHJlYWwgYmxvY2tlci4KCgoKCi0tLS0t IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLQo+IEZyb206IEphY2sgS29obiA8a29obi5qYWNrQGdtYWls LmNvbT4KPiBUbzogIkJoYXRpYSwgTWFuYXYgKE1hbmF2KSIgPG1hbmF2QGFsY2F0ZWwtbHVjZW50 LmNvbT4KPiBDYzogaXBzZWNAaWV0Zi5vcmc7IFN0ZXBoZW4gS2VudCA8a2VudEBiYm4uY29tPgo+ IFNlbnQ6IFR1ZXNkYXksIERlY2VtYmVyIDIsIDIwMDggNzozOTo1MiBBTQo+IFN1YmplY3Q6IFJl OiBbSVBzZWNdIERlZXAgSW5zcGVjdGluZyBFU1AtTlVMTCBQYWNrZXRzCj4gCj4gPiAoaHR0cDov L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9wcm90b2NvbC1udW1iZXJzL3Byb3RvY29sLW51bWJl cnMudHh0KS4KPiA+IFRoZSBvbmx5IGF2YWlsYWJsZSByYW5nZSBpcyBmcm9tIDE0MC0yNTIsIHdo aWNoIGlzIHF1aXRlIG5hcnJvdy4gSQo+ID4gYmVsaWV2ZSB3ZSBtdXN0IGJlIGNoYXJ5IGluIHJl cXVlc3RpbmcgZm9yIG5ldyBudW1iZXJzLCBvdGhlcndpc2Ugd2UnbGwKPiA+IGhhdmUgYSBuZXcg ZXh0ZW5zaW9uIHRvbW9ycm93IHRoYXQgZXhwYW5kcyB0aGlzIHJhbmdlIGZyb20gb25lIG9jdGV0 IHRvCj4gPiB0d28gb2N0ZXRzISA7LSkKPiAKPiA6RAo+IAo+IE9oIGRvbnQgd29ycnksIGl0cyBn b2luZyB0byB0YWtlIHNvbWUgd2hpbGUgYmVmb3JlIHdlIGV4aGF1c3QgYWxsCj4gdGhlc2UgbnVt YmVyczsgdGhlbiB0aGVyZSBhcmUgc29tZSBsZWZ0IHRoYXQgY2FuIGJlIHJldXNlZCAuLgo+IAo+ ID4gSW4gdGhpcyBjYXNlIHlvdSBkaWZmZXJlbnRpYXRlIGJldHdlZW4gdGhlIGRpZmZlcmVudCBm b3JtYXRzIGJhc2VkIG9uCj4gPiB0aGUgU1BJIHZhbHVlLCB3aGlsZSwgdGhlIHVuZGVybHlpbmcg cHJvdG9jb2wgc3RpbGwgcmVtYWlucyBFU1AhIEFsbAo+ID4gcnVsZXMgYXBwbGljYWJsZSB0byBF U1AgYXBwbHkgaGVyZSB0b28uIFdlIGNvdWxkIGhhdmUgZ29uZQo+ID4gZG93biB0aGUgbmV3Cj4g PiBwcm90by1udW1iZXIgcGF0aCBpZiB0aGVyZSB3YXMgKm5vKiBvdGhlciBhbHRlcm5hdGl2ZSBh cm91bmQuIEhvd2V2ZXIsCj4gPiB3ZSBzZWVtIHRvIGhhdmUgYW4gZWFzeSB3YXkgb3V0IHdpdGhv dXQgdXNpbmcgdXAgYSBuZXcKPiAKPiBJIGFncmVlIHdpdGggdGhlIGFib3ZlIHNlbnRpbWVudCAt IGkgZG9udCB0aGluayB1c2luZyBhIHJlc2VydmVkIFNQSQo+IHZhbHVlIG1ha2VzIHRoZSB1bmRl cmx5aW5nIHByb3RvY29sIGFueSBkaWZmZXJlbnQgZnJvbSB0aGUgYmFzZSBFU1AuCj4gCj4gPiBu dW1iZXIuIEhvdyBlbHNlCj4gPiBkbyB3ZSBvdGhlcndpc2UgaW50ZW5kIHRvIHVzZSB0aGUgcmVz ZXJ2ZWQgdmFsdWVzIG9mIFNQST8KPiAKPiBUaGUgY2hhaXJzIGFuZCBBRHMgY291bGQgcGVyaGFw cyBndWlkZSB1cyBoZXJlPwo+IAo+IEphY2sKPiAKPiA+IENoZWVycywgTWFuYXYKPiA+Cj4gPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiA+PiBGcm9tOiBTdGVwaGVuIEtlbnQgW21haWx0 bzprZW50QGJibi5jb21dCj4gPj4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAwMSwgMjAwOCA4LjQ5 IFBNCj4gPj4gVG86IEJoYXRpYSwgTWFuYXYgKE1hbmF2KQo+ID4+IENjOiBKYWNrIEtvaG47IGlw c2VjQGlldGYub3JnCj4gPj4gU3ViamVjdDogUmU6IFtJUHNlY10gRGVlcCBJbnNwZWN0aW5nIEVT UC1OVUxMIFBhY2tldHMKPiA+Pgo+ID4+IE1hbmF2LAo+ID4+Cj4gPj4gSWYgeW91IGhhdmUgdHdv IFNQSXMgKG9yaWdpbmFsIGFuZCB0aGUgbmV3LCByZXNlcnZlZCBvbmUpIHRoZW4gdGhlCj4gPj4g Zm9ybWF0IGlzIG5vIGxvbmdlciBFU1AgYW5kIHRodXMgY2Fubm90IHJldXNlIHRoZSBFU1AgcHJv dG9jb2wgbnVtYmVyLgo+ID4+Cj4gPj4gdGhlIHNhbWUgYXJndW1lbnQgYXBwbGllcyB0byB0aGUg cHJvcG9zYWwgdGhhdCB0aGUgb3JpZ2luYWwgU1BJIGJlCj4gPj4gc3R1ZmZlZCBpbnRvIHRoZSBw YXlsb2FkLgo+ID4+Cj4gPj4gU3RldmUKPiA+Pgo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiA+IElQc2VjIG1haWxpbmcgbGlzdAo+ID4gSVBzZWNA aWV0Zi5vcmcKPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMK PiA+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBJ UHNlYyBtYWlsaW5nIGxpc3QKPiBJUHNlY0BpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXBzZWMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCklQc2VjIG1haWxpbmcgbGlzdApJUHNlY0BpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjCg== From ipsec-bounces@ietf.org Tue Dec 2 08:56:41 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF91B28C13B; Tue, 2 Dec 2008 08:56:41 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6415E28C13B for ; Tue, 2 Dec 2008 08:56:40 -0800 (PST) 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 HJu79TRZvzHW for ; Tue, 2 Dec 2008 08:56:39 -0800 (PST) Received: from mail-gx0-f18.google.com (mail-gx0-f18.google.com [209.85.217.18]) by core3.amsl.com (Postfix) with ESMTP id 44F283A67D0 for ; Tue, 2 Dec 2008 08:56:39 -0800 (PST) Received: by gxk11 with SMTP id 11so451171gxk.13 for ; Tue, 02 Dec 2008 08:56:34 -0800 (PST) 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=T+Q3qi/IrMQr/5+39EN+71dNj6lWdyGkYcaBK+Pr/ig=; b=hOrRo09zt6GtIfAgNSZFFYrss/ux91OwZHiftg+nHqPbEgyePOb3O6lEgVHL/Mquck 14SaEPas488+U+tUT4uxU5GLIUizdOYBtvbeO+8at+ED4qj/2dKa4ipfgrDpCKtZU34Q iL+THSjf302S8euiQMOaoEb/DmWhiW31yTIwI= 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=jLdm/wA8eRhqPIBkah8ES8C+JX5qntbTXXW7NfZcIQyOR0yitQDD5NOfK3GKT71RpG GqNfBtokgFxMMw0JXmpnf0kyOC35DpizW68T+uOHRWutbYe7Nxjgv4uXkkJnMM9wDzAc vvtDZ1bmOm1k4n+pc6vysF2pRILSWdHSCSwYM= Received: by 10.143.7.5 with SMTP id k5mr4958737wfi.176.1228236993608; Tue, 02 Dec 2008 08:56:33 -0800 (PST) Received: by 10.142.171.20 with HTTP; Tue, 2 Dec 2008 08:56:33 -0800 (PST) Message-ID: Date: Tue, 2 Dec 2008 22:26:33 +0530 From: "Jack Kohn" To: "Yaron Sheffer" In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FD1F@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline References: <6D26D1FE43A66F439F8109CDD424196502356BC4@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356E81@INEXC1U01.in.lucent.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FD1F@il-ex01.ad.checkpoint.com> Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Stephen Kent Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > In fact, I cannot imagine any good use for the reserved SPI values. But I > don't think that when you use a "magic" SPI value, you are allowed to change > the header format drastically. And shifting everything by 2 or 4 bytes is I read the draft again (can the author please post it, as its extremely inconvenient reading it from a mail attachment .. ) and verified that the header remains the same; its the payload thats modified. > certainly drastic (e.g. to protocol analyzers, deep inspection engines, load > balancers). To each his own, because to me a new protocol number is as inconveniencing, if not more, than changing the packet semantics. Are you suggesting that there are protocol analyzers, deep inspection engines, load balancers peeking inside ESP packets? What i am unable to fathom is that if they can be updated to understand the new protocol number, then why cant they be updated to parse the new SPI type? Jack > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Jack Kohn > Sent: Tuesday, December 02, 2008 17:40 > To: Bhatia, Manav (Manav) > Cc: ipsec@ietf.org; Stephen Kent > Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > >> (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt). >> The only available range is from 140-252, which is quite narrow. I >> believe we must be chary in requesting for new numbers, otherwise we'll >> have a new extension tomorrow that expands this range from one octet to >> two octets! ;-) > > :D > > Oh dont worry, its going to take some while before we exhaust all > these numbers; then there are some left that can be reused .. > >> In this case you differentiate between the different formats based on >> the SPI value, while, the underlying protocol still remains ESP! All >> rules applicable to ESP apply here too. We could have gone >> down the new >> proto-number path if there was *no* other alternative around. However, >> we seem to have an easy way out without using up a new > > I agree with the above sentiment - i dont think using a reserved SPI > value makes the underlying protocol any different from the base ESP. > >> number. How else >> do we otherwise intend to use the reserved values of SPI? > > The chairs and ADs could perhaps guide us here? > > Jack > >> Cheers, Manav >> >>> -----Original Message----- >>> From: Stephen Kent [mailto:kent@bbn.com] >>> Sent: Monday, December 01, 2008 8.49 PM >>> To: Bhatia, Manav (Manav) >>> Cc: Jack Kohn; ipsec@ietf.org >>> Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets >>> >>> Manav, >>> >>> If you have two SPIs (original and the new, reserved one) then the >>> format is no longer ESP and thus cannot reuse the ESP protocol number. >>> >>> the same argument applies to the proposal that the original SPI be >>> stuffed into the payload. >>> >>> Steve >>> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 09:03: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 3EFF728C117; Tue, 2 Dec 2008 09:03:47 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13C023A67D0 for ; Tue, 2 Dec 2008 09:03:46 -0800 (PST) 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 B7mJ3uaqWACR for ; Tue, 2 Dec 2008 09:03:45 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id F3D7C3A67D6 for ; Tue, 2 Dec 2008 09:03:44 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so1303104yxg.49 for ; Tue, 02 Dec 2008 09:03:40 -0800 (PST) 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=IXd/1x9nfqFVUjKzFGhE4Jk+iWQHjQPxU1+2gxvORf0=; b=pJsYTNef34ebydjApDlrZjW4J2LRNBI5Ua0N2effARJpiTeDTPaOkJzSXD6YW4zo7n zRvBXgcNHRF7pvdZanwXzS8ytiXU/S/yJN/Z389LTfbyyT4sUJKj2c5D96DONjn3dV/I ZlWVGMEMKtNZlPwIzSSqqca69PPdQLE1q9D9I= 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=NknwLZYYcFgnhxouWMOqPmqcVJVsdthX62BL8MU/jWrwDz70Nc8sMz691hh2wxXYXm BXKxh/GsRtxOKrKMeOkrtm2XCs/OVVZ1pOTseRjJmvg9YOVrJYm7GMrSV4eFSFUQARGS jcFB3BAl1C+GKVCf6nHp+C1akoKfAWWuNU37s= Received: by 10.142.187.8 with SMTP id k8mr4968790wff.48.1228237420042; Tue, 02 Dec 2008 09:03:40 -0800 (PST) Received: by 10.142.171.20 with HTTP; Tue, 2 Dec 2008 09:03:39 -0800 (PST) Message-ID: Date: Tue, 2 Dec 2008 22:33:39 +0530 From: "Jack Kohn" To: g_e_montenegro@yahoo.com In-Reply-To: <727584.61133.qm@web81908.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Disposition: inline References: <727584.61133.qm@web81908.mail.mud.yahoo.com> Cc: ipsec@ietf.org, "Bhatia, Manav \(Manav\)" , Stephen Kent Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Gabriel, > Resolving the payload "location" in a hardware-friendly manner would end up with > something like the WESP header immediately following the fixed SPI anyways. Yes. > > Unfortunately, hijacking the existing ESP in such a manner is a more significant > change to the IPsec architecture than simply adding a new protocol number. > Intermediate devices that would drop this today would need to be reconfigured, yes. You can only reconfigure them to accept a new protocol type packet. > But these filters are not static, and are being modified and tweaked on an ongoing > basis anyways, adapting to traffic patterns. I'd be surprised if this were a real blocker. You would need a SW upgrade to be able to do anything meaningful with that (deep inspect, etc). Jack > > > > > ----- Original Message ---- >> From: Jack Kohn >> To: "Bhatia, Manav (Manav)" >> Cc: ipsec@ietf.org; Stephen Kent >> Sent: Tuesday, December 2, 2008 7:39:52 AM >> Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets >> >> > (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt). >> > The only available range is from 140-252, which is quite narrow. I >> > believe we must be chary in requesting for new numbers, otherwise we'll >> > have a new extension tomorrow that expands this range from one octet to >> > two octets! ;-) >> >> :D >> >> Oh dont worry, its going to take some while before we exhaust all >> these numbers; then there are some left that can be reused .. >> >> > In this case you differentiate between the different formats based on >> > the SPI value, while, the underlying protocol still remains ESP! All >> > rules applicable to ESP apply here too. We could have gone >> > down the new >> > proto-number path if there was *no* other alternative around. However, >> > we seem to have an easy way out without using up a new >> >> I agree with the above sentiment - i dont think using a reserved SPI >> value makes the underlying protocol any different from the base ESP. >> >> > number. How else >> > do we otherwise intend to use the reserved values of SPI? >> >> The chairs and ADs could perhaps guide us here? >> >> Jack >> >> > Cheers, Manav >> > >> >> -----Original Message----- >> >> From: Stephen Kent [mailto:kent@bbn.com] >> >> Sent: Monday, December 01, 2008 8.49 PM >> >> To: Bhatia, Manav (Manav) >> >> Cc: Jack Kohn; ipsec@ietf.org >> >> Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets >> >> >> >> Manav, >> >> >> >> If you have two SPIs (original and the new, reserved one) then the >> >> format is no longer ESP and thus cannot reuse the ESP protocol number. >> >> >> >> the same argument applies to the proposal that the original SPI be >> >> stuffed into the payload. >> >> >> >> Steve >> >> >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> > >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 09:08:14 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB153A6902; Tue, 2 Dec 2008 09:08:14 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748403A6902 for ; Tue, 2 Dec 2008 09:08:13 -0800 (PST) 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 vxYTwJnzsWUw for ; Tue, 2 Dec 2008 09:08:12 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 759643A6774 for ; Tue, 2 Dec 2008 09:08:11 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 77E8029C002; Tue, 2 Dec 2008 19:08:06 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 50E1B29C001; Tue, 2 Dec 2008 19:08:05 +0200 (IST) X-CheckPoint: {49356ABE-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB2H84fE013505; Tue, 2 Dec 2008 19:08:04 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 2 Dec 2008 19:08:04 +0200 From: Yaron Sheffer To: Jack Kohn Date: Tue, 2 Dec 2008 19:08:06 +0200 Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclUnvEvMgIz34//SfCvDKyPrgek+gAAG9XQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FD2B@il-ex01.ad.checkpoint.com> References: <6D26D1FE43A66F439F8109CDD424196502356BC4@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356E81@INEXC1U01.in.lucent.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FD1F@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Stephen Kent Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0190876760==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0190876760== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_030E_01C954B1.4EA090A0" ------=_NextPart_000_030E_01C954B1.4EA090A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jack, I am not following you: the draft has the fixed SPI, then sequence number, then another SPI, then payload. ESP has SPI, sequence number, payload. Of course the header is changed! Realistically, if people look at ANYTHING in these packets, it'll be the SPI. And you've just ruined their day :-) They can certainly change their code, but until they do, I would like them to identify the packets as strange and unknown instead of misunderstanding them as regular ESP and treating them incorrectly. Thanks, Yaron -----Original Message----- From: Jack Kohn [mailto:kohn.jack@gmail.com] Sent: Tuesday, December 02, 2008 18:57 To: Yaron Sheffer Cc: Bhatia, Manav (Manav); ipsec@ietf.org; Stephen Kent Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > In fact, I cannot imagine any good use for the reserved SPI values. But I > don't think that when you use a "magic" SPI value, you are allowed to change > the header format drastically. And shifting everything by 2 or 4 bytes is I read the draft again (can the author please post it, as its extremely inconvenient reading it from a mail attachment .. ) and verified that the header remains the same; its the payload thats modified. > certainly drastic (e.g. to protocol analyzers, deep inspection engines, load > balancers). To each his own, because to me a new protocol number is as inconveniencing, if not more, than changing the packet semantics. Are you suggesting that there are protocol analyzers, deep inspection engines, load balancers peeking inside ESP packets? What i am unable to fathom is that if they can be updated to understand the new protocol number, then why cant they be updated to parse the new SPI type? Jack > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Jack Kohn > Sent: Tuesday, December 02, 2008 17:40 > To: Bhatia, Manav (Manav) > Cc: ipsec@ietf.org; Stephen Kent > Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > >> (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt). >> The only available range is from 140-252, which is quite narrow. I >> believe we must be chary in requesting for new numbers, otherwise we'll >> have a new extension tomorrow that expands this range from one octet to >> two octets! ;-) > > :D > > Oh dont worry, its going to take some while before we exhaust all > these numbers; then there are some left that can be reused .. > >> In this case you differentiate between the different formats based on >> the SPI value, while, the underlying protocol still remains ESP! All >> rules applicable to ESP apply here too. We could have gone >> down the new >> proto-number path if there was *no* other alternative around. However, >> we seem to have an easy way out without using up a new > > I agree with the above sentiment - i dont think using a reserved SPI > value makes the underlying protocol any different from the base ESP. > >> number. How else >> do we otherwise intend to use the reserved values of SPI? > > The chairs and ADs could perhaps guide us here? > > Jack > >> Cheers, Manav >> >>> -----Original Message----- >>> From: Stephen Kent [mailto:kent@bbn.com] >>> Sent: Monday, December 01, 2008 8.49 PM >>> To: Bhatia, Manav (Manav) >>> Cc: Jack Kohn; ipsec@ietf.org >>> Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets >>> >>> Manav, >>> >>> If you have two SPIs (original and the new, reserved one) then the >>> format is no longer ESP and thus cannot reuse the ESP protocol number. >>> >>> the same argument applies to the proposal that the original SPI be >>> stuffed into the payload. >>> >>> Steve >>> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_030E_01C954B1.4EA090A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwMjE3MDgwNlowIwYJKoZIhvcNAQkEMRYEFLG2oYzxctFe fBFdTR994L61xXaSMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA rdU46RlQIEp2FasubTkFeVf0TBco/9eni2w8Um+2q21cHA9DhJcyZoazFvgfc74z3G2r1LIXiqOt 7qXSxS1KfVkef4le2Xb5PSmEE6alzdER9g9ojo4GCmeInMztY0RID6VdxLmL9+znxSwz+C4bAYmE 6CHs+TpBBBJ7PBVS/v1mw0XyZ04w4rc0jpDwbXImebK/UQ4f8ayTR7hWOLV5w5nVal0syB/eLzwv 01IQArHGc9B3jRp4aAZdNdfnAy25Qkh4h7mN9DTmBLdjqs5Q4iA/b+k+JCOoN8RbR5ErQgHIF2LU N3WaD99c4EsrPH9B7e8X/BtovQTkN3f4qMAJiAAAAAAAAA== ------=_NextPart_000_030E_01C954B1.4EA090A0-- Email secured by Check Point --===============0190876760== 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 --===============0190876760==-- Email secured by Check Point From ipsec-bounces@ietf.org Tue Dec 2 09:08: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 04AAE3A6B73; Tue, 2 Dec 2008 09:08:51 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609C83A6B73 for ; Tue, 2 Dec 2008 09:08:50 -0800 (PST) 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 V5WP1zL2Oufk for ; Tue, 2 Dec 2008 09:08:49 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 51CA23A6902 for ; Tue, 2 Dec 2008 09:08:49 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 02 Dec 2008 09:02:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.33,702,1220252400"; d="scan'208";a="470345947" Received: from unknown (HELO azsmsx601.amr.corp.intel.com) ([10.2.121.193]) by orsmga001.jf.intel.com with ESMTP; 02 Dec 2008 09:07:27 -0800 Received: from rrsmsx604.amr.corp.intel.com (10.31.0.170) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 2 Dec 2008 10:08:36 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Tue, 2 Dec 2008 10:08:35 -0700 From: "Grewal, Ken" To: Yaron Sheffer , "Bhatia, Manav (Manav)" , Vishwas Manral Date: Tue, 2 Dec 2008 10:08:18 -0700 Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclTvFw1CmB5541FS2y3UoR2tQkwOwAErimQAAZb7OAALe5SYA== Message-ID: References: <6D26D1FE43A66F439F8109CDD424196502356B45@INEXC1U01.in.lucent.com> <01f901c95173$5199e9a0$54f4200a@amer.cisco.com> <6D26D1FE43A66F439F8109CDD424196502356BC5@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356C2B@INEXC1U01.in.lucent.com> <77ead0ec0811301039k1e279415tb4d5037b0c9e3a74@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356C2F@INEXC1U01.in.lucent.com> <77ead0ec0812010554jc86bb07gd79285bb31437c3e@mail.gmail.com> <6D26D1FE43A66F439F8109CDD424196502356D74@INEXC1U01.in.lucent.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FBD7@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FBD7@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I agree with Yaron, but am open to other opinions also. The proposal from Manav is essentially similar (except moving a few fields around) to the UDP-Encapsulation proposal for NAT-T from the current WG draft (but applied to ESP, instead of/as well as NAT-T), where a reserved value of the SPI is used to differentiate between existing ESP encapsulation and a new one. Some additional observations: - We considered this originally and then benched it favoring a new protocol definition for the new encapsulation. Having said that, it is good to get the discussion officially on the table to get wider perspective from the participants. - The reason we added the additional reserved SPI into NAT-T and not natively in ESP was that the additional field (Non-ESP marker) was already present in NAT-T for demuxing between IKE and ESP traffic when using NAT-T. - Some people made observations that there may be home brewed solutions where intermediate devices may be attempting to parse legacy ESP traffic, hence (as Yaron indicates below), it is speculative as to what real-life routers / firewalls do when faced with a reserved SPI value - hence a clean break in using a new protocol. Note** If such devices/solutions do exist, they will break if we keep the existing ESP protocol and modify the packet format. - In a separate thread, there have been questions on how legacy devices behave when seeing a new, unrecognized protocol - We face the same issues each time we introduce a new protocol (e.g. HIP, UDP-Lite, mobility headers, etc.). Although the introduction of a new protocol is infrequent, these are still being introduced on a periodic basis, hence legacy devices need to cater for these, so no difference here. Thanks, - Ken >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Yaron Sheffer >Sent: Monday, December 01, 2008 11:31 AM >To: Bhatia, Manav (Manav); Vishwas Manral >Cc: ipsec@ietf.org >Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > >Hi Manav, > >I think we are splitting hairs here. IMHO it's completely speculative to >say >what real-life routers/firewalls will do when faced with a reserved SPI >value. > >And I agree with Steve that a new protocol requires a new protocol number. >Also, it strikes me as strange that existing routers which can detect ESP >(in hardware, say) cannot be configured to pass through any packet with the >new protocol number X. Moreover, the security of this access control policy >(in the absence of deep inspection on the same router), is very debatable. > >Thanks, > Yaron > >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Bhatia, Manav (Manav) >Sent: Monday, December 01, 2008 18:10 >To: Vishwas Manral >Cc: ipsec@ietf.org >Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > >Hi Vishwas, > >Let me reword my reply. > >A compliant implementation upon receiving the reserved value must accept >it and process it accordingly. A non compliant implementation should >drop this packet, as it comes with a reserved SPI. > >Cheers, Manav > >> -----Original Message----- >> From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] >> Sent: Monday, December 01, 2008 7.24 PM >> To: Bhatia, Manav (Manav) >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets >> >> Hi Manav, >> >> > The transit routers would not care about this while the end routers >> > should ignore such packets. In this case, the latter behavior is >> > acceptable as end routers unaware of this extension would anyways be >> > unable able to parse this packet. >> How can we identify the difference between "unable to parse" a packet >> vs "wrongly parsing a packet"? >> >> Thanks, >> Vishwas >> >> On Sun, Nov 30, 2008 at 3:52 PM, Bhatia, Manav (Manav) >> wrote: >> > Hi Vishwas, >> > >> > [ .. ] >> > >> >> What would an IPsec router do in case it gets one of the >> reserved SPI >> >> values in the packet? >> > >> > The transit routers would not care about this while the end routers >> > should ignore such packets. In this case, the latter behavior is >> > acceptable as end routers unaware of this extension would anyways be >> > unable able to parse this packet. >> > >> > Cheers, Manav >> > >> >> >> >> Thanks again, >> >> Vishwas >> >> >> >> On Sun, Nov 30, 2008 at 7:57 AM, Bhatia, Manav (Manav) >> >> wrote: >> >> > Hi Jack, >> >> > >> >> >> > could look at the 5th octet to know what the next-header >> >> >> is. If you want >> >> >> > the firewalls to be able to parse the L4 info then you >> >> >> could include the >> >> >> > ESP header length too. This could be the 6th octet. >> >> Using this the >> >> >> >> >> >> I am assuming that you're mentioning ESP header length >> >> explicitly to >> >> >> account for the IV (if required, by the authentication >> >> algorithm), as >> >> >> otherwise its a fixed value and can always be inferred, right? >> >> > >> >> > Yes, that's correct. >> >> > >> >> > Cheers, Manav >> > >> >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec > >Scanned by Check Point Total Security Gateway. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 10:07: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 8114228C18D; Tue, 2 Dec 2008 10:07:25 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46C428C10A; Tue, 2 Dec 2008 10:07:24 -0800 (PST) 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 TmdvTU-THOKt; Tue, 2 Dec 2008 10:07:13 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 30C9E28C1A4; Tue, 2 Dec 2008 10:07:13 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 02 Dec 2008 10:00:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.33,702,1220252400"; d="scan'208,217";a="410721753" Received: from azsmsx602.amr.corp.intel.com ([10.2.121.201]) by fmsmga002.fm.intel.com with ESMTP; 02 Dec 2008 10:02:46 -0800 Received: from rrsmsx002.amr.corp.intel.com (10.31.0.34) by azsmsx602.amr.corp.intel.com (10.2.121.201) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 2 Dec 2008 11:03:27 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx002.amr.corp.intel.com ([10.31.0.34]) with mapi; Tue, 2 Dec 2008 11:03:26 -0700 From: "Grewal, Ken" To: Scott C Moonen , Tero Kivinen Date: Tue, 2 Dec 2008 11:03:09 -0700 Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclUf8wH4UEf4A0RRRmPLxw4G+J2owAIxKTA Message-ID: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "ipsec-bounces@ietf.org" , "manav@alcatel-lucent.com" , Jack Kohn Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0607828598==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0607828598== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_C49B4B6450D9AA48AB99694D2EB0A48308E92C9Arrsmsx505amrcor_" --_000_C49B4B6450D9AA48AB99694D2EB0A48308E92C9Arrsmsx505amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott, Heuristics based solutions can be expensive to implement in HW as well as b= eing inconclusive, providing assurances based on probabilities and hence pr= one to false positives. Furthermore, some HW devices (especially Network Interface Cards, NICs) cur= rently only examine packet headers and do not load the whole packet into me= mory. In aggregated environments, where these devices need to maintain line= rate processing, subtle changes in design such as loading the whole packet= into memory and parsing the packet trailer before making a decision if the= packet should be sent to one CPU core or another for processing will have = drastic impact on the packet processing engines of such devices (compared w= ith a simple, deterministic approach such as in the current draft). As for the E2E encryption, I agree that there is some regulatory pressure t= o adopt this from a security perspective, but this is also competing with e= ntrenched solutions offering valuable network services for traffic monitori= ng and hence require traffic visibility - this is one of the reasons that E= 2E encryption is not widely employed today within Enterprise environments, = as it circumvents these network tools. The predominant use of IPsec today i= s in the remote access / VPN scenarios. Some people have also mentioned that E2E encryption offers a secure channel= for virus propagation, where the intermediate devices such as IDS/IPS are = left blind to the network traffic flow. Having said that, there was some discussion during the last IETF meeting an= d the mailing list on adding the 'integrity bit' back into the WESP header.= This was removed from the last draft and we could add this back in as it w= ill provide a consistent view of an IPsec packet indicating if the packet i= s encrypted or in the clear, as well as allowing future innovation on inter= mediate devices being able to examine encrypted data based on administrativ= e policy - food for thought. Thanks, - Ken ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= cott C Moonen Sent: Tuesday, December 02, 2008 5:13 AM To: Tero Kivinen Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; manav@alcatel-lucent.com; Jack = Kohn Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets Tero, I wanted to chime in briefly in support of your suggested heuristic a= pproach over against the proposed drafts to modify the ESP protocol with ne= w formats and/or protocol numbers. I prefer recommending a heuristic appro= ach for the following reasons: 1) Creating new protocols and different formats places an undue burden on e= nd-node implementations when there is already a viable heuristic approach t= hat would require no end-node retooling. 2) Considering that end-node adoption of these drafts is realistically goin= g to be slow and incomplete, a heuristic approach will be necessary in any = case for any intermediate-node implementation that wishes to remain competi= tive. 3) Finally, considering industry, regulatory and governmental moves to adop= t end-to-end encryption, I suspect that in the long term the use of ESP-NUL= L may be insignificant compared to using encryption. This would limit the = usefulness of these drafts (or indeed any form of deep-packet inspection), = and also make it harder for end-node implementations to justify spending re= sources to implement and support a new protocol. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: "Jack Kohn" Cc: ipsec@ietf.org, manav@alcatel-lucent.com Date: 12/01/2008 09:52 AM Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets ________________________________ Jack Kohn writes: > Heuristics is probability and is at best just an educated guess. Not really. For ESP-NULL there is always at least few bytes of self describing padding, which is very easy to check. After checking those the next ones to check is either the inner IP header (in case of tunnel mode) or TCP/UDP headers (in case of transport mode). All that checking nedes to only be done for the FIRST few packets, after the heuristics have identified the ICV length (currently 5 possible values in total, and currently only 1 of them is widely sued) and IV length (2 possible values and currently only 1 of them is widely used) then the information can be stored along the other flow specific information and no heuristics is needed after that. > I think the stakes are high as you would be dropping/forwarding > packets based on the probability that your model returns you. There is 1 out of 2^96 probability that random packet will pass your HMAC-SHA1-96 message check, so that is also probabilistic approach... If you check 8 bytes of self-describing padding and 4 bytes from the inner IP header (for tunnel mode) you get same probability... > Also, do you propose to do this in HW or SW? Either way is doable. I think the actual initial heuristics that is run when unknown source IP, destination IP and SPI value is found, would most likely be run on the softpath, as it makes adding things in future easier, but the actual per packet processing would most likely be run on the hardware. Only changes there would require adding SPI as one of the keys used when looking up the state information and getting ICV_len and IV_len from the per flow state and use those to get the protocol number. > Is there a model that you have in mind? I posted a example pseudocode for this earlier to this list. http://www.ietf.org/mail-archive/web/ipsec/current/msg03385.html > Do you have a study that you can share with us that gives some > numbers on how well this model works? My earlier email listed some numbers, so check those. There are also ways to make this even better without modifying the ESP packet format, but that would require changes to the ESP-NULL senders. I.e. the ESP-NULL senders could send at least 8 bytes of self-describing padding instead of the minimal amount, and with that change the probability of detecting ESP-NULL packet versuis ESP-encrypted packet with just one packet would go over 2^72 (8 bits of self-describing padding length, and 64 bits of padding). This is change we could do without breaking existing implementations, and it would usually be one or two line change to the code, i.e. something like: ---------------------------------------------------------------------- /* ... calculate normal pad_len here ... */ if (cipher =3D=3D ESP_NULL) { pad_len +=3D 8; } ---------------------------------------------------------------------- On the other hand if the implementation is already doing deep inspection of the packet (i.e. verifying urls and such inside the packets) then it will be checking more than enough bytes from the packet, that we do not need the extra bytes for the self-describing padding. The self-describing padding already gives you 99.998% - 99.999999999999999994% probability for detecting whether the first packet is ESP-NULL packet or ESP with encryption packet (depending how many bytes of padding there is (2-8 bytes)). And even then it would detect encrypted ESP packets as ESP-NULL because they happened to have correct bytes which looked like self-describing padding in the encrypted part. The packet would then be passed to the deep inspection part, which could not do deep inspection because the packet is encrypted. This would just cause some extra resources wasted when deep inspection engine tries to inspect those encrypted packets. The heuristics would never get it wrong in the other way, i.e detecting ESP-NULL packet as being encrypted, thus all ESP-NULL packets would be passed to the deep inspection part. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_C49B4B6450D9AA48AB99694D2EB0A48308E92C9Arrsmsx505amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott,

Heuristics based solutions can be expensive to implement in HW as well as being inconclusive, providing assurances based on probabilities and hence prone to false positives. =

Furthermore, some HW devices (especial= ly Network Interface Cards, NICs) currently only examine packet headers and do not loa= d the whole packet into memory. In aggregated environments, where these devic= es need to maintain line rate processing, subtle changes in design such as loa= ding the whole packet into memory and parsing the packet trailer before making a decision if the packet should be sent to one CPU core or another for proces= sing will have drastic impact on the packet processing engines of such devices (compared with a simple, deterministic approach such as in the current draf= t).

 

As for the E2E encryption, I agree tha= t there is some regulatory pressure to adopt this from a security perspective= , but this is also competing with entrenched solutions offering valuable netw= ork services for traffic monitoring and hence require traffic visibility – this is= one of the reasons that E2E encryption is not widely employed today within Enterprise environments, as it circumvents these network tools. The predomi= nant use of IPsec today is in the remote access / VPN scenarios.

Some people have also mentioned that E= 2E encryption offers a secure channel for virus propagation, where the intermediate devices such as IDS/IPS are left blind to the network traffic flow.

 

Having said that, there was some discussion during the last IETF meeting and the mailing list on adding the = ‘integrity bit’ back into the WESP header. This was removed from the last draft = and we could add this back in as it will provide a consistent view of an IPsec pac= ket indicating if the packet is encrypted or in the clear, as well as allowing future innovation on intermediate devices being able to examine encrypted d= ata based on administrative policy – food for thought.  <= /span>

 

<= span style=3D'font-size:12.0pt;color:navy'>Thanks,

<= span style=3D'font-size:12.0pt;color:navy'>- Ken

 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott C Moonen
Sent: Tuesday, December 02, = 2008 5:13 AM
To: Tero Kivinen
Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; manav@alcatel-lucent.com; Jack Kohn
Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets

 


Tero, I wanted to chime in briefly in support of yo= ur suggested heuristic approach over against the proposed drafts to modify the= ESP protocol with new formats and/or protocol numbers.  I prefer recommend= ing a heuristic approach for the following reasons:

1) Creating new protocols and different formats places an undue burden on end-= node implementations when there is already a viable heuristic approach that woul= d require no end-node retooling.
2) Considering that end-node adoption of these drafts is realistically going t= o be slow and incomplete, a heuristic approach will be necessary in any case for= any intermediate-node implementation that wishes to remain competitive.<= /font>
3) Finally, considering industry, regulatory and governmental moves to adopt end-to-end encryption, I suspect that in the long term the use of ESP-NULL = may be insignificant compared to using encryption.  This would limit the usefulness of these drafts (or indeed any form of deep-packet inspection), = and also make it harder for end-node implementations to justify spending resour= ces to implement and support a new protocol.


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

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>From:

Tero Kivinen <kivinen@iki.fi>=

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>To:=

"Jack Kohn" <kohn.jack@gmail.com>=

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>Cc:=

ipsec@ietf.org, manav@alcatel-lucent.com

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>Date:

12/01/2008 09:52 AM

<= span style=3D'font-size:7.5pt;font-family:sans-serif;color:#5F5F5F'>Subject:

Re: [IPsec] Deep Inspecting ESP-NULL Packets

 




Jack Kohn writes:
> Heuristics is probability and is at bes= t just an educated guess.

Not really. For ESP-NULL there is always at = least few bytes of self
describing padding, which is very easy to ch= eck. After checking those
the next ones to check is either the inner I= P header (in case of
tunnel mode) or TCP/UDP headers (in case of transport mode). All that
checking nedes to only be done for the FIRST= few packets, after the
heuristics have identified the ICV length (currently 5 possible values
in total, and currently only 1 of them is wi= dely sued) and IV length
(2 possible values and currently only 1 of t= hem is widely used) then
the information can be stored along the othe= r flow specific
information and no heuristics is needed afte= r that.

> I think the stakes are high as you woul= d be dropping/forwarding
> packets based on the probability that y= our model returns you.

There is 1 out of 2^96 probability that rand= om packet will pass your
HMAC-SHA1-96 message check, so that is also probabilistic approach...
If you check 8 bytes of self-describing padd= ing and 4 bytes from the
inner IP header (for tunnel mode) you get sa= me probability...

> Also, do you propose to do this in HW o= r SW?

Either way is doable. I think the actual ini= tial heuristics that is
run when unknown source IP, destination IP a= nd SPI value is found,
would most likely be run on the softpath, as= it makes adding things in
future easier, but the actual per packet processing would most likely
be run on the hardware. Only changes there w= ould require adding SPI as
one of the keys used when looking up the sta= te information and getting
ICV_len and IV_len from the per flow state a= nd use those to get the
protocol number.

> Is there a model that you have in mind?=

I posted a example pseudocode for this earli= er to this list.
<= tt>http://www.i= etf.org/mail-archive/web/ipsec/current/msg03385.html=

> Do you have a study that you can share = with us that gives some
> numbers on how well this model works?

My earlier email listed some numbers, so che= ck those.

There are also ways to make this even better without modifying the ESP
packet format, but that would require change= s to the ESP-NULL senders.
I.e. the ESP-NULL senders could send at leas= t 8 bytes of
self-describing padding instead of the minim= al amount, and with that
change the probability of detecting ESP-NULL packet versuis
ESP-encrypted packet with just one packet wo= uld go over 2^72 (8 bits
of self-describing padding length, and 64 bi= ts of padding).

This is change we could do without breaking = existing implementations,
and it would usually be one or two line chan= ge to the code, i.e.
something like:
--------------------------------------------= --------------------------
 /* ... calculate normal pad_len here .= .. */
 if (cipher =3D=3D ESP_NULL) {
    pad_len +=3D 8;  }
--------------------------------------------= --------------------------

On the other hand if the implementation is a= lready doing deep
inspection of the packet (i.e. verifying url= s and such inside the
packets) then it will be checking more than = enough bytes from the
packet, that we do not need the extra bytes = for the self-describing
padding. The self-describing padding already= gives you 99.998% -
99.999999999999999994% probability for detec= ting whether the first
packet is ESP-NULL packet or ESP with encryp= tion packet (depending
how many bytes of padding there is (2-8 byte= s)).

And even then it would detect encrypted ESP packets as ESP-NULL
because they happened to have correct bytes = which looked like
self-describing padding in the encrypted par= t. The packet would then
be passed to the deep inspection part, which= could not do deep
inspection because the packet is encrypted. = This would just cause some
extra resources wasted when deep inspection = engine tries to inspect
those encrypted packets.

The heuristics would never get it wrong in t= he other way, i.e
detecting ESP-NULL packet as being encrypted= , thus all ESP-NULL
packets would be passed to the deep inspecti= on part.
--
kivinen@iki.fi
____________________________________________= ___
IPsec mailing list
IPsec@ietf.org
<= font size=3D2 face=3D"Courier New">https://www.= ietf.org/mailman/listinfo/ipsec

--_000_C49B4B6450D9AA48AB99694D2EB0A48308E92C9Arrsmsx505amrcor_-- --===============0607828598== 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 --===============0607828598==-- From ipsec-bounces@ietf.org Tue Dec 2 10:35:35 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DD643A6B46; Tue, 2 Dec 2008 10:35:35 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895A63A6B46 for ; Tue, 2 Dec 2008 10:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Df8-RpEi2K3V for ; Tue, 2 Dec 2008 10:35:32 -0800 (PST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 439DC3A6B3A for ; Tue, 2 Dec 2008 10:35:32 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[69.58.70.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1L7a5n-0004Mo-Ek; Tue, 02 Dec 2008 13:35:27 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <6D26D1FE43A66F439F8109CDD424196502356E81@INEXC1U01.in.lucent.com> References: <6D26D1FE43A66F439F8109CDD424196502356BC4@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356E81@INEXC1U01.in.lucent.com> Date: Tue, 2 Dec 2008 13:35:32 -0500 To: "Bhatia, Manav \(Manav\)" From: Stephen Kent Cc: ipsec@ietf.org Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 2:10 PM +0530 12/2/08, Bhatia, Manav \(Manav\) wrote: >Hi Steve, > >We're just changing how the packet needs to be parsed when using the new >SPI - the protocol still remains ESP! :-) I have to disagree. ESP specifies a format with precise locations for the SPI and sequence number in the header. When you hide the original SPI somewhere else in the ESP payload, that constitutes a change to the protocol format. >This isn't as you already know, new in IETF, and a lot of proposals do >this - they extend and change how an existing protocol packet needs to >be parsed/formatted. Look at OSPFv2 and OSPFv3 - you parse the packet >based on the version field that you have at the beginning. Packet >formats are different, and but they still use the same protocol number - >89. we don't carry a version field in ESP or AH. We negotiate it via IKE. I think others have noted that intermediate systems need to know where to find the next protocol field, which >To cite another example, you could look at the latest cryptographic >authentication draft in IS-IS. It changes how the authentication data >needs to be parsed, but continues to use the same Authentication TLV 10. >It does not introduce a new TLV within IS-IS. That proposal is not my responsibility :-). >In this case you differentiate between the different formats based on >the SPI value, while, the underlying protocol still remains ESP! All >rules applicable to ESP apply here too. We could have gone down the new >proto-number path if there was *no* other alternative around. However, >we seem to have an easy way out without using up a new number. How else >do we otherwise intend to use the reserved values of SPI? Reserved SPI values are not defined as ways to changing how ESP/AH packets are parsed. They were defined for uses such as manual keying support. In IPsec, we allow the crypto algorithm choices to affect parsing, because of variability in length and location of IVs, and integrity info, for example. So, your proposal to use the SPI for this sort of demuxing is not consistent with what IPsec has chosen to do. >Last but not the least, the protocol number field is of one byte and we >have already taken up most of the numbers >(http://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt). >The only available range is from 140-252, which is quite narrow. I >believe we must be chary in requesting for new numbers, otherwise we'll >have a new extension tomorrow that expands this range from one octet to >two octets! ;-) We are all aware of this issue. Several proposals prior to your's also required a new protocol number. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 10:37: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 D95493A6B34; Tue, 2 Dec 2008 10:37:38 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DDC03A6B4A; Tue, 2 Dec 2008 10:37:37 -0800 (PST) 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 FuFEIxaLDPs3; Tue, 2 Dec 2008 10:37:24 -0800 (PST) Received: from smtp1gap.foundrynet.com (smtp1gap.foundrynet.com [76.199.70.29]) by core3.amsl.com (Postfix) with ESMTP id 1A9443A6B5E; Tue, 2 Dec 2008 10:36:05 -0800 (PST) Received: from xmail.ds.foundrynet.com (unknown [10.101.218.254]) by smtp1gap.foundrynet.com (Postfix) with ESMTP id 249B83E0007; Tue, 2 Dec 2008 10:35:41 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Dec 2008 10:36:47 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclUf8wH4UEf4A0RRRmPLxw4G+J2owAIxKTAAAJUhfA= References: <18736.7977.492687.346315@fireball.kivinen.iki.fi><18739.63975.625276.269689@fireball.kivinen.iki.fi> From: "Gary Hemminger" To: "Grewal, Ken" , "Scott C Moonen" , "Tero Kivinen" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, manav@alcatel-lucent.com, Jack Kohn Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1687895088==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1687895088== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C954AC.EEF2B4B7" This is a multi-part message in MIME format. ------_=_NextPart_001_01C954AC.EEF2B4B7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I chimed in on this earlier and want to provide feedback from a network (L2-3) and application delivery controller (load balancer) perspective. That perspective is that basically everyone in the industry uses merchant silicon (ie Broadcom/Marvell) to provide network functionality. Some kind of heuristic approach is going to be very difficult to convince them to provide vs. having a deterministic approach, in my opinion. =20 =20 That said, the previous emails seemed to indicate that the heuristic approach would not require any retooling. Can someone explain that magic to me? =20 Gary =20 From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Grewal, Ken Sent: Tuesday, December 02, 2008 10:03 AM To: Scott C Moonen; Tero Kivinen Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; manav@alcatel-lucent.com; Jack Kohn Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets =20 Scott,=20 Heuristics based solutions can be expensive to implement in HW as well as being inconclusive, providing assurances based on probabilities and hence prone to false positives.=20 Furthermore, some HW devices (especially Network Interface Cards, NICs) currently only examine packet headers and do not load the whole packet into memory. In aggregated environments, where these devices need to maintain line rate processing, subtle changes in design such as loading the whole packet into memory and parsing the packet trailer before making a decision if the packet should be sent to one CPU core or another for processing will have drastic impact on the packet processing engines of such devices (compared with a simple, deterministic approach such as in the current draft).=20 =20 As for the E2E encryption, I agree that there is some regulatory pressure to adopt this from a security perspective, but this is also competing with entrenched solutions offering valuable network services for traffic monitoring and hence require traffic visibility - this is one of the reasons that E2E encryption is not widely employed today within Enterprise environments, as it circumvents these network tools. The predominant use of IPsec today is in the remote access / VPN scenarios.=20 Some people have also mentioned that E2E encryption offers a secure channel for virus propagation, where the intermediate devices such as IDS/IPS are left blind to the network traffic flow.=20 =20 Having said that, there was some discussion during the last IETF meeting and the mailing list on adding the 'integrity bit' back into the WESP header. This was removed from the last draft and we could add this back in as it will provide a consistent view of an IPsec packet indicating if the packet is encrypted or in the clear, as well as allowing future innovation on intermediate devices being able to examine encrypted data based on administrative policy - food for thought. =20 =20 Thanks,=20 - Ken =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott C Moonen Sent: Tuesday, December 02, 2008 5:13 AM To: Tero Kivinen Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; manav@alcatel-lucent.com; Jack Kohn Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets =20 Tero, I wanted to chime in briefly in support of your suggested heuristic approach over against the proposed drafts to modify the ESP protocol with new formats and/or protocol numbers. I prefer recommending a heuristic approach for the following reasons:=20 1) Creating new protocols and different formats places an undue burden on end-node implementations when there is already a viable heuristic approach that would require no end-node retooling.=20 2) Considering that end-node adoption of these drafts is realistically going to be slow and incomplete, a heuristic approach will be necessary in any case for any intermediate-node implementation that wishes to remain competitive.=20 3) Finally, considering industry, regulatory and governmental moves to adopt end-to-end encryption, I suspect that in the long term the use of ESP-NULL may be insignificant compared to using encryption. This would limit the usefulness of these drafts (or indeed any form of deep-packet inspection), and also make it harder for end-node implementations to justify spending resources to implement and support a new protocol.=20 Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ =20 http://www.linkedin.com/in/smoonen From:=20 Tero Kivinen =20 To:=20 "Jack Kohn" =20 Cc:=20 ipsec@ietf.org, manav@alcatel-lucent.com=20 Date:=20 12/01/2008 09:52 AM=20 Subject:=20 Re: [IPsec] Deep Inspecting ESP-NULL Packets =20 ________________________________ Jack Kohn writes: > Heuristics is probability and is at best just an educated guess. Not really. For ESP-NULL there is always at least few bytes of self describing padding, which is very easy to check. After checking those the next ones to check is either the inner IP header (in case of tunnel mode) or TCP/UDP headers (in case of transport mode). All that checking nedes to only be done for the FIRST few packets, after the heuristics have identified the ICV length (currently 5 possible values in total, and currently only 1 of them is widely sued) and IV length (2 possible values and currently only 1 of them is widely used) then the information can be stored along the other flow specific information and no heuristics is needed after that. > I think the stakes are high as you would be dropping/forwarding > packets based on the probability that your model returns you. There is 1 out of 2^96 probability that random packet will pass your HMAC-SHA1-96 message check, so that is also probabilistic approach... If you check 8 bytes of self-describing padding and 4 bytes from the inner IP header (for tunnel mode) you get same probability...=20 > Also, do you propose to do this in HW or SW? Either way is doable. I think the actual initial heuristics that is run when unknown source IP, destination IP and SPI value is found, would most likely be run on the softpath, as it makes adding things in future easier, but the actual per packet processing would most likely be run on the hardware. Only changes there would require adding SPI as one of the keys used when looking up the state information and getting ICV_len and IV_len from the per flow state and use those to get the protocol number.=20 > Is there a model that you have in mind? I posted a example pseudocode for this earlier to this list.=20 http://www.ietf.org/mail-archive/web/ipsec/current/msg03385.html =20 > Do you have a study that you can share with us that gives some > numbers on how well this model works? My earlier email listed some numbers, so check those. There are also ways to make this even better without modifying the ESP packet format, but that would require changes to the ESP-NULL senders. I.e. the ESP-NULL senders could send at least 8 bytes of self-describing padding instead of the minimal amount, and with that change the probability of detecting ESP-NULL packet versuis ESP-encrypted packet with just one packet would go over 2^72 (8 bits of self-describing padding length, and 64 bits of padding). This is change we could do without breaking existing implementations, and it would usually be one or two line change to the code, i.e. something like: ---------------------------------------------------------------------- /* ... calculate normal pad_len here ... */ if (cipher =3D=3D ESP_NULL) { pad_len +=3D 8; } ---------------------------------------------------------------------- On the other hand if the implementation is already doing deep inspection of the packet (i.e. verifying urls and such inside the packets) then it will be checking more than enough bytes from the packet, that we do not need the extra bytes for the self-describing padding. The self-describing padding already gives you 99.998% - 99.999999999999999994% probability for detecting whether the first packet is ESP-NULL packet or ESP with encryption packet (depending how many bytes of padding there is (2-8 bytes)). And even then it would detect encrypted ESP packets as ESP-NULL because they happened to have correct bytes which looked like self-describing padding in the encrypted part. The packet would then be passed to the deep inspection part, which could not do deep inspection because the packet is encrypted. This would just cause some extra resources wasted when deep inspection engine tries to inspect those encrypted packets. The heuristics would never get it wrong in the other way, i.e detecting ESP-NULL packet as being encrypted, thus all ESP-NULL packets would be passed to the deep inspection part. --=20 kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 ------_=_NextPart_001_01C954AC.EEF2B4B7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I chimed in on this earlier and want to provide feedback = from a network (L2-3) and application delivery controller (load balancer) perspective.  That perspective is that basically everyone in the = industry uses merchant silicon (ie Broadcom/Marvell) to provide network = functionality.  Some kind of heuristic approach is going to be very difficult to convince = them to provide vs. having a deterministic approach, in my opinion.  =  

 

That said, the previous emails seemed to indicate that = the heuristic approach would not require any retooling.  Can someone = explain that magic to me?

 

Gary

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Grewal, Ken
Sent: Tuesday, December 02, 2008 10:03 AM
To: Scott C Moonen; Tero Kivinen
Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; = manav@alcatel-lucent.com; Jack Kohn
Subject: Re: [IPsec] Deep Inspecting ESP-NULL = Packets

 

Scott,

Heuristics based solutions can be expensive to implement in = HW as well as being inconclusive, providing assurances based on probabilities = and hence prone to false positives.

Furthermore, some HW devices (especially Network Interface = Cards, NICs) currently only examine packet headers and do not load the whole = packet into memory. In aggregated environments, where these devices need to = maintain line rate processing, subtle changes in design such as loading the whole = packet into memory and parsing the packet trailer before making a decision if = the packet should be sent to one CPU core or another for processing will = have drastic impact on the packet processing engines of such devices (compared with a simple, deterministic approach such as in the current draft). =

 

As for the E2E encryption, I agree that there is some = regulatory pressure to adopt this from a security perspective, but this is also = competing with entrenched solutions offering valuable network services for traffic monitoring and hence require traffic visibility – this is one of = the reasons that E2E encryption is not widely employed today within Enterprise = environments, as it circumvents these network tools. The predominant use of IPsec = today is in the remote access / VPN scenarios.

Some people have also mentioned that E2E encryption offers a = secure channel for virus propagation, where the intermediate devices such as = IDS/IPS are left blind to the network traffic flow.

 

Having said that, there was some discussion during the last = IETF meeting and the mailing list on adding the ‘integrity bit’ = back into the WESP header. This was removed from the last draft and we could add this back = in as it will provide a consistent view of an IPsec packet indicating if the = packet is encrypted or in the clear, as well as allowing future innovation on intermediate devices being able to examine encrypted data based on administrative policy – food for thought. =  

 

Thanks, =

- = Ken

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Scott C Moonen
Sent: Tuesday, December 02, 2008 5:13 AM
To: Tero Kivinen
Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; = manav@alcatel-lucent.com; Jack Kohn
Subject: Re: [IPsec] Deep Inspecting ESP-NULL = Packets

 


Tero, = I wanted to chime in briefly in support of your suggested heuristic approach over against the proposed drafts to modify the ESP protocol with new formats = and/or protocol numbers.  I prefer recommending a heuristic approach for = the following reasons:

1) = Creating new protocols and different formats places an undue burden on end-node implementations when there is already a viable heuristic approach that = would require no end-node retooling.
2) = Considering that end-node adoption of these drafts is realistically going to be slow = and incomplete, a heuristic approach will be necessary in any case for any intermediate-node implementation that wishes to remain = competitive.
3) = Finally, considering industry, regulatory and governmental moves to adopt = end-to-end encryption, I suspect that in the long term the use of ESP-NULL may be insignificant compared to using encryption.  This would limit the usefulness of these drafts (or indeed any form of deep-packet = inspection), and also make it harder for end-node implementations to justify spending = resources to implement and support a new protocol.


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

From:

Tero Kivinen <kivinen@iki.fi>

To:

"Jack Kohn" <kohn.jack@gmail.com>

Cc:

ipsec@ietf.org= , manav@alcatel-lucent.com

Date:

12/01/2008 09:52 AM

Subject:

Re: [IPsec] Deep Inspecting ESP-NULL Packets

 




Jack Kohn writes:
> Heuristics is probability and is at best just an educated = guess.

Not really. For ESP-NULL there is always at least few bytes of = self
describing padding, which is very easy to check. After checking = those
the next ones to check is either the inner IP header (in case = of
tunnel mode) or TCP/UDP headers (in case of transport mode). All = that
checking nedes to only be done for the FIRST few packets, after = the
heuristics have identified the ICV length (currently 5 possible = values
in total, and currently only 1 of them is widely sued) and IV = length
(2 possible values and currently only 1 of them is widely used) = then
the information can be stored along the other flow specific
information and no heuristics is needed after that.

> I think the stakes are high as you would be = dropping/forwarding
> packets based on the probability that your model returns = you.

There is 1 out of 2^96 probability that random packet will pass = your
HMAC-SHA1-96 message check, so that is also probabilistic = approach...
If you check 8 bytes of self-describing padding and 4 bytes from = the
inner IP header (for tunnel mode) you get same probability... =

> Also, do you propose to do this in HW or SW?

Either way is doable. I think the actual initial heuristics that = is
run when unknown source IP, destination IP and SPI value is = found,
would most likely be run on the softpath, as it makes adding things = in
future easier, but the actual per packet processing would most = likely
be run on the hardware. Only changes there would require adding SPI = as
one of the keys used when looking up the state information and = getting
ICV_len and IV_len from the per flow state and use those to get = the
protocol number.

> Is there a model that you have in mind?

I posted a example pseudocode for this earlier to this list. =
http://www.ietf.org/mail-archive/web/ipsec/cur= rent/msg03385.html

> Do you have a study that you can share with us that gives = some
> numbers on how well this model works?

My earlier email listed some numbers, so check those.

There are also ways to make this even better without modifying the = ESP
packet format, but that would require changes to the ESP-NULL = senders.
I.e. the ESP-NULL senders could send at least 8 bytes of
self-describing padding instead of the minimal amount, and with = that
change the probability of detecting ESP-NULL packet versuis
ESP-encrypted packet with just one packet would go over 2^72 (8 = bits
of self-describing padding length, and 64 bits of padding).

This is change we could do without breaking existing = implementations,
and it would usually be one or two line change to the code, = i.e.
something like:
---------------------------------------------------------------------= -
 /* ... calculate normal pad_len here ... */
 if (cipher =3D=3D ESP_NULL) {
    pad_len +=3D 8;
 }
---------------------------------------------------------------------= -

On the other hand if the implementation is already doing = deep
inspection of the packet (i.e. verifying urls and such inside = the
packets) then it will be checking more than enough bytes from = the
packet, that we do not need the extra bytes for the = self-describing
padding. The self-describing padding already gives you 99.998% = -
99.999999999999999994% probability for detecting whether the = first
packet is ESP-NULL packet or ESP with encryption packet = (depending
how many bytes of padding there is (2-8 bytes)).

And even then it would detect encrypted ESP packets as = ESP-NULL
because they happened to have correct bytes which looked = like
self-describing padding in the encrypted part. The packet would = then
be passed to the deep inspection part, which could not do = deep
inspection because the packet is encrypted. This would just cause = some
extra resources wasted when deep inspection engine tries to = inspect
those encrypted packets.

The heuristics would never get it wrong in the other way, = i.e
detecting ESP-NULL packet as being encrypted, thus all = ESP-NULL
packets would be passed to the deep inspection part.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

------_=_NextPart_001_01C954AC.EEF2B4B7-- --===============1687895088== 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 --===============1687895088==-- From ipsec-bounces@ietf.org Tue Dec 2 10:44: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 6193F3A6B57; Tue, 2 Dec 2008 10:44:46 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C84383A6B54 for ; Tue, 2 Dec 2008 10:44:44 -0800 (PST) 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 4pVkiUlr1kFV for ; Tue, 2 Dec 2008 10:44:43 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id A7DFD3A6B51 for ; Tue, 2 Dec 2008 10:44:43 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 02 Dec 2008 10:38:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.33,702,1220252400"; d="scan'208";a="367274695" Received: from unknown (HELO azsmsx001.amr.corp.intel.com) ([10.2.167.98]) by orsmga002.jf.intel.com with ESMTP; 02 Dec 2008 10:43:34 -0800 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by azsmsx001.amr.corp.intel.com (10.2.167.98) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 2 Dec 2008 11:44:38 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Tue, 2 Dec 2008 11:44:34 -0700 From: "Grewal, Ken" To: Jack Kohn , Yaron Sheffer Date: Tue, 2 Dec 2008 11:44:17 -0700 Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclUnvUG52yqq65ASLSvh6D35RJVTAADE80w Message-ID: References: <6D26D1FE43A66F439F8109CDD424196502356BC4@INEXC1U01.in.lucent.com> <6D26D1FE43A66F439F8109CDD424196502356E81@INEXC1U01.in.lucent.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FD1F@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" , Stephen Kent Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Jack, I think we are splitting hairs here! In either case, the packet format changes. If there are legacy devices parsing ESP packets, then these will need to change for the reserved SPI based solution, as well as the new protocol based solution. If a legacy intermediate device is assuming a fixed ESP format (it has not changed in the last 10 years) and looking inside a packet based on a generic policy that all traffic is ESP-Null, than it does not even need to parse the SPI and may be dumb in so far as skipping x number of bytes for the ESP header and parsing the payload - in such a case, changing the packet format, while preserving the protocol number will certainly break such implementations. Not sure if such implementations or deployments exist? The new protocol approach appears to be a cleaner solution and will not have any compatibility issues. I look forward to other opinions... Thanks, - Ken >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Jack Kohn >Sent: Tuesday, December 02, 2008 8:57 AM >To: Yaron Sheffer >Cc: ipsec@ietf.org; Bhatia, Manav (Manav); Stephen Kent >Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > >> In fact, I cannot imagine any good use for the reserved SPI values. But I >> don't think that when you use a "magic" SPI value, you are allowed to >change >> the header format drastically. And shifting everything by 2 or 4 bytes is > >I read the draft again (can the author please post it, as its >extremely inconvenient reading it from a mail attachment .. ) and >verified that the header remains the same; its the payload thats >modified. > >> certainly drastic (e.g. to protocol analyzers, deep inspection engines, >load >> balancers). > >To each his own, because to me a new protocol number is as >inconveniencing, if not more, than changing the packet semantics. > >Are you suggesting that there are protocol analyzers, deep inspection >engines, load balancers peeking inside ESP packets? What i am unable >to fathom is that if they can be updated to understand the new >protocol number, then why cant they be updated to parse the new SPI >type? > >Jack > >> >> Thanks, >> Yaron >> >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >> Jack Kohn >> Sent: Tuesday, December 02, 2008 17:40 >> To: Bhatia, Manav (Manav) >> Cc: ipsec@ietf.org; Stephen Kent >> Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets >> >>> (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.txt). >>> The only available range is from 140-252, which is quite narrow. I >>> believe we must be chary in requesting for new numbers, otherwise we'll >>> have a new extension tomorrow that expands this range from one octet to >>> two octets! ;-) >> >> :D >> >> Oh dont worry, its going to take some while before we exhaust all >> these numbers; then there are some left that can be reused .. >> >>> In this case you differentiate between the different formats based on >>> the SPI value, while, the underlying protocol still remains ESP! All >>> rules applicable to ESP apply here too. We could have gone >>> down the new >>> proto-number path if there was *no* other alternative around. However, >>> we seem to have an easy way out without using up a new >> >> I agree with the above sentiment - i dont think using a reserved SPI >> value makes the underlying protocol any different from the base ESP. >> >>> number. How else >>> do we otherwise intend to use the reserved values of SPI? >> >> The chairs and ADs could perhaps guide us here? >> >> Jack >> >>> Cheers, Manav >>> >>>> -----Original Message----- >>>> From: Stephen Kent [mailto:kent@bbn.com] >>>> Sent: Monday, December 01, 2008 8.49 PM >>>> To: Bhatia, Manav (Manav) >>>> Cc: Jack Kohn; ipsec@ietf.org >>>> Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets >>>> >>>> Manav, >>>> >>>> If you have two SPIs (original and the new, reserved one) then the >>>> format is no longer ESP and thus cannot reuse the ESP protocol number. >>>> >>>> the same argument applies to the proposal that the original SPI be >>>> stuffed into the payload. >>>> >>>> Steve >>>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. >> >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 11:00: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 325573A6B3A; Tue, 2 Dec 2008 11:00:51 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345D13A6B3A for ; Tue, 2 Dec 2008 11:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0JK2aXY46gu for ; Tue, 2 Dec 2008 11:00:49 -0800 (PST) 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 6C7AE3A692B for ; Tue, 2 Dec 2008 11:00:49 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mB2J0jBr021011 for ; Tue, 2 Dec 2008 19:00:45 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 mB2J0ier009426 for ; Tue, 2 Dec 2008 14:00:44 -0500 (EST) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB2IrEI3007715 for ; Tue, 2 Dec 2008 13:53:14 -0500 (EST) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB2IrEfW007714 for ipsec@ietf.org; Tue, 2 Dec 2008 13:53:14 -0500 (EST) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Tue, 2 Dec 2008 13:53:14 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20081202185314.GH6533@sun.com> References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > That said, the previous emails seemed to indicate that the heuristic > approach would not require any retooling. Can someone explain that > magic to me? The problem with any deep-inspection-friendly ESP comes down to two complaints from two mostly-disjoint sets of developers: End-node/OS types: ------------------ I'm not putting in a THIRD IPsec protocol (or SECOND if I blew off AH) if I can help it. I put in IPv6 a while ago and not many of my customers/users are using it. And do you know how hard it is to get customers to *upgrade*?!? They all want the new features in the same *&^%&%$# revision number so they won't have to pay high-priced con-art^H^H^H^Hsultants to "recertify" their setup. I thought this whole 430x movement was about *SIMPLIFYING* things! Middlebox/Router/Firewall types: -------------------------------- You expect me to go begging to my {silicon vendor, in-house polygon pushers} and put in all sorts of can't-make-it-run-fast inspection that needs to guess? It's all just software at the end-nodes - let them figure it out! I thought this whole 430x movement was about *SIMPLIFYING* things! My apologies for not injecting enough humor into the 2nd point of view. If anyone's scheme can overcome both of those complaints, we all win. Anything else is going to be painful for someone. I am a fan of Kivenen's middlebox heuristic scheme, mostly because I fall into the first category of complainers. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 11:12:12 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FD773A6B24; Tue, 2 Dec 2008 11:12:12 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8CAD3A6823 for ; Tue, 2 Dec 2008 11:12:11 -0800 (PST) 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 QIAqVwsbk1qK for ; Tue, 2 Dec 2008 11:12:10 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 58E7E3A6B3A for ; Tue, 2 Dec 2008 11:11:13 -0800 (PST) Received: by qyk4 with SMTP id 4so3625341qyk.13 for ; Tue, 02 Dec 2008 11:11:08 -0800 (PST) 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=/y505k4+h5lCcbhDbvjtG5r4P5tSG+eQAww2kYnYsWI=; b=bZviz3hi/nZSngRfU1ULGUUL05vGI3T7ASIDMeTuJXw14Q3duNFmQzrpjojgy64zSq KpuR5vOt3qtaGiwi6nF9vn6U2jhfMmaHR3yiMiIY3mBuLSr+SQiQHvyDAX++3W7P73X2 u+mBYFmHFiG7fJTDIzyeCb3GTFnHT6Jufb7V4= 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=mwNlue/H9EJ4thN3RsesXTHeyYk1Axz+gKRxfpD6Q/vS2li+6qFOhUTXOnqe74JzRs 06oz5XZEno4GoRzyDuepsJ91+J49L9zFMU90ZEImy4/N7yTfCNbrkJFyUHBKO2EsURr4 XUM+jVrC2g7kCh3xhWHVD6ATMJ466bB7Yb450= Received: by 10.215.15.7 with SMTP id s7mr12035045qai.347.1228245068688; Tue, 02 Dec 2008 11:11:08 -0800 (PST) Received: by 10.214.181.8 with HTTP; Tue, 2 Dec 2008 11:11:08 -0800 (PST) Message-ID: Date: Tue, 2 Dec 2008 11:11:08 -0800 From: "fan zhao" To: "Vijay Devarapalli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Vijay, Thanks for following up on this issue. Please see my reply below. On Mon, Dec 1, 2008 at 11:06 AM, Vijay Devarapalli wrote: > Hi Fan, > > I am following up on the one open issue on allowing a re-direct during > IKE_AUTH stage. > > Yaron mentioned during the meeting in Minneapolis that this is not > really necessary. I think the advantage of doing this during the IKE_AUTH is to avoid overheasd because if the IPsec client is redirected during the informational exchange, more signaling messages are sent and the states regarding the SA are created unnecessarily. Even worse, the client may request to set up the child SA during the IKE_AUTH. Note that redirection during the informational exchange is still useful in other cases; however, if the IPsec gateway knows it needs to redirect the IPsec client to another gateway, it does not have to wait until the IKE_AUTH is completed. > It just adds complexity to the state machine on both > the client and the gateway. The following cases are possible if the redirection is done during IKE_AUTH: 1) The IPsec client does not request to set up the child SA during IKE_AUTH client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH} The IPsec gateway verifies such message (may use EAP also), if the authentication fails, the IPsec gateway indicates the error without providing the REDIRECT payload to the client per rfc 4306. If the authentication succeeds, the IPsec gateway returns the following message with the REDIRECT payload. gateway -> client: HDR, SK {IDr, [CERT,] AUTH, [REDIRECT]} The client authenticates this message. If fail, the client ignores this message and may try with the same or different IPsec gateway again. If authentication succeeds, the client performs redirection based on the REDIRECT payload. 2) The IPsec client requests to set up the child SA during IKE_AUTH client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH SAi2, TSi, TSr} The IPsec gateway verifies such message (may use EAP also), if the authentication fails, the IPsec gateway indicates the error without providing the REDIRECT payload to the client per rfc 4306. If the authentication succeeds, the IPsec gateway returns the following message with the REDIRECT payload. gateway -> client: HDR, SK {IDr, [CERT,] AUTH, [REDIRECT]} The client authenticates this message. If fail, the client ignores this message and may try with the same or different IPsec gateway again. If authentication succeeds, the client performs redirection based on the REDIRECT payload. I do not see too much complexitiy. It is worth documenting redirection during the IKE_AUTH given the benefits. In fact, it only needs a few sentences. What do you think? Sincerely, fan > I agree with him. I think the current > mechanisms, re-direct during the IKE_SA_INIT exchange and > gateway-initiated re-direct, are sufficient. > > Vijay > > On Wed, Nov 5, 2008 at 2:33 PM, fan zhao wrote: >> Hi Vijay, >> >> Thanks for your reply. Please see below. >> >> On Wed, Nov 5, 2008 at 2:23 PM, Vijay Devarapalli wrote: >>> Hi Fan, >>> >>> On Tue, Nov 4, 2008 at 3:09 PM, fan zhao wrote: >>>> Hi, Vijay and Killian, >>>> >>>> I have some comments on draft-ietf-ipsecme-ikev2-redirect-01. >>>> >>>> 1) The draft describes the redirection during the IKE_SA_INIT exchange >>>> and during the informational exchange that is after the SA is established. >>>> Please correct me if I am wrong. I think the redirection can be done during >>>> the IKE_AUTH exchange, right? We have discussed this before. >>> >>> Yes, but this change has not been made yet. I had presented this issue >>> at the last IETF, but there were no comments. I was looking for a >>> little bit more discussion on this before adding this to the document. >> OK. >> >>> >>>> 2) Near the end of section 3: >>>> >>>> "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." >>>> Based on RFC 4877, the lifetime of a dynamically assigned HoA is >>>> the same as that of the SA. So if the SA expires, the HoA expires >>>> and the BCE is invalid too, right? >>> >>> The home address and the binding cache entry are not marked invalid >>> right away. If the SAs expire, the mobile node can run IKEv2 with the >>> home agent again and request for the same home address. >> OK. This can be done. >> >>> >>>> "In this case, the >>>> mobile node MUST NOT use the original home agent 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." >>>> >>>> If I understand correctly, in this case, the MN will use the anycast address >>>> in the IKE_SA_INIT, and then is redirected to the original home agent. >>>> Is this correct? >>> >>> No, we wanted to say that the mobile node should try running IKEv2 >>> again with the existing home agent. Not use the anycast address as the >>> destination address for the IKE_SA_INIT exchange. >> >> I agree with what you said. Somehow, I read the text differently. >> >> Thanks. >> >> Sincerely, >> fan >> >>> >>>> 3) Some editorial issues: >>>> >>>> Abstract: 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. >>>> >>>> Maybe it is better: >>>> "The proposed mechanism can also be used in Mobile IPv6 ..." >>>> >>>> >>>> 3. IKEv2 Exchange with Redirect >>>> To redirect a IKEv2 session to >>>> >>>> s/a/an >>> >>> Thanks for catching these. >>> >>> Vijay >>> >>>> >>>> Thanks. >>>> >>>> Sincerely, >>>> fan >>>> >>>> >>>> On Mon, Nov 3, 2008 at 4:22 PM, Vijay Devarapalli wrote: >>>>> Hi, >>>>> >>>>> We just submitted a new draft version for the IKEv2 re-direct >>>>> mechanism. Changes made in this version >>>>> >>>>> - Added a section on gateway-initiated re-direct. The earlier versions >>>>> only spoke about re-direct during the IKE_SA_INIT exchange >>>>> - Updated the reference to IKEv2bis draft >>>>> - A few other minor fixes. >>>>> >>>>> Vijay >>>>> >>>>> >>>>> 2008/11/3 : >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>> This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. >>>>>> >>>>>> >>>>>> Title : Re-direct Mechanism for IKEv2 >>>>>> Author(s) : V. Devarapalli, K. Weniger >>>>>> Filename : draft-ietf-ipsecme-ikev2-redirect-01.txt >>>>>> Pages : 12 >>>>>> Date : 2008-11-03 >>>>>> >>>>>> 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-ietf-ipsecme-ikev2-redirect-01.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. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Dec 2 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 5F6DD3A68E8; Tue, 2 Dec 2008 12:03:09 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8903A68E8 for ; Tue, 2 Dec 2008 12:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1GGQHhpbiWD for ; Tue, 2 Dec 2008 12:03:07 -0800 (PST) Received: from smtp1gap.foundrynet.com (smtp1gap.foundrynet.com [76.199.70.29]) by core3.amsl.com (Postfix) with ESMTP id DE6303A6778 for ; Tue, 2 Dec 2008 12:03:07 -0800 (PST) Received: from xmail.ds.foundrynet.com (unknown [10.101.218.254]) by smtp1gap.foundrynet.com (Postfix) with ESMTP id E97EA3E0002; Tue, 2 Dec 2008 12:02:50 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 2 Dec 2008 12:03:32 -0800 Message-ID: In-Reply-To: <20081202185314.GH6533@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclUsJ+qk1zjncJ0TMqZ6CBRWhjEHQACESWw References: <18736.7977.492687.346315@fireball.kivinen.iki.fi><18739.63975.625276.269689@fireball.kivinen.iki.fi> <20081202185314.GH6533@sun.com> From: "Gary Hemminger" To: "Dan McDonald" , Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I think you pretty much nailed it. Very accurate depiction of the issues on both sides. Gary -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Dan McDonald Sent: Tuesday, December 02, 2008 10:53 AM To: ipsec@ietf.org Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > That said, the previous emails seemed to indicate that the heuristic > approach would not require any retooling. Can someone explain that > magic to me? The problem with any deep-inspection-friendly ESP comes down to two complaints from two mostly-disjoint sets of developers: End-node/OS types: ------------------ I'm not putting in a THIRD IPsec protocol (or SECOND if I blew off AH) if I can help it. I put in IPv6 a while ago and not many of my customers/users are using it. And do you know how hard it is to get customers to *upgrade*?!? They all want the new features in the same *&^%&%$# revision number so they won't have to pay high-priced con-art^H^H^H^Hsultants to "recertify" their setup. I thought this whole 430x movement was about *SIMPLIFYING* things! Middlebox/Router/Firewall types: -------------------------------- You expect me to go begging to my {silicon vendor, in-house polygon pushers} and put in all sorts of can't-make-it-run-fast inspection that needs to guess? It's all just software at the end-nodes - let them figure it out! I thought this whole 430x movement was about *SIMPLIFYING* things! My apologies for not injecting enough humor into the 2nd point of view. If anyone's scheme can overcome both of those complaints, we all win. Anything else is going to be painful for someone. I am a fan of Kivenen's middlebox heuristic scheme, mostly because I fall into the first category of complainers. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 13:05: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 22D0628C1DA; Tue, 2 Dec 2008 13:05:57 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84C4628C1DA; Tue, 2 Dec 2008 13:05:55 -0800 (PST) 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 5oZY+Q-5k+W1; Tue, 2 Dec 2008 13:05:54 -0800 (PST) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id D2D113A68E8; Tue, 2 Dec 2008 13:05:53 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e38.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB2L4jU1014140; Tue, 2 Dec 2008 14:04:45 -0700 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB2L5g8U124022; Tue, 2 Dec 2008 14:05:44 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB2L5fo8027539; Tue, 2 Dec 2008 14:05:42 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB2L5fA0027534; Tue, 2 Dec 2008 14:05:41 -0700 In-Reply-To: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi><18739.63975.625276.269689@fireball.kivinen.iki.fi> <20081202185314.GH6533@sun.com> To: "Gary Hemminger" MIME-Version: 1.0 X-KeepSent: 96633F7C:88366AEC-85257513:0071145F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 12/02/2008 04:05:28 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 12/02/2008 04:05:28 PM, Serialize complete at 12/02/2008 04:05:28 PM, S/MIME Sign failed at 12/02/2008 04:05:29 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_10262008HFIGS1|October 26, 2008) at 12/02/2008 14:05:41, Serialize complete at 12/02/2008 14:05:41 Message-ID: Date: Tue, 2 Dec 2008 16:05:41 -0500 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Dan McDonald Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2046189015==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============2046189015== Content-Type: multipart/alternative; boundary="=_alternative 0073DBB885257513_=" This is a multipart message in MIME format. --=_alternative 0073DBB885257513_= Content-Type: text/plain; charset="US-ASCII" Thanks to Dan for his excellent analysis. :) I'm certainly willing to look for solutions that try to bridge the concerns of both camps. In 2007, on August 27th Dan and I almost simultaneously proposed something simpler on-list. We suggested reserving by convention portions of the SPI space to signal the use of ESP NULL and even possibly distinct IV lengths: http://www.ietf.org/mail-archive/web/ipsec/current/msg02417.html http://www.ietf.org/mail-archive/web/ipsec/current/msg02418.html I'm not able to find any replies to our notes, although perhaps I'm missing them. For this approach, the burden on end-node implementations would be substantially reduced compared to the WG draft, as the TCP/IP stack no longer needs any involvement with new protocols; the only thing that needs to be changed is the SPI selection algorithm. Furthermore, this will not break existing intermediate-node implementations or even require any configuration changes to permit new protocols. It will even allow for unidirectional packet inspection if only one endpoint supports the proposal. Finally, I don't think it would be any more burdensome on intermediate-node implementations than the current WG draft. It is true that existing end-node implementations will create both false positives and false negatives by not honoring this convention. But any architected solution will be hampered by incomplete adoption -- and in this case a simpler solution may actually be adopted more quickly by end nodes. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: "Gary Hemminger" To: "Dan McDonald" , Date: 12/02/2008 03:05 PM Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets I think you pretty much nailed it. Very accurate depiction of the issues on both sides. Gary -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Dan McDonald Sent: Tuesday, December 02, 2008 10:53 AM To: ipsec@ietf.org Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > That said, the previous emails seemed to indicate that the heuristic > approach would not require any retooling. Can someone explain that > magic to me? The problem with any deep-inspection-friendly ESP comes down to two complaints from two mostly-disjoint sets of developers: End-node/OS types: ------------------ I'm not putting in a THIRD IPsec protocol (or SECOND if I blew off AH) if I can help it. I put in IPv6 a while ago and not many of my customers/users are using it. And do you know how hard it is to get customers to *upgrade*?!? They all want the new features in the same *&^%&%$# revision number so they won't have to pay high-priced con-art^H^H^H^Hsultants to "recertify" their setup. I thought this whole 430x movement was about *SIMPLIFYING* things! Middlebox/Router/Firewall types: -------------------------------- You expect me to go begging to my {silicon vendor, in-house polygon pushers} and put in all sorts of can't-make-it-run-fast inspection that needs to guess? It's all just software at the end-nodes - let them figure it out! I thought this whole 430x movement was about *SIMPLIFYING* things! My apologies for not injecting enough humor into the 2nd point of view. If anyone's scheme can overcome both of those complaints, we all win. Anything else is going to be painful for someone. I am a fan of Kivenen's middlebox heuristic scheme, mostly because I fall into the first category of complainers. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0073DBB885257513_= Content-Type: text/html; charset="US-ASCII"
Thanks to Dan for his excellent analysis. :)  I'm certainly willing to look for solutions that try to bridge the concerns of both camps.

In 2007, on August 27th Dan and I almost simultaneously proposed something simpler on-list.  We suggested reserving by convention portions of the SPI space to signal the use of ESP NULL and even possibly distinct IV lengths:

        http://www.ietf.org/mail-archive/web/ipsec/current/msg02417.html
        http://www.ietf.org/mail-archive/web/ipsec/current/msg02418.html

I'm not able to find any replies to our notes, although perhaps I'm missing them.

For this approach, the burden on end-node implementations would be substantially reduced compared to the WG draft, as the TCP/IP stack no longer needs any involvement with new protocols; the only thing that needs to be changed is the SPI selection algorithm.  Furthermore, this will not break existing intermediate-node implementations or even require any configuration changes to permit new protocols.  It will even allow for unidirectional packet inspection if only one endpoint supports the proposal.  Finally, I don't think it would be any more burdensome on intermediate-node implementations than the current WG draft.

It is true that existing end-node implementations will create both false positives and false negatives by not honoring this convention.  But any architected solution will be hampered by incomplete adoption -- and in this case a simpler solution may actually be adopted more quickly by end nodes.


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


From: "Gary Hemminger" <ghemminger@foundrynet.com>
To: "Dan McDonald" <danmcd@sun.com>, <ipsec@ietf.org>
Date: 12/02/2008 03:05 PM
Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets




I think you pretty much nailed it.  Very accurate depiction of the
issues on both sides.

Gary

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
Of Dan McDonald
Sent: Tuesday, December 02, 2008 10:53 AM
To: ipsec@ietf.org
Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets

<mucho snippage deleted!>
> That said, the previous emails seemed to indicate that the heuristic
> approach would not require any retooling.  Can someone explain that
> magic to me?

The problem with any deep-inspection-friendly ESP comes down to two
complaints from two mostly-disjoint sets of developers:

End-node/OS types:
------------------

I'm not putting in a THIRD IPsec protocol (or SECOND if I blew off AH)
if I
can help it.  I put in IPv6 a while ago and not many of my
customers/users
are using it.  And do you know how hard it is to get customers to
*upgrade*?!?  They all want the new features in the same *&^%&%$#
revision
number so they won't have to pay high-priced con-art^H^H^H^Hsultants to
"recertify" their setup.  I thought this whole 430x movement was about
*SIMPLIFYING* things!



Middlebox/Router/Firewall types:
--------------------------------

You expect me to go begging to my {silicon vendor, in-house polygon
pushers}
and put in all sorts of can't-make-it-run-fast inspection that needs to
guess?  It's all just software at the end-nodes - let them figure it
out!  I
thought this whole 430x movement was about *SIMPLIFYING* things!



My apologies for not injecting enough humor into the 2nd point of view.


If anyone's scheme can overcome both of those complaints, we all win.
Anything else is going to be painful for someone.  I am a fan of
Kivenen's
middlebox heuristic scheme, mostly because I fall into the first
category of
complainers.


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

--=_alternative 0073DBB885257513_=-- --===============2046189015== 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 --===============2046189015==-- From ipsec-bounces@ietf.org Tue Dec 2 13:28: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 53D4F28C0EB; Tue, 2 Dec 2008 13:28:51 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81C0B3A69AB for ; Tue, 2 Dec 2008 13:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Les-yavhoVvr for ; Tue, 2 Dec 2008 13:28:48 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id ACCCD28C125 for ; Tue, 2 Dec 2008 13:28:48 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mB2LSTBJ003252 for ; Tue, 2 Dec 2008 21:28:42 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mB2LSSkC020701 for ; Tue, 2 Dec 2008 16:28:28 -0500 (EST) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB2LKw8Y008044 for ; Tue, 2 Dec 2008 16:20:58 -0500 (EST) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB2LKwjc008043 for ipsec@ietf.org; Tue, 2 Dec 2008 16:20:58 -0500 (EST) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Tue, 2 Dec 2008 16:20:58 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20081202212058.GA7728@sun.com> References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> <20081202185314.GH6533@sun.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Tue, Dec 02, 2008 at 04:05:41PM -0500, Scott C Moonen wrote: > In 2007, on August 27th Dan and I almost simultaneously proposed something > simpler on-list. We suggested reserving by convention portions of the SPI > space to signal the use of ESP NULL and even possibly distinct IV lengths: > > http://www.ietf.org/mail-archive/web/ipsec/current/msg02417.html > http://www.ietf.org/mail-archive/web/ipsec/current/msg02418.html > > I'm not able to find any replies to our notes, although perhaps I'm > missing them. Yeah... the thread-view on the mail archive website is kinda *off* around this thread. > For this approach, the burden on end-node implementations would be > substantially reduced compared to the WG draft, as the TCP/IP stack no > longer needs any involvement with new protocols; the only thing that needs > to be changed is the SPI selection algorithm. Even stronger than "no TCP/IP stack changes", a decent user/kernel split will require no kernel-level changes as well. And for embedded/single-level implementations, you can probably isolate the changes if the system is well-architected. > configuration changes to permit new protocols. It will even allow for > unidirectional packet inspection if only one endpoint supports the > proposal. Finally, I don't think it would be any more burdensome on > intermediate-node implementations than the current WG draft. And trapping 0xfffe0000/15 for deep-inspection-happiness should be easy to put in your silicon, if not a firmware update for middle-box vendors. > It is true that existing end-node implementations will create both false > positives and false negatives by not honoring this convention. My proposal causes that to happen 1/32768 of assigned SAs. > But any architected solution will be hampered by incomplete adoption -- and > in this case a simpler solution may actually be adopted more quickly by end > nodes. The only real drawback I can see is if an SPD entry and subsequent proposal (IKEv1 or IKEv2) has a mix of with-and-without-encryption for possible actions (kinda silly, but it is possible). The SPI selection in those cases cannot be guaranteed to be deep-inspectable, and therefore the reserved SPI range cannot be used. Besides, end-nodes might not WANT their packets deep-inspected, and those that do can configure their SPD accordingly -- setting ESP encryption to NULL explicitly. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 13:52: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 C811F3A6852; Tue, 2 Dec 2008 13:52:02 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97EE53A6852 for ; Tue, 2 Dec 2008 13:52:01 -0800 (PST) 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=[AWL=0.001, 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 wG64R3QcyFsK for ; Tue, 2 Dec 2008 13:52:00 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id BFE893A6767 for ; Tue, 2 Dec 2008 13:52:00 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 02 Dec 2008 13:45:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.33,704,1220252400"; d="scan'208";a="646328915" Received: from azsmsx602.amr.corp.intel.com ([10.2.121.201]) by fmsmga001.fm.intel.com with ESMTP; 02 Dec 2008 13:52:34 -0800 Received: from rrsmsx002.amr.corp.intel.com (10.31.0.34) by azsmsx602.amr.corp.intel.com (10.2.121.201) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 2 Dec 2008 14:47:29 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx002.amr.corp.intel.com ([10.31.0.34]) with mapi; Tue, 2 Dec 2008 14:47:20 -0700 From: "Grewal, Ken" To: Dan McDonald , "ipsec@ietf.org" Date: Tue, 2 Dec 2008 14:47:06 -0700 Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclUxPppIkxaWni6TEK1rjkXYpE63QAAQXQw Message-ID: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> <20081202185314.GH6533@sun.com> <20081202212058.GA7728@sun.com> In-Reply-To: <20081202212058.GA7728@sun.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] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org One observation with this proposal (call it the SPI semantics proposal) is legacy incompatibility. All endpoint implementations would need to ensure they follow these rules and change their implementations accordingly. If there are any implementations within a network that do not follow these rules, we are back to invalid inferences. Another observation along similar lines is any HW devices that are encoding additional lookup information directly into the Rx SPI (which is under the control of the recipient) to allow optimized Rx SA lookup (e.g. masking some SPI bits to extract a direct SA index into the SADB) will now need to be changed also. I actually did one of these in my previous life. This will impact HW and SW. Thanks, - Ken >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Dan McDonald >Sent: Tuesday, December 02, 2008 1:21 PM >To: ipsec@ietf.org >Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > >On Tue, Dec 02, 2008 at 04:05:41PM -0500, Scott C Moonen wrote: >> In 2007, on August 27th Dan and I almost simultaneously proposed >something >> simpler on-list. We suggested reserving by convention portions of the >SPI >> space to signal the use of ESP NULL and even possibly distinct IV >lengths: >> >> http://www.ietf.org/mail-archive/web/ipsec/current/msg02417.html >> http://www.ietf.org/mail-archive/web/ipsec/current/msg02418.html >> >> I'm not able to find any replies to our notes, although perhaps I'm >> missing them. > >Yeah... the thread-view on the mail archive website is kinda *off* around >this thread. > >> For this approach, the burden on end-node implementations would be >> substantially reduced compared to the WG draft, as the TCP/IP stack no >> longer needs any involvement with new protocols; the only thing that >needs >> to be changed is the SPI selection algorithm. > >Even stronger than "no TCP/IP stack changes", a decent user/kernel split >will >require no kernel-level changes as well. And for embedded/single-level >implementations, you can probably isolate the changes if the system is >well-architected. > >> configuration changes to permit new protocols. It will even allow for >> unidirectional packet inspection if only one endpoint supports the >> proposal. Finally, I don't think it would be any more burdensome on >> intermediate-node implementations than the current WG draft. > >And trapping 0xfffe0000/15 for deep-inspection-happiness should be easy to >put in your silicon, if not a firmware update for middle-box vendors. > >> It is true that existing end-node implementations will create both false >> positives and false negatives by not honoring this convention. > >My proposal causes that to happen 1/32768 of assigned SAs. > >> But any architected solution will be hampered by incomplete adoption -- >and >> in this case a simpler solution may actually be adopted more quickly by >end >> nodes. > >The only real drawback I can see is if an SPD entry and subsequent proposal >(IKEv1 or IKEv2) has a mix of with-and-without-encryption for possible >actions (kinda silly, but it is possible). The SPI selection in those >cases >cannot be guaranteed to be deep-inspectable, and therefore the reserved SPI >range cannot be used. > >Besides, end-nodes might not WANT their packets deep-inspected, and those >that do can configure their SPD accordingly -- setting ESP encryption to >NULL >explicitly. > >Dan >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 13:56: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 CB8813A6852; Tue, 2 Dec 2008 13:56:03 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382C33A67D4 for ; Tue, 2 Dec 2008 13:56:03 -0800 (PST) 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 i0cZMJ37fkGu for ; Tue, 2 Dec 2008 13:56:02 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by core3.amsl.com (Postfix) with ESMTP id 5BA813A6767 for ; Tue, 2 Dec 2008 13:56:02 -0800 (PST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 02 Dec 2008 13:55:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.33,704,1220252400"; d="scan'208";a="85663654" Received: from unknown (HELO azsmsx601.amr.corp.intel.com) ([10.2.121.193]) by azsmga001.ch.intel.com with ESMTP; 02 Dec 2008 13:55:56 -0800 Received: from rrsmsx602.amr.corp.intel.com (10.31.0.33) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 2 Dec 2008 14:55:55 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Tue, 2 Dec 2008 14:55:53 -0700 From: "Grewal, Ken" To: Dan McDonald , "ipsec@ietf.org" Date: Tue, 2 Dec 2008 14:55:39 -0700 Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclUsFVk2+cvq468QSqQbwO01YZzXwAF1qkA Message-ID: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> <20081202185314.GH6533@sun.com> In-Reply-To: <20081202185314.GH6533@sun.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] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org LOL - Nice analysis :-) If we want a common solution amenable to all parties, without letting the 'other guy' worry about it, we need a common language, hence the new protocol. BTW, some of your text appears encrypted (*&^%&%$#) - any pointers on how to parse this? ;-) Thanks, - Ken >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Dan McDonald >Sent: Tuesday, December 02, 2008 10:53 AM >To: ipsec@ietf.org >Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > > >> That said, the previous emails seemed to indicate that the heuristic >> approach would not require any retooling. Can someone explain that >> magic to me? > >The problem with any deep-inspection-friendly ESP comes down to two >complaints from two mostly-disjoint sets of developers: > >End-node/OS types: >------------------ > >I'm not putting in a THIRD IPsec protocol (or SECOND if I blew off AH) if I >can help it. I put in IPv6 a while ago and not many of my customers/users >are using it. And do you know how hard it is to get customers to >*upgrade*?!? They all want the new features in the same *&^%&%$# revision >number so they won't have to pay high-priced con-art^H^H^H^Hsultants to >"recertify" their setup. I thought this whole 430x movement was about >*SIMPLIFYING* things! > > > >Middlebox/Router/Firewall types: >-------------------------------- > >You expect me to go begging to my {silicon vendor, in-house polygon >pushers} >and put in all sorts of can't-make-it-run-fast inspection that needs to >guess? It's all just software at the end-nodes - let them figure it out! >I >thought this whole 430x movement was about *SIMPLIFYING* things! > > > >My apologies for not injecting enough humor into the 2nd point of view. > > >If anyone's scheme can overcome both of those complaints, we all win. >Anything else is going to be painful for someone. I am a fan of Kivenen's >middlebox heuristic scheme, mostly because I fall into the first category >of >complainers. > > >Dan >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 14:33: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 6C5F128C1FF; Tue, 2 Dec 2008 14:33:25 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B97328C1FF for ; Tue, 2 Dec 2008 14:33:24 -0800 (PST) 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 vMbInPDLUXtv for ; Tue, 2 Dec 2008 14:33:22 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id F3D333A69AD for ; Tue, 2 Dec 2008 14:33:21 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4658E29C002; Wed, 3 Dec 2008 00:33:17 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 593C629C001; Wed, 3 Dec 2008 00:32:48 +0200 (IST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB2MWlfE024580; Wed, 3 Dec 2008 00:32:47 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 3 Dec 2008 00:32:47 +0200 From: Yaron Sheffer To: fan zhao , Vijay Devarapalli Date: Wed, 3 Dec 2008 00:32:59 +0200 Thread-Topic: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) Thread-Index: AclUsei4rcGv6TL3TOCKnjXln7hRHQAGxYjw Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FD44@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0940366602==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0940366602== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0330_01C954DE.B1A67980" ------=_NextPart_000_0330_01C954DE.B1A67980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Fan, To clarify: in the case of EAP, you are looking for redirect *only* in the last message of the IKE_AUTH exchange, right? And the motivation is to redirect (to choose the destination gateway) based on the client's authenticated identity? I think that with EAP, if you want to redirect because of overload conditions, then having the AAA server work hard and only then redirecting the client (and repeating this effort somewhere else) doesn't make much engineering sense. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of fan zhao Sent: Tuesday, December 02, 2008 21:11 To: Vijay Devarapalli Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) Hi Vijay, Thanks for following up on this issue. Please see my reply below. On Mon, Dec 1, 2008 at 11:06 AM, Vijay Devarapalli wrote: > Hi Fan, > > I am following up on the one open issue on allowing a re-direct during > IKE_AUTH stage. > > Yaron mentioned during the meeting in Minneapolis that this is not > really necessary. I think the advantage of doing this during the IKE_AUTH is to avoid overheasd because if the IPsec client is redirected during the informational exchange, more signaling messages are sent and the states regarding the SA are created unnecessarily. Even worse, the client may request to set up the child SA during the IKE_AUTH. Note that redirection during the informational exchange is still useful in other cases; however, if the IPsec gateway knows it needs to redirect the IPsec client to another gateway, it does not have to wait until the IKE_AUTH is completed. > It just adds complexity to the state machine on both > the client and the gateway. The following cases are possible if the redirection is done during IKE_AUTH: 1) The IPsec client does not request to set up the child SA during IKE_AUTH client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH} The IPsec gateway verifies such message (may use EAP also), if the authentication fails, the IPsec gateway indicates the error without providing the REDIRECT payload to the client per rfc 4306. If the authentication succeeds, the IPsec gateway returns the following message with the REDIRECT payload. gateway -> client: HDR, SK {IDr, [CERT,] AUTH, [REDIRECT]} The client authenticates this message. If fail, the client ignores this message and may try with the same or different IPsec gateway again. If authentication succeeds, the client performs redirection based on the REDIRECT payload. 2) The IPsec client requests to set up the child SA during IKE_AUTH client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH SAi2, TSi, TSr} The IPsec gateway verifies such message (may use EAP also), if the authentication fails, the IPsec gateway indicates the error without providing the REDIRECT payload to the client per rfc 4306. If the authentication succeeds, the IPsec gateway returns the following message with the REDIRECT payload. gateway -> client: HDR, SK {IDr, [CERT,] AUTH, [REDIRECT]} The client authenticates this message. If fail, the client ignores this message and may try with the same or different IPsec gateway again. If authentication succeeds, the client performs redirection based on the REDIRECT payload. I do not see too much complexitiy. It is worth documenting redirection during the IKE_AUTH given the benefits. In fact, it only needs a few sentences. What do you think? Sincerely, fan > I agree with him. I think the current > mechanisms, re-direct during the IKE_SA_INIT exchange and > gateway-initiated re-direct, are sufficient. > > Vijay > > On Wed, Nov 5, 2008 at 2:33 PM, fan zhao wrote: >> Hi Vijay, >> >> Thanks for your reply. Please see below. >> >> On Wed, Nov 5, 2008 at 2:23 PM, Vijay Devarapalli wrote: >>> Hi Fan, >>> >>> On Tue, Nov 4, 2008 at 3:09 PM, fan zhao wrote: >>>> Hi, Vijay and Killian, >>>> >>>> I have some comments on draft-ietf-ipsecme-ikev2-redirect-01. >>>> >>>> 1) The draft describes the redirection during the IKE_SA_INIT exchange >>>> and during the informational exchange that is after the SA is established. >>>> Please correct me if I am wrong. I think the redirection can be done during >>>> the IKE_AUTH exchange, right? We have discussed this before. >>> >>> Yes, but this change has not been made yet. I had presented this issue >>> at the last IETF, but there were no comments. I was looking for a >>> little bit more discussion on this before adding this to the document. >> OK. >> >>> >>>> 2) Near the end of section 3: >>>> >>>> "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." >>>> Based on RFC 4877, the lifetime of a dynamically assigned HoA is >>>> the same as that of the SA. So if the SA expires, the HoA expires >>>> and the BCE is invalid too, right? >>> >>> The home address and the binding cache entry are not marked invalid >>> right away. If the SAs expire, the mobile node can run IKEv2 with the >>> home agent again and request for the same home address. >> OK. This can be done. >> >>> >>>> "In this case, the >>>> mobile node MUST NOT use the original home agent 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." >>>> >>>> If I understand correctly, in this case, the MN will use the anycast address >>>> in the IKE_SA_INIT, and then is redirected to the original home agent. >>>> Is this correct? >>> >>> No, we wanted to say that the mobile node should try running IKEv2 >>> again with the existing home agent. Not use the anycast address as the >>> destination address for the IKE_SA_INIT exchange. >> >> I agree with what you said. Somehow, I read the text differently. >> >> Thanks. >> >> Sincerely, >> fan >> >>> >>>> 3) Some editorial issues: >>>> >>>> Abstract: 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. >>>> >>>> Maybe it is better: >>>> "The proposed mechanism can also be used in Mobile IPv6 ..." >>>> >>>> >>>> 3. IKEv2 Exchange with Redirect >>>> To redirect a IKEv2 session to >>>> >>>> s/a/an >>> >>> Thanks for catching these. >>> >>> Vijay >>> >>>> >>>> Thanks. >>>> >>>> Sincerely, >>>> fan >>>> >>>> >>>> On Mon, Nov 3, 2008 at 4:22 PM, Vijay Devarapalli wrote: >>>>> Hi, >>>>> >>>>> We just submitted a new draft version for the IKEv2 re-direct >>>>> mechanism. Changes made in this version >>>>> >>>>> - Added a section on gateway-initiated re-direct. The earlier versions >>>>> only spoke about re-direct during the IKE_SA_INIT exchange >>>>> - Updated the reference to IKEv2bis draft >>>>> - A few other minor fixes. >>>>> >>>>> Vijay >>>>> >>>>> >>>>> 2008/11/3 : >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>>>> This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. >>>>>> >>>>>> >>>>>> Title : Re-direct Mechanism for IKEv2 >>>>>> Author(s) : V. Devarapalli, K. Weniger >>>>>> Filename : draft-ietf-ipsecme-ikev2-redirect-01.txt >>>>>> Pages : 12 >>>>>> Date : 2008-11-03 >>>>>> >>>>>> 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-ietf-ipsecme-ikev2-redirect-01.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. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0330_01C954DE.B1A67980 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwMjIyMzI1OVowIwYJKoZIhvcNAQkEMRYEFJYCoSROpNks cqC1Hsjn6M0slQ6pMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Uvnd7c4s6/ZJIW64KMybSw73EwiQ8PSWZRuL3O/c2ibVLAoWanF935vJPW0+RZdRIkecwV27Sioj Em555pwOY7tpBunpCgCdSbDTzJyC+74mVDT0g7r96y4w1PG2tcJuaNqPvnEFbFsJgRKT5U0tUgwc jH9rWpIrYAxfdp8wBZO4YBmPaG5JHEWBpYnt7TVVmgagbLJkTs1xyoEq4rIl1BnFeOqQbcOhQhz4 z7kfAekJb0mLUbX1qkwGZKU8l5Q2GRoGVZyNUxhSHbJmHECls4Rr54ov79n0F75QdJiD2Hza5GW/ I5QYmL+h2JfxeMgLcm5YdWM5HGvdht4edHCiCQAAAAAAAA== ------=_NextPart_000_0330_01C954DE.B1A67980-- --===============0940366602== 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 --===============0940366602==-- From ipsec-bounces@ietf.org Tue Dec 2 15:26: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 16F703A67DB; Tue, 2 Dec 2008 15:26:49 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC50428C104 for ; Tue, 2 Dec 2008 15:26:47 -0800 (PST) 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 K7PiJNvqVKyt for ; Tue, 2 Dec 2008 15:26:47 -0800 (PST) Received: from web81905.mail.mud.yahoo.com (web81905.mail.mud.yahoo.com [68.142.207.184]) by core3.amsl.com (Postfix) with SMTP id 0A2893A67AC for ; Tue, 2 Dec 2008 15:26:46 -0800 (PST) Received: (qmail 89311 invoked by uid 60001); 2 Dec 2008 23:26:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=JXZ5hp6qXusz2MB/Zxm4XDmLQk095SKc1GlEe1EZJsCpkio3VOO31tXFJiJuVRoKXfTP8TDqEOEkkCqJIv5NpciqU4asy/q2Gzu92fgy7J1MCIZjAQ+iK7T95CtfFQ5qr8+/pG9KZSGz4avT53Psg0dRuNhbiXe8nUljsg1gYyU=; X-YMail-OSG: qSr_4MAVM1lL7BLU_mgXxsDXaEcoLKvQmI_j5jwNCGcjX03oPIVI4yvViZ1YaOlFiIREZ1wgnZ5fyz_K9CD39e9KWnnRFiULIU.JnkCjWxQ5GRrafqqk02r17iT6_rBWoVzJvArB9OT_oAD5TN8kDjZi.A4mRsAeu0_BkxOjzKD1 Received: from [131.107.0.75] by web81905.mail.mud.yahoo.com via HTTP; Tue, 02 Dec 2008 15:26:43 PST X-Mailer: YahooMailRC/1155.20 YahooMailWebService/0.7.218.2 Date: Tue, 2 Dec 2008 15:26:43 -0800 (PST) From: g_e_montenegro@yahoo.com To: "Grewal, Ken" , Dan McDonald , "ipsec@ietf.org" MIME-Version: 1.0 Message-ID: <163020.85292.qm@web81905.mail.mud.yahoo.com> Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org An additional dimension to this analysis is related to scenarios. Splitting the world between nodes and middleboxes may not capture the whole thing. For example, a middlebox in, say, a branch office scenario may have much less of a scalability problem than the middlebox sitting in front of a datacenter on a 10Gbps link. The answer from the middlebox dude probably differs depending on which scenario they are contemplating. ----- Original Message ---- > From: "Grewal, Ken" > To: Dan McDonald ; "ipsec@ietf.org" > Sent: Tuesday, December 2, 2008 1:55:39 PM > Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > > LOL - Nice analysis :-) > > If we want a common solution amenable to all parties, without letting the 'other > guy' worry about it, we need a common language, hence the new protocol. > > BTW, some of your text appears encrypted (*&^%&%$#) - any pointers on how to > parse this? ;-) > > Thanks, > - Ken > > > >-----Original Message----- > >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > >Dan McDonald > >Sent: Tuesday, December 02, 2008 10:53 AM > >To: ipsec@ietf.org > >Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > > > > > >> That said, the previous emails seemed to indicate that the heuristic > >> approach would not require any retooling. Can someone explain that > >> magic to me? > > > >The problem with any deep-inspection-friendly ESP comes down to two > >complaints from two mostly-disjoint sets of developers: > > > >End-node/OS types: > >------------------ > > > >I'm not putting in a THIRD IPsec protocol (or SECOND if I blew off AH) if I > >can help it. I put in IPv6 a while ago and not many of my customers/users > >are using it. And do you know how hard it is to get customers to > >*upgrade*?!? They all want the new features in the same *&^%&%$# revision > >number so they won't have to pay high-priced con-art^H^H^H^Hsultants to > >"recertify" their setup. I thought this whole 430x movement was about > >*SIMPLIFYING* things! > > > > > > > >Middlebox/Router/Firewall types: > >-------------------------------- > > > >You expect me to go begging to my {silicon vendor, in-house polygon > >pushers} > >and put in all sorts of can't-make-it-run-fast inspection that needs to > >guess? It's all just software at the end-nodes - let them figure it out! > >I > >thought this whole 430x movement was about *SIMPLIFYING* things! > > > > > > > >My apologies for not injecting enough humor into the 2nd point of view. > > > > > >If anyone's scheme can overcome both of those complaints, we all win. > >Anything else is going to be painful for someone. I am a fan of Kivenen's > >middlebox heuristic scheme, mostly because I fall into the first category > >of > >complainers. > > > > > >Dan > >_______________________________________________ > >IPsec mailing list > >IPsec@ietf.org > >https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 2 15:30: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 128E728C22F; Tue, 2 Dec 2008 15:30:34 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 587F928C22F for ; Tue, 2 Dec 2008 15:30:32 -0800 (PST) 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 l4UgStPhDpMd for ; Tue, 2 Dec 2008 15:30:31 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id B19F828C22A for ; Tue, 2 Dec 2008 15:30:30 -0800 (PST) Received: by qyk4 with SMTP id 4so3754720qyk.13 for ; Tue, 02 Dec 2008 15:30:23 -0800 (PST) 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=nWvnglgqd1r7+mU8HzqAqaZxmD9W0ra8IMurX6lYqXs=; b=N3x01cKwoBlUUwwpvDLHfxfLbehifl2siP/jFyRX3cXqp3Gg7lZ9+mG2n0mMMwDkrT pLSUUYwDWmkteCrLS/xI80SvHT1MPlPf+gj8Q5uufPompZvaNj0bh2y7n7Uu/6M+q/R3 lHbeEnMYEMeB45SRW3pWO3+dvdbknUAneu6oQ= 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=tdWIBjR0LlbRAt8QHqBJ30He6p7yNe34oruXU4b5i9YoNj3XhIkszHL9ixH9ejH1xI vTOQB4GDP3lf7NlvpbXZOmDsgUsdpl/BzbsVe4D0mIA1iPfajb7i3FOzR7gVeBJ481Qf cPAG2Vqsz6LBJmWZrpFreax0t4Urqmv62G0e4= Received: by 10.214.26.1 with SMTP id 1mr12472448qaz.334.1228260622969; Tue, 02 Dec 2008 15:30:22 -0800 (PST) Received: by 10.214.181.8 with HTTP; Tue, 2 Dec 2008 15:30:22 -0800 (PST) Message-ID: Date: Tue, 2 Dec 2008 15:30:22 -0800 From: "fan zhao" To: "Yaron Sheffer" In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FD44@il-ex01.ad.checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB94FD44@il-ex01.ad.checkpoint.com> Cc: "ipsec@ietf.org" , Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Yaron, Thanks for your reply. Please see below. On Tue, Dec 2, 2008 at 2:32 PM, Yaron Sheffer wrote: > Hi Fan, > > To clarify: in the case of EAP, you are looking for redirect *only* in the > last message of the IKE_AUTH exchange, right? Yes. > And the motivation is to > redirect (to choose the destination gateway) based on the client's > authenticated identity? Yes. > > I think that with EAP, if you want to redirect because of overload > conditions, then having the AAA server work hard and only then redirecting > the client (and repeating this effort somewhere else) doesn't make much > engineering sense. In this case, redirection is not because of load condition. It is because the network (such as AAA server or other backend server) has user profile and the profile stores the IPsec gateway that the client needs to connect to; however the client selects a different gateway initially. Sincerely, fan > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > fan zhao > Sent: Tuesday, December 02, 2008 21:11 > To: Vijay Devarapalli > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 > Re-direct draft) > > Hi Vijay, > > Thanks for following up on this issue. Please see my reply below. > > On Mon, Dec 1, 2008 at 11:06 AM, Vijay Devarapalli wrote: >> Hi Fan, >> >> I am following up on the one open issue on allowing a re-direct during >> IKE_AUTH stage. >> >> Yaron mentioned during the meeting in Minneapolis that this is not >> really necessary. > I think the advantage of doing this during the IKE_AUTH is to avoid > overheasd because if the IPsec client is redirected during the informational > exchange, more signaling messages are sent and the states regarding > the SA are created unnecessarily. Even worse, the client may request > to set up the child SA during the IKE_AUTH. Note that redirection during > the informational exchange is still useful in other cases; however, if the > IPsec gateway knows it needs to redirect the IPsec client to another > gateway, it does not have to wait until the IKE_AUTH is completed. > >> It just adds complexity to the state machine on both >> the client and the gateway. > The following cases are possible if the redirection is done during IKE_AUTH: > 1) The IPsec client does not request to set up the child SA during IKE_AUTH > client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH} > The IPsec gateway verifies such message (may use EAP also), if > the authentication fails, the IPsec gateway indicates the error without > providing the REDIRECT payload to the client per rfc 4306. > If the authentication succeeds, the IPsec gateway returns the following > message with the REDIRECT payload. > gateway -> client: HDR, SK {IDr, [CERT,] AUTH, [REDIRECT]} > The client authenticates this message. If fail, the client ignores this > message and may try with the same or different IPsec gateway again. > If authentication succeeds, the client performs redirection based on the > REDIRECT payload. > > 2) The IPsec client requests to set up the child SA during IKE_AUTH > client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH SAi2, TSi, > TSr} > The IPsec gateway verifies such message (may use EAP also), if > the authentication fails, the IPsec gateway indicates the error without > providing the REDIRECT payload to the client per rfc 4306. > If the authentication succeeds, the IPsec gateway returns the following > message with the REDIRECT payload. > gateway -> client: HDR, SK {IDr, [CERT,] AUTH, [REDIRECT]} > The client authenticates this message. If fail, the client ignores this > message and may try with the same or different IPsec gateway again. > If authentication succeeds, the client performs redirection based on the > REDIRECT payload. > > I do not see too much complexitiy. It is worth documenting redirection > during the IKE_AUTH given the benefits. In fact, it only needs a few > sentences. > What do you think? > > Sincerely, > fan > > >> I agree with him. I think the current >> mechanisms, re-direct during the IKE_SA_INIT exchange and >> gateway-initiated re-direct, are sufficient. >> >> Vijay >> >> On Wed, Nov 5, 2008 at 2:33 PM, fan zhao wrote: >>> Hi Vijay, >>> >>> Thanks for your reply. Please see below. >>> >>> On Wed, Nov 5, 2008 at 2:23 PM, Vijay Devarapalli > wrote: >>>> Hi Fan, >>>> >>>> On Tue, Nov 4, 2008 at 3:09 PM, fan zhao wrote: >>>>> Hi, Vijay and Killian, >>>>> >>>>> I have some comments on draft-ietf-ipsecme-ikev2-redirect-01. >>>>> >>>>> 1) The draft describes the redirection during the IKE_SA_INIT exchange >>>>> and during the informational exchange that is after the SA is > established. >>>>> Please correct me if I am wrong. I think the redirection can be done > during >>>>> the IKE_AUTH exchange, right? We have discussed this before. >>>> >>>> Yes, but this change has not been made yet. I had presented this issue >>>> at the last IETF, but there were no comments. I was looking for a >>>> little bit more discussion on this before adding this to the document. >>> OK. >>> >>>> >>>>> 2) Near the end of section 3: >>>>> >>>>> "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." >>>>> Based on RFC 4877, the lifetime of a dynamically assigned HoA is >>>>> the same as that of the SA. So if the SA expires, the HoA expires >>>>> and the BCE is invalid too, right? >>>> >>>> The home address and the binding cache entry are not marked invalid >>>> right away. If the SAs expire, the mobile node can run IKEv2 with the >>>> home agent again and request for the same home address. >>> OK. This can be done. >>> >>>> >>>>> "In this case, the >>>>> mobile node MUST NOT use the original home agent 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." >>>>> >>>>> If I understand correctly, in this case, the MN will use the anycast > address >>>>> in the IKE_SA_INIT, and then is redirected to the original home agent. >>>>> Is this correct? >>>> >>>> No, we wanted to say that the mobile node should try running IKEv2 >>>> again with the existing home agent. Not use the anycast address as the >>>> destination address for the IKE_SA_INIT exchange. >>> >>> I agree with what you said. Somehow, I read the text differently. >>> >>> Thanks. >>> >>> Sincerely, >>> fan >>> >>>> >>>>> 3) Some editorial issues: >>>>> >>>>> Abstract: 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. >>>>> >>>>> Maybe it is better: >>>>> "The proposed mechanism can also be used in Mobile IPv6 ..." >>>>> >>>>> >>>>> 3. IKEv2 Exchange with Redirect >>>>> To redirect a IKEv2 session to >>>>> >>>>> s/a/an >>>> >>>> Thanks for catching these. >>>> >>>> Vijay >>>> >>>>> >>>>> Thanks. >>>>> >>>>> Sincerely, >>>>> fan >>>>> >>>>> >>>>> On Mon, Nov 3, 2008 at 4:22 PM, Vijay Devarapalli > wrote: >>>>>> Hi, >>>>>> >>>>>> We just submitted a new draft version for the IKEv2 re-direct >>>>>> mechanism. Changes made in this version >>>>>> >>>>>> - Added a section on gateway-initiated re-direct. The earlier versions >>>>>> only spoke about re-direct during the IKE_SA_INIT exchange >>>>>> - Updated the reference to IKEv2bis draft >>>>>> - A few other minor fixes. >>>>>> >>>>>> Vijay >>>>>> >>>>>> >>>>>> 2008/11/3 : >>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts > directories. >>>>>>> This draft is a work item of the IP Security Maintenance and > Extensions Working Group of the IETF. >>>>>>> >>>>>>> >>>>>>> Title : Re-direct Mechanism for IKEv2 >>>>>>> Author(s) : V. Devarapalli, K. Weniger >>>>>>> Filename : draft-ietf-ipsecme-ikev2-redirect-01.txt >>>>>>> Pages : 12 >>>>>>> Date : 2008-11-03 >>>>>>> >>>>>>> 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-ietf-ipsecme-ikev2-redirect-01.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. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 > > 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 Wed Dec 3 04:51: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 2629A3A6894; Wed, 3 Dec 2008 04:51:49 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6EF23A6894 for ; Wed, 3 Dec 2008 04:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 RutJxdynMcs5 for ; Wed, 3 Dec 2008 04:51:47 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 65E3F3A6861 for ; Wed, 3 Dec 2008 04:51:47 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB3Cpb9K004720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2008 14:51:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB3CpYvi016540; Wed, 3 Dec 2008 14:51:34 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18742.32982.788647.641072@fireball.kivinen.iki.fi> Date: Wed, 3 Dec 2008 14:51:34 +0200 From: Tero Kivinen To: "fan zhao" In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 19 min X-Total-Time: 18 min Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org fan zhao writes: > 2) The IPsec client requests to set up the child SA during IKE_AUTH > client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH SAi2, TSi, TSr} If we want to allow redirection during the IKE_AUTH, I think this second option is the one we want to select. This would be identical to normal exchange, thus it will cause smaller changes, and it has good property that if server does NOT do redirect we get the IPsec SA done after this. In any cause we MUST NOT define two different ways how to do this, as that would just add unnessary complexity. So if we are going to select one, lets select this one. On the other hand the difference between doing the IKE_AUTH to end and doing INFORMATINAL exchange after that to do redirect is even simplier, as we still want to support that option too, and the most time consuming part of the IKE_AUTH (Diffie-Hellman, Signing etc) is already done anyways, so doing it as separate INFOMRATIONL exchange, simply wastes 2 extra small packets but no extra round trips. Note, that server can reject the IPsec SA creation by returning suitable error message (for example NO_ADDITIONAL_SAS) in the IKE_AUTH, and then the full exchange would be: Initiator Responder ------------------------------------------------------------------- HDR, SAi1, KEi, Ni, N(REDIRECT_SUPPORTED) --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, N(NO_ADDITIONAL_SAS)} <-- HDR, SK {N(REDIRECT)} HDR, SK {N(REDIRECT_ACK)} --> HDR, SAi1, KEi, Ni, N(REDIRECT_FROM) --> I.e. the server would reply N(NO_ADDITIONAL_SAS) and immediately after that send N(REDIRECT) notify as separate INFORMATINAL exchange. The initiator would first get the IKE_AUTH reply, process that, and immediately after that get INFORMATINAL exhange asking to N(REDIRECT). The initiator can start connection to the new IKE SA immediately when it receives the N(REDIRECT) thus it does not waste any single round trip, only wasted resource would be 2 small packets (less than 100 bytes each). I think this is simplier and cleaner way to get the same effect with no extra real cost. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 3 05:00: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 DD2113A69E6; Wed, 3 Dec 2008 05:00:33 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E46613A69E0 for ; Wed, 3 Dec 2008 05:00:32 -0800 (PST) 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 aQZBfEROUvya for ; Wed, 3 Dec 2008 05:00:32 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9646A3A69E6 for ; Wed, 3 Dec 2008 05:00:31 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB3D0PBY000274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2008 15:00:25 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB3D0OF2017531; Wed, 3 Dec 2008 15:00:24 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18742.33512.884628.356909@fireball.kivinen.iki.fi> Date: Wed, 3 Dec 2008 15:00:24 +0200 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> <20081202185314.GH6533@sun.com> <20081202212058.GA7728@sun.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" , Dan McDonald Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Grewal, Ken writes: > One observation with this proposal (call it the SPI semantics > proposal) is legacy incompatibility. > > All endpoint implementations would need to ensure they follow these > rules and change their implementations accordingly. If there are any > implementations within a network that do not follow these rules, we > are back to invalid inferences. I.e it as exactly same problems as what modifying ESP in general has... > Another observation along similar lines is any HW devices that are > encoding additional lookup information directly into the Rx SPI > (which is under the control of the recipient) to allow optimized Rx > SA lookup (e.g. masking some SPI bits to extract a direct SA index > into the SADB) will now need to be changed also. I actually did one > of these in my previous life. I would guess those changes would also be quite small. On the other hand another problem with that proposal is that there is no ICV length information there. I assume that when those were proposed we had only ICV length of 12 to consider, but now we also have ICV lengths of 12, 16, 20, 24, and 32 to consider... Of course that information could also be encoded to the SPI if this proposal would go forward, but this still has the problem you listed first, meaning it requires changes to the all end nodes thus it will be very slow to deploy (faster than WESP though, as the changes to implementations would be smaller). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 3 05:16: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 C8C673A683B; Wed, 3 Dec 2008 05:16:56 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE03D3A68C0 for ; Wed, 3 Dec 2008 05:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 N2nv1WF14Ejg for ; Wed, 3 Dec 2008 05:16:55 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A57C43A67B3 for ; Wed, 3 Dec 2008 05:16:54 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB3DGTp0022065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2008 15:16:29 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB3DGSK9012664; Wed, 3 Dec 2008 15:16:28 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18742.34476.957638.373556@fireball.kivinen.iki.fi> Date: Wed, 3 Dec 2008 15:16:28 +0200 From: Tero Kivinen To: "Gary Hemminger" In-Reply-To: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 13 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Gary Hemminger writes: > I chimed in on this earlier and want to provide feedback from a network > (L2-3) and application delivery controller (load balancer) perspective. > That perspective is that basically everyone in the industry uses > merchant silicon (ie Broadcom/Marvell) to provide network functionality. > Some kind of heuristic approach is going to be very difficult to > convince them to provide vs. having a deterministic approach, in my > opinion. It will be about same to get the IPsec chip vendors to provide support for WESP. In either case silicon vendors need to implement new functionality and it will be slow before the actual chips are out. On the other side the good thing is that most of those complicated deep inspection engines (and actually security processors too) are very programmable already thus they might not require actual silicon changes, but just some tweaking on the firmware. > That said, the previous emails seemed to indicate that the heuristic > approach would not require any retooling. Can someone explain that > magic to me? If you use heuristic approach then the ESP and all end nodes would remain intact, i.e. no changes is required to them. Also no changes will be done on the normal firewalls or routers (i.e. the ones not doing deep inspection). Only devices which do require changes will be the deep inspection middleboxes, and there the changes required for the fastpath are going to be quite small (add SPI to the flow lookup, load ICV_len and IV_len from the state information so they can know the offsets where the protocol number is located and where the actual payload starts). All the more complicated heuristics would most likely be done on the slowpath anyways, and even there it would be too complicated (much simplier than checking TCP headers). Also all deep inspection engines need to load the full packet to the deep inspection engine anyways (usually they also need to reassemble IP fragments to get full packet, and even reorder out of order TCP segments and remove overlapping TCP segments before doing inspection), so I do not really belive there is any deep inspection engines where getting the protocol number from the end of the packet would really be problem. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 3 05:27:14 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15B823A69E0; Wed, 3 Dec 2008 05:27:14 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A09D3A69E0 for ; Wed, 3 Dec 2008 05:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 PL5YBJbogv+W for ; Wed, 3 Dec 2008 05:27:12 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 22CC33A698C for ; Wed, 3 Dec 2008 05:27:11 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB3DR5bw008611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Dec 2008 15:27:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB3DR5vc011956; Wed, 3 Dec 2008 15:27:05 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18742.35113.355935.776274@fireball.kivinen.iki.fi> Date: Wed, 3 Dec 2008 15:27:05 +0200 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 9 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Grewal, Ken writes: > Heuristics based solutions can be expensive to implement in HW as > well as being inconclusive, providing assurances based on > probabilities and hence prone to false positives. Note, that false positivies could only happen for very few first packets, after the SPI is known to be either encrypted ESP or ESP-NULL, then there will not be any false positives or negatives. On the other hand implementing deep inspection on hardware on the TCP or HTTP request is several orders of magnitude more complicated than to check the SPI and see if that is known and do processing based on the SPI. > Furthermore, some HW devices (especially Network Interface Cards, > NICs) currently only examine packet headers and do not load the > whole packet into memory. In aggregated environments, where these > devices need to maintain line rate processing, subtle changes in > design such as loading the whole packet into memory and parsing the > packet trailer before making a decision if the packet should be sent > to one CPU core or another for processing will have drastic impact > on the packet processing engines of such devices (compared with a > simple, deterministic approach such as in the current draft). In normal case NIC does not need to find the protocol number to decide what to do with the packet, the SPI will be enough. If SPI is unknown, then packet is dropped to CPU so CPU can run heuristics. If SPI is known and is known to be ESP encrypted, then packet is passed directly forward as no deep inspection can be done. If SPI is known and is known to be ESP-NULL and SPI is marked as one that requires deep inspection (if there is cases where ESP-NULL packets can also be marked as bypassing deep inspection) then packet is thrown to the deep inspection engine, which will require the full packet anyways, so getting the protocol number from the end of the packet will not cause any problems. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kbesrl@ambrosi.com Wed Dec 3 06:48:04 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92B683A69E6 for ; Wed, 3 Dec 2008 06:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -41.974 X-Spam-Level: X-Spam-Status: No, score=-41.974 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fSmxt9yLWSJ for ; Wed, 3 Dec 2008 06:48:04 -0800 (PST) Received: from host8925129145.3s.pl (host8925129145.3s.pl [89.25.129.145]) by core3.amsl.com (Postfix) with SMTP id 151FD3A68D1 for ; Wed, 3 Dec 2008 06:48:02 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081203144803.151FD3A68D1@core3.amsl.com> Date: Wed, 3 Dec 2008 06:48:02 -0800 (PST) Click here to view as a webpage From ipsec-bounces@ietf.org Wed Dec 3 08:31: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 DD93F3A6B26; Wed, 3 Dec 2008 08:31:13 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC333A6B26 for ; Wed, 3 Dec 2008 08:31:12 -0800 (PST) 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=[AWL=0.000, 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 dSBUWxYoygyx for ; Wed, 3 Dec 2008 08:31:11 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 73D103A67ED for ; Wed, 3 Dec 2008 08:31:11 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 03 Dec 2008 08:24:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.33,708,1220252400"; d="scan'208";a="646612292" Received: from unknown (HELO azsmsx001.amr.corp.intel.com) ([10.2.167.98]) by fmsmga001.fm.intel.com with ESMTP; 03 Dec 2008 08:31:21 -0800 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by azsmsx001.amr.corp.intel.com (10.2.167.98) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 3 Dec 2008 09:30:44 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Wed, 3 Dec 2008 09:30:34 -0700 From: "Grewal, Ken" To: Tero Kivinen Date: Wed, 3 Dec 2008 09:30:25 -0700 Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclVRyNF8ydJBQ3pRCyGBC01oTBWaAAG/5Ww Message-ID: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> <20081202185314.GH6533@sun.com> <20081202212058.GA7728@sun.com> <18742.33512.884628.356909@fireball.kivinen.iki.fi> In-Reply-To: <18742.33512.884628.356909@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Dan McDonald Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Comments inline... >-----Original Message----- >From: Tero Kivinen [mailto:kivinen@iki.fi] >Sent: Wednesday, December 03, 2008 5:00 AM >To: Grewal, Ken >Cc: Dan McDonald; ipsec@ietf.org >Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > >Grewal, Ken writes: >> One observation with this proposal (call it the SPI semantics >> proposal) is legacy incompatibility. >> >> All endpoint implementations would need to ensure they follow these >> rules and change their implementations accordingly. If there are any >> implementations within a network that do not follow these rules, we >> are back to invalid inferences. > >I.e it as exactly same problems as what modifying ESP in general >has... [Ken] Slightly different - SPI semantics requires all nodes to be upgraded before it can be deployed (else there will be collisions in SPI usage between legacy and new), whereas WESP does not require all nodes to be upgraded immediately, as it is a new protocol and can co-exist with the legacy solutions. > >> Another observation along similar lines is any HW devices that are >> encoding additional lookup information directly into the Rx SPI >> (which is under the control of the recipient) to allow optimized Rx >> SA lookup (e.g. masking some SPI bits to extract a direct SA index >> into the SADB) will now need to be changed also. I actually did one >> of these in my previous life. > >I would guess those changes would also be quite small. [Ken] Depends on your implementation...and this will require a forklift upgrade to ensure it is collision free. > >On the other hand another problem with that proposal is that there is >no ICV length information there. I assume that when those were >proposed we had only ICV length of 12 to consider, but now we also >have ICV lengths of 12, 16, 20, 24, and 32 to consider... > >Of course that information could also be encoded to the SPI if this >proposal would go forward, but this still has the problem you listed >first, meaning it requires changes to the all end nodes thus it will >be very slow to deploy (faster than WESP though, as the changes to >implementations would be smaller). [Ken] Once we start consuming a few bits from the SPI, there will always be a need to consume some more at a later stage (new algorithms, IVs, Lengths, etc.), hence this does not make for an elegant or scalable solution. >-- >kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 3 08:57: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 99A1428C119; Wed, 3 Dec 2008 08:57:22 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C29D28C0DD for ; Wed, 3 Dec 2008 08:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBJva--HqHgz for ; Wed, 3 Dec 2008 08:57:21 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 5D5F928C119 for ; Wed, 3 Dec 2008 08:57:21 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 03 Dec 2008 08:50:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.33,708,1220252400"; d="scan'208";a="646620039" Received: from unknown (HELO azsmsx001.amr.corp.intel.com) ([10.2.167.98]) by fmsmga001.fm.intel.com with ESMTP; 03 Dec 2008 08:57:54 -0800 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by azsmsx001.amr.corp.intel.com (10.2.167.98) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 3 Dec 2008 09:57:08 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Wed, 3 Dec 2008 09:56:56 -0700 From: "Grewal, Ken" To: Tero Kivinen Date: Wed, 3 Dec 2008 09:56:47 -0700 Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclVStswdAjeY+viQoS1MTB7d3725wAG8A0A Message-ID: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> <18742.35113.355935.776274@fireball.kivinen.iki.fi> In-Reply-To: <18742.35113.355935.776274@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Some comments inline... >-----Original Message----- >From: Tero Kivinen [mailto:kivinen@iki.fi] >Sent: Wednesday, December 03, 2008 5:27 AM >To: Grewal, Ken >Cc: ipsec@ietf.org >Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > >Grewal, Ken writes: >> Heuristics based solutions can be expensive to implement in HW as >> well as being inconclusive, providing assurances based on >> probabilities and hence prone to false positives. > >Note, that false positivies could only happen for very few first >packets, after the SPI is known to be either encrypted ESP or >ESP-NULL, then there will not be any false positives or negatives. > [Ken] This assumes the intermediate device HW keeps state on each flow, including knowledge of SPI, algorithms, IV lengths, etc., which is not done today. This is a huge overhead for these devices, especially using expensive SRAM to keep state and ensuring all the lookups fit into the current design / pipeline. By contrast, the WESP solution is stateless, as all needed info is carried in the packet. >On the other hand implementing deep inspection on hardware on the TCP >or HTTP request is several orders of magnitude more complicated than >to check the SPI and see if that is known and do processing based on >the SPI. > [Ken] I agree that higher layer protocol offloads such as TCP is more expensive, but this depends on your device capabilities and not all devices do TCP offload. In either case, it goes back to the comment from Dan - you want me to add state for thousands or millions of SAs into an already complicated HW design - easier way is to parse a simple protocol and make it stateless. >> Furthermore, some HW devices (especially Network Interface Cards, >> NICs) currently only examine packet headers and do not load the >> whole packet into memory. In aggregated environments, where these >> devices need to maintain line rate processing, subtle changes in >> design such as loading the whole packet into memory and parsing the >> packet trailer before making a decision if the packet should be sent >> to one CPU core or another for processing will have drastic impact >> on the packet processing engines of such devices (compared with a >> simple, deterministic approach such as in the current draft). > >In normal case NIC does not need to find the protocol number to decide >what to do with the packet, the SPI will be enough. If SPI is unknown, >then packet is dropped to CPU so CPU can run heuristics. If SPI is >known and is known to be ESP encrypted, then packet is passed directly >forward as no deep inspection can be done. > >If SPI is known and is known to be ESP-NULL and SPI is marked as one >that requires deep inspection (if there is cases where ESP-NULL >packets can also be marked as bypassing deep inspection) then packet >is thrown to the deep inspection engine, which will require the full >packet anyways, so getting the protocol number from the end of the >packet will not cause any problems. [Ken] I disagree. Protocols numbers and ports are commonly used for assigning flows to a CPU core. Gone are the days of a single CPU and we are now in a world of multi-core environment. In a multi-core system, it is imperative to ensure that a given flow (e.g. TCP) is sent to the same core as the previous one with the same characteristics (protocol / ports), as that core has any state information associated with the flow. If this not done, it leads to considerable performance degradation, as data now needs to be moved between memory / cache of different cores unnecessarily. So, visibility into protocol / ports is imperative. This was one of the motivations of adding the protocol number to the header, so we do not need to load the whole packet into memory to extract this from the trailer. >-- >kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 3 09:00: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 4D6623A6930; Wed, 3 Dec 2008 09:00:23 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1EBC3A6886 for ; Wed, 3 Dec 2008 09:00:21 -0800 (PST) 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 w+dYflmczoXh for ; Wed, 3 Dec 2008 09:00:20 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id A4F923A6930 for ; Wed, 3 Dec 2008 09:00:20 -0800 (PST) Received: by qyk4 with SMTP id 4so4295526qyk.13 for ; Wed, 03 Dec 2008 09:00:14 -0800 (PST) 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=82PDNSmBoq9VqhEX4DxBYOGJh3Tohyw69R73GmejqkA=; b=qwKOT1qJdK5ar9y7j9iygAuOa012FEv6zi8IeP5tWCVY1Ux7u1duUm8k5JKtxTKit1 Pc2ypPTdiwGe/c6yAq9te6V9x8Lb0HJbYtvePJaVbCyZRYDZNOCrXYp56GxfQ59tFNZk o0eHLaBh7Y9hVVh6aSul7zvl7YGiykLC0LPBs= 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=B4easIQNPqCoUwGieYfUX5UPmSMePt6jqlo8jnaEsobRco4l3hhRuTWf/hEav4SUMC UMziQJKw5zMDsDP59hh6WNgwYHTaRU+ozbrzrbwoUn6A9HuS71wIANoSp0K/NSPI9JXl 3nkLjWlYlcVsHMBrzv+0wDJOcsWcXcHtnfHA4= Received: by 10.142.237.19 with SMTP id k19mr5468953wfh.209.1228323613869; Wed, 03 Dec 2008 09:00:13 -0800 (PST) Received: by 10.142.171.20 with HTTP; Wed, 3 Dec 2008 09:00:13 -0800 (PST) Message-ID: Date: Wed, 3 Dec 2008 22:30:13 +0530 From: "Jack Kohn" To: "Grewal, Ken" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <20081202185314.GH6533@sun.com> <20081202212058.GA7728@sun.com> <18742.33512.884628.356909@fireball.kivinen.iki.fi> Cc: "ipsec@ietf.org" , Dan McDonald , Tero Kivinen Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > > [Ken] Slightly different - SPI semantics requires all nodes to be upgraded before > it can be deployed (else there will be collisions in SPI usage between legacy and This is incorrect. There will never be a conflict as the bhatia proposal uses a reserved SPI value, something that the legacy implementations will never allocate. > new), whereas WESP does not require all nodes to be upgraded immediately, > as it is a new protocol and can co-exist with the legacy solutions.> >> > >> >>On the other hand another problem with that proposal is that there is >>no ICV length information there. I assume that when those were >>proposed we had only ICV length of 12 to consider, but now we also >>have ICV lengths of 12, 16, 20, 24, and 32 to consider... >> >>Of course that information could also be encoded to the SPI if this >>proposal would go forward, but this still has the problem you listed >>first, meaning it requires changes to the all end nodes thus it will >>be very slow to deploy (faster than WESP though, as the changes to >>implementations would be smaller). > > [Ken] Once we start consuming a few bits from the SPI, there will always be a need to consume some more at a later stage (new algorithms, IVs, Lengths, etc.), hence this does not make for an elegant or scalable solution. Why would a new algorithm require a new reserved SPI? Similarly IVs, if required, are always a part of the payload. So whats the problem? Jack > >>-- >>kivinen@iki.fi > _______________________________________________ > 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 Dec 3 09:07: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 333EB3A67ED; Wed, 3 Dec 2008 09:07:00 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 530793A67ED for ; Wed, 3 Dec 2008 09:06:59 -0800 (PST) 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 TKhsua7fC1KA for ; Wed, 3 Dec 2008 09:06:58 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 330D73A67E2 for ; Wed, 3 Dec 2008 09:06:58 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 03 Dec 2008 09:04:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.33,708,1220252400"; d="scan'208";a="367674256" Received: from unknown (HELO azsmsx001.amr.corp.intel.com) ([10.2.167.98]) by orsmga002.jf.intel.com with ESMTP; 03 Dec 2008 09:05:45 -0800 Received: from rrsmsx602.amr.corp.intel.com (10.31.0.33) by azsmsx001.amr.corp.intel.com (10.2.167.98) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 3 Dec 2008 10:06:44 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Wed, 3 Dec 2008 10:06:42 -0700 From: "Grewal, Ken" To: Jack Kohn Date: Wed, 3 Dec 2008 10:06:32 -0700 Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclVaKJkO3x0yhIsREGzS+3kflL10QAABlSA Message-ID: References: <20081202185314.GH6533@sun.com> <20081202212058.GA7728@sun.com> <18742.33512.884628.356909@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Tero@core3.amsl.com, Kivinen , Dan McDonald Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Jack, This discussion is in the context of a different thread from the reserved SPI discussion - this is in the context of reserving bits from the SPI and the protocol / packet format remains unchanged - please see the whole thread started by Dan McDonald and Scott Moonen. Thanks, - Ken >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Jack Kohn >Sent: Wednesday, December 03, 2008 9:00 AM >To: Grewal, Ken >Cc: ipsec@ietf.org; Dan McDonald; Tero Kivinen >Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > >> >> [Ken] Slightly different - SPI semantics requires all nodes to be >upgraded before >> it can be deployed (else there will be collisions in SPI usage between >legacy and > >This is incorrect. There will never be a conflict as the bhatia >proposal uses a reserved SPI value, something that the legacy >implementations will never allocate. > >> new), whereas WESP does not require all nodes to be upgraded immediately, >> as it is a new protocol and can co-exist with the legacy solutions.> >>> >> >>> >>>On the other hand another problem with that proposal is that there is >>>no ICV length information there. I assume that when those were >>>proposed we had only ICV length of 12 to consider, but now we also >>>have ICV lengths of 12, 16, 20, 24, and 32 to consider... >>> >>>Of course that information could also be encoded to the SPI if this >>>proposal would go forward, but this still has the problem you listed >>>first, meaning it requires changes to the all end nodes thus it will >>>be very slow to deploy (faster than WESP though, as the changes to >>>implementations would be smaller). >> >> [Ken] Once we start consuming a few bits from the SPI, there will always >be a need to consume some more at a later stage (new algorithms, IVs, >Lengths, etc.), hence this does not make for an elegant or scalable >solution. > >Why would a new algorithm require a new reserved SPI? Similarly IVs, >if required, are always a part of the payload. So whats the problem? > >Jack > > >> >>>-- >>>kivinen@iki.fi >> _______________________________________________ >> 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 Wed Dec 3 09:08: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 CFC5F3A69C5; Wed, 3 Dec 2008 09:08:30 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0463A69C5 for ; Wed, 3 Dec 2008 09:08:29 -0800 (PST) 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 dtzacjU44JhA for ; Wed, 3 Dec 2008 09:08:28 -0800 (PST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 620A63A67E2 for ; Wed, 3 Dec 2008 09:08:28 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 03 Dec 2008 09:05:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.33,708,1220252400"; d="scan'208";a="367674685" Received: from unknown (HELO azsmsx601.amr.corp.intel.com) ([10.2.121.193]) by orsmga002.jf.intel.com with ESMTP; 03 Dec 2008 09:07:09 -0800 Received: from rrsmsx604.amr.corp.intel.com (10.31.0.170) by azsmsx601.amr.corp.intel.com (10.2.121.193) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 3 Dec 2008 10:08:05 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Wed, 3 Dec 2008 10:08:05 -0700 From: "Grewal, Ken" To: Tero Kivinen , Gary Hemminger Date: Wed, 3 Dec 2008 10:07:55 -0700 Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclVSXSG1Y8DXnCpRdyccVuS4kVKdAAHvF1A Message-ID: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> <18742.34476.957638.373556@fireball.kivinen.iki.fi> In-Reply-To: <18742.34476.957638.373556@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Comments inline... >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Tero Kivinen >Sent: Wednesday, December 03, 2008 5:16 AM >To: Gary Hemminger >Cc: ipsec@ietf.org >Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets > >Gary Hemminger writes: >> I chimed in on this earlier and want to provide feedback from a network >> (L2-3) and application delivery controller (load balancer) perspective. >> That perspective is that basically everyone in the industry uses >> merchant silicon (ie Broadcom/Marvell) to provide network functionality. >> Some kind of heuristic approach is going to be very difficult to >> convince them to provide vs. having a deterministic approach, in my >> opinion. > >It will be about same to get the IPsec chip vendors to provide support >for WESP. In either case silicon vendors need to implement new >functionality and it will be slow before the actual chips are out. On >the other side the good thing is that most of those complicated deep >inspection engines (and actually security processors too) are very >programmable already thus they might not require actual silicon >changes, but just some tweaking on the firmware. [Ken] Adding knowledge about each SA based on SPI, algorithms, IV/ICV lengths, etc., when that info does not exist in the hardware is hardly tweaking. It is major surgery. > >> That said, the previous emails seemed to indicate that the heuristic >> approach would not require any retooling. Can someone explain that >> magic to me? > >If you use heuristic approach then the ESP and all end nodes would >remain intact, i.e. no changes is required to them. Also no changes >will be done on the normal firewalls or routers (i.e. the ones not >doing deep inspection). > >Only devices which do require changes will be the deep inspection >middleboxes, and there the changes required for the fastpath are going >to be quite small (add SPI to the flow lookup, load ICV_len and IV_len >from the state information so they can know the offsets where the >protocol number is located and where the actual payload starts). > >All the more complicated heuristics would most likely be done on the >slowpath anyways, and even there it would be too complicated (much >simplier than checking TCP headers). > >Also all deep inspection engines need to load the full packet to the >deep inspection engine anyways (usually they also need to reassemble >IP fragments to get full packet, and even reorder out of order TCP >segments and remove overlapping TCP segments before doing inspection), >so I do not really belive there is any deep inspection engines where >getting the protocol number from the end of the packet would really be >problem. [Ken] Please see my comments on the other email regarding need for protocol number in a multi-core environment. [Ken] >-- >kivinen@iki.fi >_______________________________________________ >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 Dec 3 11:06: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 0FF6D3A6B8B; Wed, 3 Dec 2008 11:06:41 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8711B3A6B87 for ; Wed, 3 Dec 2008 11:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhA4Br0C64f5 for ; Wed, 3 Dec 2008 11:06:38 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 4ED063A69E2 for ; Wed, 3 Dec 2008 11:05:44 -0800 (PST) Received: by qyk4 with SMTP id 4so4461753qyk.13 for ; Wed, 03 Dec 2008 11:05:39 -0800 (PST) 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=yxlmFh5APnsJfdurExCl9vtLi+XqFb59XjGU3qSLtM0=; b=iz36TPWTEGlOd+EXd0s5FzdTAfemo+D+UOo5MbpTXtORGrArDSfp0bM6WJey0aCRJT aTbOIdEoyty3PM3XueiKCvAXCj5C32LEByTjyvyYOb8xfQyua4nDX+vTgi7+SrRnN2NB xijVw/bf/ypfTgbySPRt2s7c5Y3FPR7tmjgvc= 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=kvZeLV2XnlYzCx3QshJ/R1EP4rNfICdbCmASnSp8fQIyit2v2GpbY7ihlPDsK9/fv8 qiokz29dmasVkI8DYR5Jbbst+dtjw+4qXigwkdD/ImatlLGWrMm9AB713+dk6SKsoTSS flH101Y5eb8+8jesKFL/LxslpIPqHvTmzDRIE= Received: by 10.215.66.20 with SMTP id t20mr13826284qak.330.1228331138999; Wed, 03 Dec 2008 11:05:38 -0800 (PST) Received: by 10.214.181.8 with HTTP; Wed, 3 Dec 2008 11:05:38 -0800 (PST) Message-ID: Date: Wed, 3 Dec 2008 11:05:38 -0800 From: "fan zhao" To: "Tero Kivinen" In-Reply-To: <18742.32982.788647.641072@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, Thanks for your reply. If you do not mind, I will call redirection in the last message during the IKE_AUTH as "redirect_auth" and redirection during the separate informational exchange as "redirect_info" in the following text. On Wed, Dec 3, 2008 at 4:51 AM, Tero Kivinen wrote: > fan zhao writes: >> 2) The IPsec client requests to set up the child SA during IKE_AUTH >> client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH SAi2, TSi, TSr} > > If we want to allow redirection during the IKE_AUTH, I think this > second option is the one we want to select. This would be identical to > normal exchange, thus it will cause smaller changes, and it has good > property that if server does NOT do redirect we get the IPsec SA done > after this. I think this property is also supported by the redirect_auth since if the IPsec server does not want to do redirect, it simply does not include the Redirect payload. > In any cause we MUST NOT define two different ways how to > do this, as that would just add unnessary complexity. So if we are > going to select one, lets select this one. This is always a good principle to follow in general. However, in this case, my understanding is that the redirect_auth and the redirect_info address different needs. For example, when an IPsec server serving IPsec clients realizes that it is overloaded or it needs to shut down for administration reasons, the server can inform the clients by using redirect_info. On the other hand, when the IPsec server realizes that the client connects to a different server from the one in the client's profile, it performs the redirect_auth that IMO is simpler and mroe efficient that the redirect_info in this case. I do not see they are two different methods for the same purpose. > > On the other hand the difference between doing the IKE_AUTH to end and > doing INFORMATINAL exchange after that to do redirect is even > simplier, as we still want to support that option too, and the most > time consuming part of the IKE_AUTH (Diffie-Hellman, Signing etc) is > already done anyways, so doing it as separate INFOMRATIONL exchange, > simply wastes 2 extra small packets but no extra round trips. Note, > that server can reject the IPsec SA creation by returning suitable > error message (for example NO_ADDITIONAL_SAS) in the IKE_AUTH, and > then the full exchange would be: > > > Initiator Responder > ------------------------------------------------------------------- > HDR, SAi1, KEi, Ni, > N(REDIRECT_SUPPORTED) --> > > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > > HDR, SK {IDi, [CERT,] [CERTREQ,] > [IDr,] AUTH, SAi2, > TSi, TSr} --> > > > <-- HDR, SK {IDr, [CERT,] AUTH, > N(NO_ADDITIONAL_SAS)} > <-- HDR, SK {N(REDIRECT)} What happens if these two messages from the server are reordered during transmisstion, and either HDR, SK {N(REDIRECT)} or HDR, SK {IDr, [CERT,] AUTH, N(NO_ADDITIONAL_SAS)} is dropped during transmission? Thanks. Sincerely, fan > > > HDR, SK {N(REDIRECT_ACK)} --> > HDR, SAi1, KEi, Ni, > N(REDIRECT_FROM) --> > > I.e. the server would reply N(NO_ADDITIONAL_SAS) and immediately after > that send N(REDIRECT) notify as separate INFORMATINAL exchange. The > initiator would first get the IKE_AUTH reply, process that, and > immediately after that get INFORMATINAL exhange asking to N(REDIRECT). > > The initiator can start connection to the new IKE SA immediately when > it receives the N(REDIRECT) thus it does not waste any single round > trip, only wasted resource would be 2 small packets (less than 100 > bytes each). > > I think this is simplier and cleaner way to get the same effect with > no extra real cost. > -- > kivinen@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From letrado@abrahamlincoln.edu.co Wed Dec 3 12:59:42 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7904F3A6A3C for ; Wed, 3 Dec 2008 12:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -19.884 X-Spam-Level: X-Spam-Status: No, score=-19.884 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJ7zbb1vF7yA for ; Wed, 3 Dec 2008 12:59:41 -0800 (PST) Received: from 87-97-124-244.pool.invitel.hu (87-97-124-244.pool.invitel.hu [87.97.124.244]) by core3.amsl.com (Postfix) with SMTP id 358373A6A28 for ; Wed, 3 Dec 2008 12:59:39 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081203205940.358373A6A28@core3.amsl.com> Date: Wed, 3 Dec 2008 12:59:39 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Wed Dec 3 13:05:44 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D9723A6A10; Wed, 3 Dec 2008 13:05:44 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED9943A6999 for ; Wed, 3 Dec 2008 13:05:42 -0800 (PST) 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 4ladAw5+v4LZ for ; Wed, 3 Dec 2008 13:05:42 -0800 (PST) Received: from smtp1gap.foundrynet.com (smtp1gap.foundrynet.com [76.199.70.29]) by core3.amsl.com (Postfix) with ESMTP id 3D50F3A67ED for ; Wed, 3 Dec 2008 13:05:42 -0800 (PST) Received: from xmail.ds.foundrynet.com (unknown [10.101.218.254]) by smtp1gap.foundrynet.com (Postfix) with ESMTP id 3BB0D3E0002; Wed, 3 Dec 2008 13:05:18 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 Dec 2008 13:06:20 -0800 Message-ID: In-Reply-To: <18742.33512.884628.356909@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Deep Inspecting ESP-NULL Packets Thread-Index: AclVR1nZ5WM1ohVASZebeUw60bRltgAQ6Fsg References: <18736.7977.492687.346315@fireball.kivinen.iki.fi><18739.63975.625276.269689@fireball.kivinen.iki.fi><20081202185314.GH6533@sun.com><20081202212058.GA7728@sun.com> <18742.33512.884628.356909@fireball.kivinen.iki.fi> From: "Gary Hemminger" To: "Tero Kivinen" , "Grewal, Ken" Cc: ipsec@ietf.org, Dan McDonald Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org GRE -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Wednesday, December 03, 2008 5:00 AM To: Grewal, Ken Cc: ipsec@ietf.org; Dan McDonald Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets Grewal, Ken writes: > One observation with this proposal (call it the SPI semantics > proposal) is legacy incompatibility. > > All endpoint implementations would need to ensure they follow these > rules and change their implementations accordingly. If there are any > implementations within a network that do not follow these rules, we > are back to invalid inferences. I.e it as exactly same problems as what modifying ESP in general has... > Another observation along similar lines is any HW devices that are > encoding additional lookup information directly into the Rx SPI > (which is under the control of the recipient) to allow optimized Rx > SA lookup (e.g. masking some SPI bits to extract a direct SA index > into the SADB) will now need to be changed also. I actually did one > of these in my previous life. I would guess those changes would also be quite small. On the other hand another problem with that proposal is that there is no ICV length information there. I assume that when those were proposed we had only ICV length of 12 to consider, but now we also have ICV lengths of 12, 16, 20, 24, and 32 to consider... Of course that information could also be encoded to the SPI if this proposal would go forward, but this still has the problem you listed first, meaning it requires changes to the all end nodes thus it will be very slow to deploy (faster than WESP though, as the changes to implementations would be smaller). -- kivinen@iki.fi _______________________________________________ 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 mpitawanakwat@amtelecom.net Wed Dec 3 16:38:36 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 686B33A6BE7 for ; Wed, 3 Dec 2008 16:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -29.345 X-Spam-Level: X-Spam-Status: No, score=-29.345 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pN1t0yYsOQfo for ; Wed, 3 Dec 2008 16:38:35 -0800 (PST) Received: from allgaeuer-anzeigeblatt.de (unknown [189.61.52.67]) by core3.amsl.com (Postfix) with SMTP id 9B68E3A6BE4 for ; Wed, 3 Dec 2008 16:38:34 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081204003834.9B68E3A6BE4@core3.amsl.com> Date: Wed, 3 Dec 2008 16:38:34 -0800 (PST) Click here to view as a webpage From ipsec-bounces@ietf.org Thu Dec 4 04:36: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 50C8628C0EB; Thu, 4 Dec 2008 04:36:49 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70B53A684F for ; Thu, 4 Dec 2008 04:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVgawk9VRFGZ for ; Thu, 4 Dec 2008 04:36:45 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AB6893A6A38 for ; Thu, 4 Dec 2008 04:36:39 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB4CaWd8022471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2008 14:36:32 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB4CaVXV024053; Thu, 4 Dec 2008 14:36:31 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18743.52943.772254.83902@fireball.kivinen.iki.fi> Date: Thu, 4 Dec 2008 14:36:31 +0200 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <18736.7977.492687.346315@fireball.kivinen.iki.fi> <18739.63975.625276.269689@fireball.kivinen.iki.fi> <18742.35113.355935.776274@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 28 min X-Total-Time: 151 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Deep Inspecting ESP-NULL Packets X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org [I combined the to replies to one] Grewal, Ken writes: > [Ken] This assumes the intermediate device HW keeps state on each > flow, including knowledge of SPI, algorithms, IV lengths, etc., > which is not done today. This is a huge overhead for these devices, > especially using expensive SRAM to keep state and ensuring all the > lookups fit into the current design / pipeline. By contrast, the > WESP solution is stateless, as all needed info is carried in the > packet. We are talking here about DEEP INSPECTION devices. All of such devices need to be stateful to do anything useful. The ACL list based on the TCP/UDP port numbers are not really useful for deep inspection or protection, thus I do not consider stateless cases for this case useful. Almost every modern firewall / IDS / IPS system around now is already keeping lots of state, so adding SPI there isn't really a problem. WESP solution is stateless, and it can be used by the firewalls around year 2020, not before. Before that firewall vendors and such still need to provide some method of doing the same thing, thus they will need to implement the heuristics anyways regradless whether we have WESP or not and the only benefit for using WESP instead of heauristics at year 2020 when both area available is that WESP can be used also for stateless devices. The trend I am seeing is that more and more security devices are going to be statefull even in the very small ones, I do not think there will be that many stateless security devices around year 2020. Do you really see there will be lots of stateless security devices inspecting WESP-NULL traffic around year 2020? > >On the other hand implementing deep inspection on hardware on the TCP > >or HTTP request is several orders of magnitude more complicated than > >to check the SPI and see if that is known and do processing based on > >the SPI. > > > [Ken] I agree that higher layer protocol offloads such as TCP is > more expensive, but this depends on your device capabilities and not > all devices do TCP offload. In either case, it goes back to the > comment from Dan - you want me to add state for thousands or > millions of SAs into an already complicated HW design - easier way > is to parse a simple protocol and make it stateless. If you are doing deep inspection device you need to cope with at least 10 or 100 times more of TCP/UDP flows inside single SA, so the cost of storing the per SA information is quite small compared to the TCP/UDP state. I agree it would be easier, but I claim it would be completely doable, and actually much easier than most of the things the complicated HW designs already do. I mean there are full security prosessors out there who can save the same amount of SA information and also keep the track of keying material and encrypt and authenticate all packets going in and coming out from the SA... Keeping track of the SPI, ICV len, IV len is very simple compared to that. And I do not think you have option, your customers will want the solution now, not year 2020, thus you need to implement the heuristics now anyways, and I would rather only implement one method of doing the same thing than multiple different methods. If you do not implement the heuristics then your competitors will implement it and you will loose deals to them. I am pretty much sure that our customers will require us to implement the solution now, not in 10 years timeframe. > [Ken] I disagree. Protocols numbers and ports are commonly used for > assigning flows to a CPU core. Gone are the days of a single CPU and > we are now in a world of multi-core environment. In a multi-core > system, it is imperative to ensure that a given flow (e.g. TCP) is > sent to the same core as the previous one with the same > characteristics (protocol / ports), as that core has any state > information associated with the flow. If this not done, it leads to > considerable performance degradation, as data now needs to be moved > between memory / cache of different cores unnecessarily. As in this case the SPI number will be part of the flow, so IP and SPI numberswill select the CPU core for that specific flow. > So, visibility into protocol / ports is imperative. This was one of > the motivations of adding the protocol number to the header, so we > do not need to load the whole packet into memory to extract this > from the trailer. You do not need protocol or port numbers to demux packets to correct CPU, you can simply use IP and SPI numbers for that. You already have protocol number, that is 50, then you already have flow information per that protocol number, i.e. the SPI, you just demux packets based on that to the correct CPU core, and the CPU core will then demux things further based on the inner protocol number and port numbers. > [Ken] Adding knowledge about each SA based on SPI, algorithms, > IV/ICV lengths, etc., when that info does not exist in the hardware > is hardly tweaking. It is major surgery. Most of the modern security processor I know do use microcode to do part of the packet processing and modifying those do not require major surgery. There are limitations how much can be done with those and there are usually size constraints also, but this kind of changes (i.e. using SPI for flow lookup if protocol is ESP, and loading 2 bytes of extra data (ICV_len and IV_len) when loading flow data) should be doable with current hardware by just changing the firmware. I already commented earlier that it is doable in our own SafeXce-5160 hardware, or Octeon from Cavium. It should also be doable in Intel Tolapai chips too as far as I have understood things. Unfortunately I only know security coprocessor chips, I do not know that much what they use in deep inspection engines but I would guess they use even more programmable devices there. Can you give some examples in which modern chips that are used in deep inspection devices this is not doable? -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From momijasdd@aitlbd.net Thu Dec 4 05:01:07 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2128528C114 for ; Thu, 4 Dec 2008 05:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -21.968 X-Spam-Level: X-Spam-Status: No, score=-21.968 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUEbE00y3SVx for ; Thu, 4 Dec 2008 05:01:06 -0800 (PST) Received: from 201-25-211-46.fnsce702.dsl.brasiltelecom.net.br (201-25-211-46.fnsce702.dsl.brasiltelecom.net.br [201.25.211.46]) by core3.amsl.com (Postfix) with SMTP id A5A6D28C113 for ; Thu, 4 Dec 2008 05:00:50 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081204130057.A5A6D28C113@core3.amsl.com> Date: Thu, 4 Dec 2008 05:00:50 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Thu Dec 4 05:23: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 010F93A6A46; Thu, 4 Dec 2008 05:23:57 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB01A3A6A46 for ; Thu, 4 Dec 2008 05:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 xIYZjpU81L8w for ; Thu, 4 Dec 2008 05:23:54 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2F63A69D4 for ; Thu, 4 Dec 2008 05:23:54 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB4DNj87023903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2008 15:23:45 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB4DNjMa026841; Thu, 4 Dec 2008 15:23:45 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18743.55776.990379.921448@fireball.kivinen.iki.fi> Date: Thu, 4 Dec 2008 15:23:44 +0200 From: Tero Kivinen To: "fan zhao" In-Reply-To: References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 45 min Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org fan zhao writes: > On Wed, Dec 3, 2008 at 4:51 AM, Tero Kivinen wrote: > > fan zhao writes: > >> 2) The IPsec client requests to set up the child SA during IKE_AUTH > >> client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH SAi2, TSi, TSr} > > > > If we want to allow redirection during the IKE_AUTH, I think this > > second option is the one we want to select. This would be identical to > > normal exchange, thus it will cause smaller changes, and it has good > > property that if server does NOT do redirect we get the IPsec SA done > > after this. > I think this property is also supported by the redirect_auth since if > the IPsec server does not want to do redirect, it simply does not include > the Redirect payload. That would not be possible for the first option you gave, i.e. the one I did not include in my email. The one having only HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH}, as there is not enough information there to creat ethe IPsec SAs (i.e. the SAi2, TSi, and TSr are missing). > > In any cause we MUST NOT define two different ways how to > > do this, as that would just add unnessary complexity. So if we are > > going to select one, lets select this one. > This is always a good principle to follow in general. However, in this case, my > understanding is that the redirect_auth and the redirect_info address > different needs. For example, when an IPsec server serving IPsec clients > realizes that it is overloaded or it needs to shut down for > administration reasons, > the server can inform the clients by using redirect_info. > On the other hand, when the IPsec server realizes that the client connects > to a different server from the one in the client's profile, it > performs the redirect_auth > that IMO is simpler and mroe efficient that the redirect_info in this case. > I do not see they are two different methods for the same purpose. Yes, they are for different purposes, but on the other hand we can still use one way to solve both purposes, with only 2 extra 100 byte packets as an overhead (no round trips or anything like that). > > Initiator Responder > > ------------------------------------------------------------------- > > HDR, SAi1, KEi, Ni, > > N(REDIRECT_SUPPORTED) --> > > > > > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > > > > > HDR, SK {IDi, [CERT,] [CERTREQ,] > > [IDr,] AUTH, SAi2, > > TSi, TSr} --> > > > > > > <-- HDR, SK {IDr, [CERT,] AUTH, > > N(NO_ADDITIONAL_SAS)} > > <-- HDR, SK {N(REDIRECT)} > What happens if these two messages from the server are reordered > during transmisstion, and either HDR, SK {N(REDIRECT)} or > HDR, SK {IDr, [CERT,] AUTH, N(NO_ADDITIONAL_SAS)} is dropped > during transmission? Nothing special. The Client will either drop the N(REDIRECT) request if it comes before the reply for IKE_AUTH, or it will keep it on hold until the IKE_AUTH is processed. In any case it MUST to do the same thing it does normally when it receives request from the other end before it has received reply to the IKE_AUTH, i.e. it must process the IKE_AUTH first and check the AUTH payload before it is allowed to process any other requests from the other end. Note, that this is not special case for the N(REDIRECT), this thing can also happen with CREATE_CHILD_SA or any other exchange too. Our implementation will simply drop all those new request until it gets the reply back to the IKE_AUTH (just checked it with create child sa exchanges to be sure our code works correctly :-). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 4 07:08: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 042CA3A6891; Thu, 4 Dec 2008 07:08:45 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC873A6809 for ; Thu, 4 Dec 2008 07:08:43 -0800 (PST) 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 onzDHd0VC-8d for ; Thu, 4 Dec 2008 07:08:42 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 83F0B3A6A18 for ; Thu, 4 Dec 2008 07:08:42 -0800 (PST) Received: from [10.20.30.163] (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 mB4F8ZYW048928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Dec 2008 08:08:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 4 Dec 2008 07:08:34 -0800 To: IPsecme WG From: Paul Hoffman Subject: [IPsec] Minutes from Minneapolis 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 ... are at . Let me know if you see any errors. Thanks to David Black and Richard Gravemen for taking minutes! Thanks to Cheryl Madson for being Jabber responder! --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 4 12:57: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 A66363A69FD; Thu, 4 Dec 2008 12:57:30 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBCDA3A69FD for ; Thu, 4 Dec 2008 12:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Hz9jdooGy+bE for ; Thu, 4 Dec 2008 12:57:28 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 9A6BD3A6972 for ; Thu, 4 Dec 2008 12:57:28 -0800 (PST) Received: by qyk4 with SMTP id 4so5382116qyk.13 for ; Thu, 04 Dec 2008 12:57:23 -0800 (PST) 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=bTVSu9J4Azw84sVVsnVVARgbKCUSjhtVs+Bwf/JuNcw=; b=ZCxBuyedpTHVs0D/YqYkDRj+f/GOitjElkRBJB7XJXUX0cele00OVujS07PKAooqKU v74rXXwevCNKNB0t2h28lc1sPbiF3KQXf1MFc9j/rAtsboBMBEBqrYVSTmglWuZEzozH TVmuKmQWpue+CcZYjddzztszqkOKIU372wwt4= 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=Dh1b+QNV4mIStnWu1b6MW8EXNKAaCNPb3FHfgEuj7QJEquBuniziGFMoNDq371nhlk BW/iYKai1QIlND3LznGFM9Wesue57BN5PgV/9uv5KUKpigFH0FgqEateNlFUID+Cq1Xr 48ozrLUCGU2WqFHuY5ShWg3lrkOzi2Idb31cE= Received: by 10.214.78.2 with SMTP id a2mr15522630qab.136.1228424243376; Thu, 04 Dec 2008 12:57:23 -0800 (PST) Received: by 10.214.181.8 with HTTP; Thu, 4 Dec 2008 12:57:23 -0800 (PST) Message-ID: Date: Thu, 4 Dec 2008 12:57:23 -0800 From: "fan zhao" To: "Tero Kivinen" In-Reply-To: <18743.55776.990379.921448@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, Thanks for your reply. Please see below. On Thu, Dec 4, 2008 at 5:23 AM, Tero Kivinen wrote: > fan zhao writes: >> On Wed, Dec 3, 2008 at 4:51 AM, Tero Kivinen wrote: >> > fan zhao writes: >> >> 2) The IPsec client requests to set up the child SA during IKE_AUTH >> >> client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH SAi2, TSi, TSr} >> > >> > If we want to allow redirection during the IKE_AUTH, I think this >> > second option is the one we want to select. This would be identical to >> > normal exchange, thus it will cause smaller changes, and it has good >> > property that if server does NOT do redirect we get the IPsec SA done >> > after this. >> I think this property is also supported by the redirect_auth since if >> the IPsec server does not want to do redirect, it simply does not include >> the Redirect payload. > > That would not be possible for the first option you gave, i.e. the one > I did not include in my email. The one having only HDR, SK {IDi, > [CERT,] [CERTREQ,] [IDr,] AUTH}, as there is not enough information > there to creat ethe IPsec SAs (i.e. the SAi2, TSi, and TSr are > missing). Sorry I did not make myself clear. The first option I listed is the case where the client does not want to set up a child SA during the IKE_AUTH. If the client wants to do that, it can send the message as described in the second option I listed. I listed two options separately, but with the redirect during the IKE_AUTH, the SA can be established if the client wants to create the child SA and the server does not need to redirect the client. > >> > In any cause we MUST NOT define two different ways how to >> > do this, as that would just add unnessary complexity. So if we are >> > going to select one, lets select this one. >> This is always a good principle to follow in general. However, in this case, my >> understanding is that the redirect_auth and the redirect_info address >> different needs. For example, when an IPsec server serving IPsec clients >> realizes that it is overloaded or it needs to shut down for >> administration reasons, >> the server can inform the clients by using redirect_info. >> On the other hand, when the IPsec server realizes that the client connects >> to a different server from the one in the client's profile, it >> performs the redirect_auth >> that IMO is simpler and mroe efficient that the redirect_info in this case. >> I do not see they are two different methods for the same purpose. > > Yes, they are for different purposes, but on the other hand we can > still use one way to solve both purposes, with only 2 extra 100 byte > packets as an overhead (no round trips or anything like that). Actually I think the redirect during the IKE_AUTH is similar to the redirect during the IKE_SA_INIT with the unicast IPsec gateway, with the only difference that is during the IKE_AUTH, the IPSec gateway takes not only its load condition but also the ID of the client into consideration. I agree that the redirect during the informational exchange works in both cases. However, if it is more efficient and does not introduce much complexity, I do not see why we do not take advantage of the already defined REDIRECT payload and use it during the IKE_AUTH. Using one way for multiple purposes in general is good to simplify the solution. In this case, I do not see much benefit by excluding the REDIRECT payload from the IKE_AUTH. > >> > Initiator Responder >> > ------------------------------------------------------------------- >> > HDR, SAi1, KEi, Ni, >> > N(REDIRECT_SUPPORTED) --> >> > >> > >> > <-- HDR, SAr1, KEr, Nr, [CERTREQ] >> > >> > >> > HDR, SK {IDi, [CERT,] [CERTREQ,] >> > [IDr,] AUTH, SAi2, >> > TSi, TSr} --> >> > >> > >> > <-- HDR, SK {IDr, [CERT,] AUTH, >> > N(NO_ADDITIONAL_SAS)} >> > <-- HDR, SK {N(REDIRECT)} >> What happens if these two messages from the server are reordered >> during transmisstion, and either HDR, SK {N(REDIRECT)} or >> HDR, SK {IDr, [CERT,] AUTH, N(NO_ADDITIONAL_SAS)} is dropped >> during transmission? > > Nothing special. The Client will either drop the N(REDIRECT) request > if it comes before the reply for IKE_AUTH, or it will keep it on hold > until the IKE_AUTH is processed. In any case it MUST to do the same > thing it does normally when it receives request from the other end > before it has received reply to the IKE_AUTH, i.e. it must process the > IKE_AUTH first and check the AUTH payload before it is allowed to > process any other requests from the other end. I never doubt that there are methods to handle packet reordering and loss. Nevertheless, if the REDIRECT payload is carried in the message, we do not have to worry about these conditions and consequences. > > Note, that this is not special case for the N(REDIRECT), this thing > can also happen with CREATE_CHILD_SA or any other exchange too. Our > implementation will simply drop all those new request until it gets > the reply back to the IKE_AUTH (just checked it with create child sa > exchanges to be sure our code works correctly :-). Good for you ;-) Sincerely, fan > -- > kivinen@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From keptx@agriquem.com Fri Dec 5 02:35:47 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4122E3A6782 for ; Fri, 5 Dec 2008 02:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -34.397 X-Spam-Level: X-Spam-Status: No, score=-34.397 tagged_above=-999 required=5 tests=[BAYES_60=1, HELO_DYNAMIC_DIALIN=3.384, HELO_EQ_DIP_DIALIN=1.573, HOST_EQ_DIP_TDIAL=2.144, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yEICXjyXg-n for ; Fri, 5 Dec 2008 02:35:46 -0800 (PST) Received: from p57B07295.dip.t-dialin.net (p57B07295.dip.t-dialin.net [87.176.114.149]) by core3.amsl.com (Postfix) with SMTP id 732633A6AFB for ; Fri, 5 Dec 2008 02:35:44 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081205103545.732633A6AFB@core3.amsl.com> Date: Fri, 5 Dec 2008 02:35:44 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Fri Dec 5 03:38:21 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044793A6A70; Fri, 5 Dec 2008 03:38:21 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25073A6A70 for ; Fri, 5 Dec 2008 03:38:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 LNLf2TMA+fuF for ; Fri, 5 Dec 2008 03:38:18 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 201EA3A68DE for ; Fri, 5 Dec 2008 03:38:17 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB5Bc7Ga001315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Dec 2008 13:38:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB5Bc6p6025111; Fri, 5 Dec 2008 13:38:06 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18745.4766.35985.750878@fireball.kivinen.iki.fi> Date: Fri, 5 Dec 2008 13:38:06 +0200 From: Tero Kivinen To: "fan zhao" In-Reply-To: References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 23 min X-Total-Time: 26 min Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org fan zhao writes: > Sorry I did not make myself clear. The first option I listed is the case > where the client does not want to set up a child SA during the IKE_AUTH. There is no such option currently. The SAi1, TSi, and TSr payloads are NOT OPTIONAL in the IKE_AUTH. I see no point to adding such option, as if the client does not want to create IPsec SA with the server, why did he connect in the first place. > If the client wants to do that, it can send the message as described > in the second option I listed. I listed two options separately, but > with the redirect during the IKE_AUTH, the SA can be established if the > client wants to create the child SA and the server does not need to redirect > the client. RFC4306 and ikev2bis documents do not offer such option, so I naturally assumed you wanted to add that option for special case for redirect case just in case client does not want to create IPsec SA because he assumes server will redirect him somewhere else. Even in that case the client usually would not have information whether server will redirect him or not, so he should always try to create IPsec SA and if server wants to redirect client, then it can refuse creation of the IPsec SA as it would be teared down immediately when client disconnects and reconnects to another place. > Actually I think the redirect during the IKE_AUTH is similar to > the redirect during the IKE_SA_INIT with the unicast IPsec gateway, > with the only difference that is during the IKE_AUTH, the IPSec > gateway takes not only its load condition but also the ID of the client > into consideration. The reason for doing redirect during IKE_SA_INIT is to avoid server doing any expensive calculations, thus not making loaded server even more loaded by doing Diffie-Hellman and signature calculations before redirecting clients to not so loaded servers. In the IKE_AUTH the server has already done all those calculations so there is no benefit for doing it inside the IKE_AUTH compared to separate INFORMATIONAL exchange. > I agree that the redirect during the informational exchange works in > both cases. However, if it is more efficient and does not introduce > much complexity, I do not see why we do not take advantage of > the already defined REDIRECT payload and use it during the IKE_AUTH. It adds yet another mode that needs to be tests. That mode needs to be tested with all possible authentication combinations (4 + EAP methods * 2). It needs to be tested with other initial exchange combinations, i.e. INVALID_KE_PAYLOAD and COOKIE notification cases, it needs to be tested with MOBIKE extensions, it needs to be tested with NAT traversal cases, etc. Adding one more mode there adds lots of complexity to testing effort and also makes the already complicated IKE_AUTH state machine even more complicated. So I strongly disagree your comment that it "does not introduce much complexity". I also mostly disagree your comment that it "is more efficient", as I do not see 2 * 100 byte packets, without any additinal round trips or similar really that much more efficient that it would matter. > Using one way for multiple purposes in general is good to simplify > the solution. In this case, I do not see much benefit by excluding > the REDIRECT payload from the IKE_AUTH. Then we disagree on that, as I do see major benefit of not making the most complex part of the IKEv2 even more complex. > I never doubt that there are methods to handle packet reordering and loss. > Nevertheless, if the REDIRECT payload is carried in the message, > we do not have to worry about these conditions and consequences. Complient IKEv2 implementation MUST be able to handle packet reordering and loss regardless whether we make this extension or not. REDIRECT notify does not add any new requirements for this part, it is already there, and if implementation does not handle packet reordering or packet loss, it is complectely broken and unsecure. I.e. if for example the client would accept CREATE_CHILD_SA before checking the IKE_AUTH auth payload, that would allow attacker to do following active attack: Initiator Attacker ------------------------------------------------------------------- HDR, SAi1, KEi, Ni --> Attacker makes sure the packets do not ever reach the intended destination, but instead intercepts them and responds to them himself. <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> As the attacker send the KEr instead of the real responder, he is able to do Diffie-Hellam calculations and getting the keying material for the packet. Now the client would notice the man in the middle if attacker would send reply to this IKE_AUTH as attacker would not be able to generate valid AUTH payload. So he does not send IKE_AUTH at all, but instead starts new CREATE_CHILD_SA exchange with client. <-- HDR, SK {SA, Ni, TSi, TSr } If the client will process the create child sa before verifing the AUTH payload of the IKE_AUTH (which has not been sent) it attacker can create IPsec SA with Initiator where the Initiator belives the other end is valid Responder So the Initiator in this case MUST not reply to the new CREATE_CHILD_SA as otherwise he opens himself to big security hole. This is specified in the section 1 of the RFC 4306 (and IKEv2bis): ---------------------------------------------------------------------- ... In all cases, all IKE_SA_INIT exchanges MUST complete before any other exchange type, then all IKE_AUTH exchanges MUST complete, and following that any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur in any order. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 5 09:58: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 5F79B3A6774; Fri, 5 Dec 2008 09:58:48 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26003A6774 for ; Fri, 5 Dec 2008 09:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 SdGhMtzsY9mB for ; Fri, 5 Dec 2008 09:58:46 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 38DCF3A63D2 for ; Fri, 5 Dec 2008 09:58:46 -0800 (PST) Received: by qyk4 with SMTP id 4so177597qyk.13 for ; Fri, 05 Dec 2008 09:58:41 -0800 (PST) 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=/mZbVvq9s89qGMAMcoNjF3c7nGp/oKLTti7bJ2khSzA=; b=AEk6HleMeDXQOlU8bTW8F6UKtz3uXS+3hp+y7zf+YD3nmJa/bdBzF06K2MEW2NTR3H yTlqk2Z7x/gI9LAyW2WoavqEzj+xOWox5j3XNyPyJrdLNvxkwe51+YsNNOgikoa4ltpF mO2U4zTgfhSZQ0Q84UpqRgc1hPX1y4NevxN0M= 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=RH18CZ4gegzVQt+LYlhRMTRqTtk5tC7brd7Y8LLI9sxIYvw618InZSXND29ge0jlU7 anY4Gko8sWPECVJz+kYFALfsI/uSZFXKtdBrEe7Hx/Vf+UVRj+IsPZ3l7Nv3VP9pB/VG 5uxlOSvwRRoenNYJhemPSKgmyXeYSRA/Ehatw= Received: by 10.215.41.10 with SMTP id t10mr496934qaj.6.1228499920929; Fri, 05 Dec 2008 09:58:40 -0800 (PST) Received: by 10.214.181.8 with HTTP; Fri, 5 Dec 2008 09:58:40 -0800 (PST) Message-ID: Date: Fri, 5 Dec 2008 09:58:40 -0800 From: "fan zhao" To: "Tero Kivinen" In-Reply-To: <18745.4766.35985.750878@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, Thanks for your reply. Please see below. On Fri, Dec 5, 2008 at 3:38 AM, Tero Kivinen wrote: > fan zhao writes: >> Sorry I did not make myself clear. The first option I listed is the case >> where the client does not want to set up a child SA during the IKE_AUTH. > > There is no such option currently. The SAi1, TSi, and TSr payloads are > NOT OPTIONAL in the IKE_AUTH. I see no point to adding such option, as > if the client does not want to create IPsec SA with the server, why > did he connect in the first place. I thought that the client does not have to create the child_sa during the IKE_AUTH, it can do that after the IKE_AUTH. That is what I meant. I do not intend to add any new option for child sa establishment. > >> If the client wants to do that, it can send the message as described >> in the second option I listed. I listed two options separately, but >> with the redirect during the IKE_AUTH, the SA can be established if the >> client wants to create the child SA and the server does not need to redirect >> the client. > > RFC4306 and ikev2bis documents do not offer such option, so I > naturally assumed you wanted to add that option for special case for > redirect case just in case client does not want to create IPsec SA > because he assumes server will redirect him somewhere else. Sorry for causing confusion. That is not my intention. Please see my clarification above. > Even in > that case the client usually would not have information whether server > will redirect him or not, so he should always try to create IPsec SA > and if server wants to redirect client, then it can refuse creation of > the IPsec SA as it would be teared down immediately when client > disconnects and reconnects to another place. > >> Actually I think the redirect during the IKE_AUTH is similar to >> the redirect during the IKE_SA_INIT with the unicast IPsec gateway, >> with the only difference that is during the IKE_AUTH, the IPSec >> gateway takes not only its load condition but also the ID of the client >> into consideration. > > The reason for doing redirect during IKE_SA_INIT is to avoid server > doing any expensive calculations, thus not making loaded server even > more loaded by doing Diffie-Hellman and signature calculations before > redirecting clients to not so loaded servers. Yes, I understand. > In the IKE_AUTH the > server has already done all those calculations so there is no benefit > for doing it inside the IKE_AUTH compared to separate INFORMATIONAL > exchange. That is where we differ. See more on this below. > >> I agree that the redirect during the informational exchange works in >> both cases. However, if it is more efficient and does not introduce >> much complexity, I do not see why we do not take advantage of >> the already defined REDIRECT payload and use it during the IKE_AUTH. > > It adds yet another mode that needs to be tests. That mode needs to be > tested with all possible authentication combinations (4 + EAP methods I do not see why adding the REDIRECT payload can affect the authentication combination. The authentication of the last IKE_AUTH message is done independently and actually before the processing of the REDIRECT payload. Sure, we should consider all possible cases. Do you find anything broken? > * 2). It needs to be tested with other initial exchange combinations, > i.e. INVALID_KE_PAYLOAD and COOKIE notification cases, it needs to be > tested with MOBIKE extensions, it needs to be tested with NAT > traversal cases, etc. Still I do not see anyhting could be broken. To my best knowledgement, I do not see this can break MOBIKE and NAT traversal either. Can you give me an example? > > Adding one more mode there adds lots of complexity to testing effort > and also makes the already complicated IKE_AUTH state machine even > more complicated. By the testing effort, do you mean the "conditions" in the program or the testing cases? There are many different ways for implementation. >From the protocol perspective, the state transition is simple: after all the processing, specified in the IKEv2 protocol, of the last IKE_AUTH message, then the client processes the REDIRECT payload. > > So I strongly disagree your comment that it "does not introduce much > complexity". I also mostly disagree your comment that it "is more > efficient", as I do not see 2 * 100 byte packets, without any > additinal round trips or similar really that much more efficient that > it would matter. I worry more about the "consequence" of packet reordering/loss. See more on this below. > >> Using one way for multiple purposes in general is good to simplify >> the solution. In this case, I do not see much benefit by excluding >> the REDIRECT payload from the IKE_AUTH. > > Then we disagree on that, as I do see major benefit of not making the > most complex part of the IKEv2 even more complex. > >> I never doubt that there are methods to handle packet reordering and loss. >> Nevertheless, if the REDIRECT payload is carried in the message, >> we do not have to worry about these conditions and consequences. > > Complient IKEv2 implementation MUST be able to handle packet > reordering and loss regardless whether we make this extension or not. > REDIRECT notify does not add any new requirements for this part, it is > already there, and if implementation does not handle packet reordering > or packet loss, it is complectely broken and unsecure. I agree that packet reordering/loss can be handled. But even so, delay and overhead are introduced. As an example, assume that the server sends the last IKE_AUTH message and then a informational message with the REDIRECT payload. If the informational message is lost during the transmission, the server does not know until it receives an IPsec packet from the client again; then the server needs to send another informational message with the REDIRECT payload to the client. In this case, the client would waste a packet and IPsec processing time on this packet, and the client cannot connect to the correct server as soon as possible. This is not good especially when there is existing session between the client and the correct server. So my point is if there is a way to avoid dealing with such situations then it is good to use it. > > I.e. if for example the client would accept CREATE_CHILD_SA before > checking the IKE_AUTH auth payload, that would allow attacker to do > following active attack: > > Initiator Attacker > ------------------------------------------------------------------- > HDR, SAi1, KEi, Ni --> > Attacker makes sure the packets do not ever reach > the intended destination, but instead intercepts > them and responds to them himself. > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > HDR, SK {IDi, [CERT,] [CERTREQ,] > [IDr,] AUTH, SAi2, > TSi, TSr} --> > > As the attacker send the KEr instead of the real > responder, he is able to do Diffie-Hellam > calculations and getting the keying material for > the packet. Now the client would notice the man in > the middle if attacker would send reply to this > IKE_AUTH as attacker would not be able to generate > valid AUTH payload. So he does not send IKE_AUTH at > all, but instead starts new CREATE_CHILD_SA > exchange with client. > > <-- HDR, SK {SA, Ni, TSi, TSr } > > If the client will process the create > child sa before verifing the AUTH > payload of the IKE_AUTH (which > has not been sent) it attacker > can create IPsec SA with Initiator > where the Initiator belives > the other end is valid Responder > > So the Initiator in this case MUST not reply to the new > CREATE_CHILD_SA as otherwise he opens himself to big security hole. > > This is specified in the section 1 of the RFC 4306 (and IKEv2bis): > ---------------------------------------------------------------------- > ... In all cases, > all IKE_SA_INIT exchanges MUST complete before any other exchange > type, then all IKE_AUTH exchanges MUST complete, and following that > any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur > in any order. Thanks for explanation. Yes I agree with you: so in the redirection case, if the REDIRECT payload is received before the last AUTH message (i.e. reordering), the client shoudl reject it.Then the server would have to send another REDIRECT payload to the client again after it realizes that the client is not redirected yet, right? Thanks. Sincerely, fan > -- > kivinen@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From jenny@alppilux.fi Fri Dec 5 16:50:59 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812D53A692E for ; Fri, 5 Dec 2008 16:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.211 X-Spam-Level: X-Spam-Status: No, score=-12.211 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91-NdB5dC3O9 for ; Fri, 5 Dec 2008 16:50:59 -0800 (PST) Received: from c-24-218-68-117.hsd1.ma.comcast.net (c-24-218-68-117.hsd1.ma.comcast.net [24.218.68.117]) by core3.amsl.com (Postfix) with SMTP id 065043A67DB for ; Fri, 5 Dec 2008 16:50:57 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081206005058.065043A67DB@core3.amsl.com> Date: Fri, 5 Dec 2008 16:50:57 -0800 (PST) Click to visit Official Web Site! From ofu@20.freelove.tv Sat Dec 6 10:42:24 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D463A69FE for ; Sat, 6 Dec 2008 10:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.099 X-Spam-Level: X-Spam-Status: No, score=-28.099 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWGGmxO7jrm3 for ; Sat, 6 Dec 2008 10:42:23 -0800 (PST) Received: from ahora.net (unknown [82.100.0.34]) by core3.amsl.com (Postfix) with SMTP id 817953A69CE for ; Sat, 6 Dec 2008 10:42:22 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081206184222.817953A69CE@core3.amsl.com> Date: Sat, 6 Dec 2008 10:42:22 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Sat Dec 6 23:57:26 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5F443A68EF; Sat, 6 Dec 2008 23:57:26 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AED93A68EF for ; Sat, 6 Dec 2008 23:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU2juS0OQ4LC for ; Sat, 6 Dec 2008 23:57:25 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id CDED83A68E5 for ; Sat, 6 Dec 2008 23:57:24 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B1C0429C002; Sun, 7 Dec 2008 09:57:18 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4801929C001; Sun, 7 Dec 2008 09:57:17 +0200 (IST) X-CheckPoint: {493B80FD-10000-88241DC2-7B6} Received: from [91.90.139.118] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB77vHfE025380; Sun, 7 Dec 2008 09:57:17 +0200 (IST) Message-Id: <79AA52D4-58CA-4656-A07A-233E19ED0C2F@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18745.4766.35985.750878@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 7 Dec 2008 09:44:46 +0200 References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Dec 5, 2008, at 1:38 PM, Tero Kivinen wrote: > fan zhao writes: >> Sorry I did not make myself clear. The first option I listed is the >> case >> where the client does not want to set up a child SA during the >> IKE_AUTH. > > There is no such option currently. The SAi1, TSi, and TSr payloads are > NOT OPTIONAL in the IKE_AUTH. I see no point to adding such option, as > if the client does not want to create IPsec SA with the server, why > did he connect in the first place. This question comes up every few months. Connecting (setting up an IKE SA) involves user interaction, and for clients it is user-initiated rather than traffic-initiated. When the user clicks the "connect" button, the client has no way of knowing what traffic it is going to protect. If the policy at the RA gateway is to have an IPsec SA for each pair of hosts, there is no way to determine which SA to setup initially. Later, when the IMAP client contacts the IMAP server, or the browser contacts the internal web site, it makes sense to set up SAs for these addresses. With IKEv1 clients, we had the "connect" button do phase 1 (Main Mode and optionally XAuth) and then the Quick Mode was traffic-initiated. With IKEv2, although you don't have any traffic, you have to set up some kind of IPsec SA, which may never be used. One was that is suggested by RFC 4306 is for the client to offer a global selector for the entire Internet, and then the gateway narrows it down to the encryption domain. But if for implementation reasons it needs to be further narrowed down (for example, either the client or the gateway can only work with single ranges per SA and would send the SINGLE_PAIR_REQUIRED notification), the first SA may be a dummy. I know the current RFC does not allow creating only an IKE SA, and that we're not going to add such an option to the -bis, but I believe that it would make the whole client thing more sensible. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Dec 7 07:09: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 A778D3A693F; Sun, 7 Dec 2008 07:09:30 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 769053A6940 for ; Sun, 7 Dec 2008 07:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-9WkpE2sIuI for ; Sun, 7 Dec 2008 07:09:26 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id C40EE3A68F7 for ; Sun, 7 Dec 2008 07:09:25 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 8386929C002; Sun, 7 Dec 2008 17:09:19 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 72E5F2004D6 for ; Sun, 7 Dec 2008 17:09:18 +0200 (IST) X-CheckPoint: {493BE63C-10002-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB7F9HfE004623 for ; Sun, 7 Dec 2008 17:09:18 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 7 Dec 2008 17:09:17 +0200 From: Yaron Sheffer To: IPsecme WG Date: Sun, 7 Dec 2008 17:09:17 +0200 Thread-Topic: IKEv2-bis issues - opening the discussion Thread-Index: AclYZEMDrT/XCYkmRyeeyK8fmyJ2+A== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950174@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] IKEv2-bis issues - opening the discussion 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="===============1138043128==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1138043128== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0065_01C95877.9B1ECF90" ------=_NextPart_000_0065_01C95877.9B1ECF90 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0066_01C95877.9B1ECF90" ------=_NextPart_001_0066_01C95877.9B1ECF90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Many of the open issues were discussed in Minneapolis. I would like to discuss them on the list to reach WG consensus. The next few messages will briefly discuss each issue and mention the "room's opinion" from Minneapolis. Please respond if you disagree. In this particular case, silence will be treated as consent. Note: the authors are requested to add the room's opinion into each issue when it is closed. Thanks, Yaron ------=_NextPart_001_0066_01C95877.9B1ECF90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Many of the open issues were discussed in Minneapolis. I would like to discuss = them on the list to reach WG consensus. The next few messages will briefly = discuss each issue and mention the “room’s opinion” from Minneapolis. Please respond if you = disagree.

 

In this particular case, silence will be treated as = consent.

 

Note: the authors are requested to add the = room’s opinion into each issue when it is closed.

 

Thanks,

         =    Yaron

------=_NextPart_001_0066_01C95877.9B1ECF90-- ------=_NextPart_000_0065_01C95877.9B1ECF90 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwNzEyMjUwOFowIwYJKoZIhvcNAQkEMRYEFMb8/inRcgys g1L6jMhwazY1aRrpMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA h0mPLsdFsf2syWl7x5zYtJbfsUBZhqMjFkjGaNvsGIaTGIc1MfOSaY47VH8yUIfD4DiyT6c2Tlc+ IYmIR4IUjpd+R+5Ef97uEMWW/H+hFj/LfVXOX86YiIMB42VnjIdQayKeHaLbqlNkeMld0OGfvrdQ 9GwNRwYTTEovQJJprWdObuw9Nd8KXnJtmdTlXNXIqNX/0qU2u/9ubWB4bPI79eGorkjymI+8QD0+ O0mvSds3AKWc7MMmGTjsrbOpYa88QRyla0WZ4g0ZTWTKWEZVGxGMljcZPnj73210OXdjPhNgszZS /1+jZ9SWWOraUnNEKjPkL809BRJAHJZfLFVAjAAAAAAAAA== ------=_NextPart_000_0065_01C95877.9B1ECF90-- Email secured by Check Point --===============1138043128== 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 --===============1138043128==-- Email secured by Check Point From ipsec-bounces@ietf.org Sun Dec 7 07:09: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 1A23D3A6953; Sun, 7 Dec 2008 07:09:32 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5235D3A68F7 for ; Sun, 7 Dec 2008 07:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0E+rDLBCu3JX for ; Sun, 7 Dec 2008 07:09:29 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id F17333A693F for ; Sun, 7 Dec 2008 07:09:28 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 96E8B29C003; Sun, 7 Dec 2008 17:09:23 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7E6182004D6 for ; Sun, 7 Dec 2008 17:09:22 +0200 (IST) X-CheckPoint: {493BE640-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB7F9LfE004654 for ; Sun, 7 Dec 2008 17:09:22 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 7 Dec 2008 17:09:21 +0200 From: Yaron Sheffer To: IPsecme WG Date: Sun, 7 Dec 2008 17:09:18 +0200 Thread-Topic: Issue #50: Behavior when KE payload not included Thread-Index: AclYZNJpZlDOntmJSoq8uj64UXeYsg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950175@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] Issue #50: Behavior when KE payload not included 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="===============1805107861==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1805107861== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002F_01C95875.95F921C0" ------=_NextPart_000_002F_01C95875.95F921C0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0030_01C95875.95F921C0" ------=_NextPart_001_0030_01C95875.95F921C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 1.3.2: why is KE a SHOULD, not a MUST? How is the SA generated if it is omitted? The room: IKE SA rekey without DH is almost pointless, better to require KE payload. "SHOULD" may have been inherited from CREATE_CHILD text. Changing to "MUST" is likely course of action. ------=_NextPart_001_0030_01C95875.95F921C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1.3.2: why is KE a SHOULD, not a MUST? How is the SA generated = if it is omitted?

 

The room: IKE SA rekey without DH is almost =
pointless, better to require KE
payload.  "SHOULD" may have =
been inherited from CREATE_CHILD =
text.
Changing =
to "MUST" is likely course of =
action.

 

------=_NextPart_001_0030_01C95875.95F921C0-- ------=_NextPart_000_002F_01C95875.95F921C0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwNzEyMTA0MFowIwYJKoZIhvcNAQkEMRYEFDtFvV8vJWIp SvBHX5nPncDxkXrqMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Q7lxQfNjmimkHFenan5mVAH16jpWUSOfdaK1fsOoUUfu5OJO5GRxJuCdYsosLZSKlcBuQ534H8Kl wLBN+oroyh5oMRs4Ruqee8JoxYnfAp8NRwtwTJZh6IStRYZwV/S7or4ovXMcExxH1jnttCouTfsB U69M66cenc5NF3nDsXw5r2/zqVSm7eal2cXmwFHkqk8I8CmAIn7C4pJ3OpsH0PY0DZzErmqW3fNI Z7kJlzYKG9uunS45j5fNU5VbMQv4A4+3llbJA8hkKtmNbvwHHIH2XaJ7FKVp6yYs+zChRI4gtPdR MUAiyZYhtLBde8WK0a5cen478+Tv/JkSTKojNwAAAAAAAA== ------=_NextPart_000_002F_01C95875.95F921C0-- Email secured by Check Point --===============1805107861== 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 --===============1805107861==-- Email secured by Check Point From ipsec-bounces@ietf.org Sun Dec 7 07:09: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 AAB063A6983; Sun, 7 Dec 2008 07:09:33 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099F43A6983 for ; Sun, 7 Dec 2008 07:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUVFragc-eyT for ; Sun, 7 Dec 2008 07:09:32 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 931B43A694E for ; Sun, 7 Dec 2008 07:09:31 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EEE2729C008; Sun, 7 Dec 2008 17:09:25 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7BDEC29C002 for ; Sun, 7 Dec 2008 17:09:23 +0200 (IST) X-CheckPoint: {493BE641-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB7F9MfE004659 for ; Sun, 7 Dec 2008 17:09:23 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 7 Dec 2008 17:09:22 +0200 From: Yaron Sheffer To: IPsecme WG Date: Sun, 7 Dec 2008 17:09:21 +0200 Thread-Topic: #46: Exchange type for INVALID_IKE_SPI outside of an IKE_SA Thread-Index: AclYZScTgk1Vf91RRWGSglFr0gH/Kw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950176@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] #46: Exchange type for INVALID_IKE_SPI outside of an IKE_SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0573302931==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0573302931== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0037_01C95875.EAA883A0" ------=_NextPart_000_0037_01C95875.EAA883A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0038_01C95875.EAA883A0" ------=_NextPart_001_0038_01C95875.EAA883A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For the one-way INVALID_IKE_SPI notification described in RFC 4306 section 1.5, it is unclear to me what the Exchange Type should be in the IKE header. Should it be 37 (INFORMATIONAL) or should it be copied from the request that contained the unrecognized SPI? The room: Kero Tivinen doesn't care as long as there is *exactly* one answer. Comment made that copying this [from the request] is implied by existing text [i.e. need to clarify]. ------=_NextPart_001_0038_01C95875.EAA883A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For the one-way INVALID_IKE_SPI notification described in RFC 4306 section 1.5, it = is unclear to me what the Exchange Type should be in the IKE header. =  Should it be 37 (INFORMATIONAL) or should it be copied from the request that = contained the unrecognized SPI?

 

The room: Kero Tivinen doesn't care as long =
as there is *exactly* one =
answer.
Comment =
made that copying this [from the request] is implied by existing text =
[i.e. need to clarify].
------=_NextPart_001_0038_01C95875.EAA883A0-- ------=_NextPart_000_0037_01C95875.EAA883A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwNzEyMTMwMlowIwYJKoZIhvcNAQkEMRYEFOd0UI2I86G5 Qt0Tn9rSKIYaKGJLMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA LXVQ4CyWD7sdWp5u2M/+9uFhP2fSnGoH3TB+u3JsKqAH8xDREyEpwXpPX6H2b26inf7CmES9hmQZ J2ZAUWzWOfISayFL+ULAOypSzhfd2wSF9RUuohR6zUr15GMy8PXMkdjk8nSzB3xI/Jy0NwItIwST szl6U2jwU1JFWtykMtbnIO5M6mXZDb16hGJN23nvZB7+IavGp+dNmmPtGQpXacDhcetaMx858Kf/ n7IY2HcFnh1thTl0PsASzg6Wno2jgH2SSNePce/UT9LRNTdT8aYlQzcnuOfXhZizaS01Dq7WCGzG MAu8vexxWaM68ruso/wbqqpsrNgv/5KGoefb9wAAAAAAAA== ------=_NextPart_000_0037_01C95875.EAA883A0-- Email secured by Check Point --===============0573302931== 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 --===============0573302931==-- Email secured by Check Point From ipsec-bounces@ietf.org Sun Dec 7 07:09: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 205A83A698B; Sun, 7 Dec 2008 07:09:41 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD73F3A698B for ; Sun, 7 Dec 2008 07:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WKLADf8VBcp for ; Sun, 7 Dec 2008 07:09:34 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E61C63A697B for ; Sun, 7 Dec 2008 07:09:32 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6D41229C002; Sun, 7 Dec 2008 17:09:27 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 02DD0200DE4 for ; Sun, 7 Dec 2008 17:09:24 +0200 (IST) X-CheckPoint: {493BE641-10003-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB7F9MfF004659 for ; Sun, 7 Dec 2008 17:09:23 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 7 Dec 2008 17:09:22 +0200 From: Yaron Sheffer To: IPsecme WG Date: Sun, 7 Dec 2008 17:09:21 +0200 Thread-Topic: #9: Notification when creation of CHILD_SA fails Thread-Index: AclYZkO+vyj9sNgASHmSnRO9S49ryA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950177@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] #9: Notification when creation of CHILD_SA fails 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="===============0519460113==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0519460113== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_003F_01C95877.07514950" ------=_NextPart_000_003F_01C95877.07514950 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0040_01C95877.07514950" ------=_NextPart_001_0040_01C95877.07514950 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > same IP address. The initiator begins negotiation of a CHILD_SA > using the SAi2 payload. The final fields (starting with SAi2) are > described in the description of the CREATE_CHILD_SA exchange. > > <-- HDR, SK {IDr, [CERT,] AUTH, > SAr2, TSi, TSr} > > The responder asserts its identity with the IDr payload, optionally > sends one or more certificates (again with the certificate containing > the public key used to verify AUTH listed first), authenticates its > identity and protects the integrity of the second message with the > AUTH payload, and completes negotiation of a CHILD_SA with the > additional fields described below in the CREATE_CHILD_SA exchange. > > The recipients of messages 3 and 4 MUST verify that all signatures > and MACs are computed correctly and that the names in the ID payloads > correspond to the keys used to generate the AUTH payload. > > {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange > fails for some reason, the IKE_SA is still created as usual. The > list of responses in the IKE_AUTH exchange that do not prevent an > IKE_SA from being set up include at least the following: > NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, > INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. Tero: In the case of the that kind of failure the return packet will then be without the SAr2, Tsi, and TSr, i.e.: <-- HDR, SK {IDr, [CERT,] AUTH, N(error_for_child_sa)} If the authentication fails in such ways that the entries cannot create IKE SA (authentication failure or similar), then the response will be unencrypted, unauthenticated notify. There is no point of sending the notify encrypted and integrity protected, as it is not authenticated (as initiator and responder have not yet verified the AUTH payloads): <-- HDR, N(error_for_ike_sa) The initiator receiving such reply MUST NOT immediately stop the SA creation, but it should still retransmit the message few times, in case that error notify was forgery and the real responder will reply with valid reply. It can use the recipient of such message as a hint to tell that authentication failed, thus it can shorten the retransmission timers from few minutes down to few tens of seconds. Paul: Not done. This is interesting, but should be discussed on the list. Room: Scenario: IKE SA creation proceeds immediately to first CHILD SA creation. What if CHILD SA can't be created, but IKE SA is ok? Text should make it clear that failure of CHILD SA creation should not tear down IKE SA (e.g., avoids losing work to create the IKE SA based on guessing wrong about a child traffic selector). Yaron: seems to me the ticket discusses one thing (IKE SA creation fails because of bad authentication), while the room's discussion is about a different thing (IKE SA successful). Comments on the original ticket are welcome. ------=_NextPart_001_0040_01C95877.07514950 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>     same IP address.  = The initiator begins negotiation of a CHILD_SA

>     using the SAi2 = payload.  The final fields (starting with SAi2) are

>     described in the = description of the CREATE_CHILD_SA exchange.

> 

>        &n= bsp;           &nb= sp;           &nbs= p; <--  HDR, SK {IDr, [CERT,] AUTH,

>        &n= bsp;           &nb= sp;           &nbs= p;          SAr2, TSi, = TSr}

> 

>     The responder asserts = its identity with the IDr payload, optionally

>     sends one or more = certificates (again with the certificate containing

>     the public key used to = verify AUTH listed first), authenticates its

>     identity and protects = the integrity of the second message with the

>     AUTH payload, and = completes negotiation of a CHILD_SA with the

>     additional fields = described below in the CREATE_CHILD_SA exchange.

> 

>     The recipients of = messages 3 and 4 MUST verify that all signatures

>     and MACs are computed = correctly and that the names in the ID payloads

>     correspond to the keys = used to generate the AUTH payload.

> 

>     {{ Clarif-4.2}} If = creating the CHILD_SA during the IKE_AUTH exchange

>     fails for some reason, = the IKE_SA is still created as usual.  The

>     list of responses in the = IKE_AUTH exchange that do not prevent an

>     IKE_SA from being set up = include at least the following:

>     NO_PROPOSAL_CHOSEN, = TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,

>     = INTERNAL_ADDRESS_FAILURE, and = FAILED_CP_REQUIRED.

 

Tero: In the case of the that kind of failure the = return packet will then be

without the SAr2, Tsi, and TSr, = i.e.:

 

         =             &= nbsp;           = <--  HDR, SK {IDr, [CERT,] AUTH,

         =             &= nbsp;           &n= bsp;        = N(error_for_child_sa)}

 

If the authentication fails in such ways that the = entries cannot

create IKE SA (authentication failure or similar), = then the response

will be unencrypted, unauthenticated notify. There is = no point of

sending the notify encrypted and integrity protected, = as it is not

authenticated (as initiator and responder have not = yet verified the

AUTH payloads):

 

         =          =             &= nbsp;  <--  HDR, = N(error_for_ike_sa)

 

The initiator receiving such reply MUST NOT = immediately stop the SA

creation, but it should still retransmit the message = few times, in

case that error notify was forgery and the real = responder will reply

with valid reply. It can use the recipient of such = message as a hint

to tell that authentication failed, thus it can = shorten the

retransmission timers from few minutes down to few = tens of seconds.

 

Paul: Not done. This is interesting, but should be = discussed on the list.

 

Room: =
Scenario: IKE SA creation proceeds immediately to first =
CHILD SA creation.  What if CHILD SA can't be created, but IKE SA =
is ok?  Text should make it clear that failure of CHILD SA creation =
should not tear down IKE SA (e.g., avoids losing work to create the IKE =
SA based on guessing wrong about a child traffic =
selector).

 

Yaron: seems to me the ticket discusses one thing = (IKE SA creation fails because of bad authentication), while the room’s = discussion is about a different thing (IKE SA successful). Comments on the original ticket are = welcome.

------=_NextPart_001_0040_01C95877.07514950-- ------=_NextPart_000_003F_01C95877.07514950 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwNzEyMjEwMFowIwYJKoZIhvcNAQkEMRYEFCdYJ+XpJmCT hBfQ3Y20uUMNNkXWMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA BgFipw56GC0wsSkWkbtRNbqzhnfwGtQPj5f14vhSLCK6vB2ywt+OyhVabfmApn+18Byzz1GEv7LC 29v97TR6TbX3ChCfXwtfSvINVYlrwFSoVQt0UodXUC4nwbyI9Kq+Li1P3MOho5anEzn713YriOEh DguGFwU1FfQdVY1nYS0WYg7g4UZqvjXaYeeh2/TJUUCCWSF3BiJU6q+MQC716P0lj9acnXmBOWpZ Z66bC7V3JHvdzRW5kMUh9Gv1Ml5KC+mv9WDpD6j6wheul9lZKmPk5MDQDj7KHIjDTlKtOvwYyXvy b5dC+QKTIR3cUK39rAxVl2RH+fEg3o0som/QRgAAAAAAAA== ------=_NextPart_000_003F_01C95877.07514950-- Email secured by Check Point --===============0519460113== 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 --===============0519460113==-- Email secured by Check Point From ipsec-bounces@ietf.org Sun Dec 7 07:41:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 670923A6944; Sun, 7 Dec 2008 07:41:17 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1ED83A6944 for ; Sun, 7 Dec 2008 07:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CG+5HzHjA2iA for ; Sun, 7 Dec 2008 07:41:13 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 253853A693B for ; Sun, 7 Dec 2008 07:41:12 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D401029C002; Sun, 7 Dec 2008 17:09:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6AFEA29C003 for ; Sun, 7 Dec 2008 17:09:25 +0200 (IST) X-CheckPoint: {493BE643-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB7F9MfJ004659 for ; Sun, 7 Dec 2008 17:09:25 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 7 Dec 2008 17:09:23 +0200 From: Yaron Sheffer To: IPsecme WG Date: Sun, 7 Dec 2008 17:09:22 +0200 Thread-Topic: #56: Address and config values lifetime Thread-Index: AclYaS9SN7JH4XMtSd+uqtsXc4vFJA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017B@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] #56: Address and config values lifetime 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="===============0535600733==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0535600733== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_007D_01C95879.F2E48740" ------=_NextPart_000_007D_01C95879.F2E48740 Content-Type: multipart/alternative; boundary="----=_NextPart_001_007E_01C95879.F2E48740" ------=_NextPart_001_007E_01C95879.F2E48740 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yaron: 2.19: INTERNAL_ADDRESS_EXPIRY is gone, but shouldn't we specify what the gateway should do if the address lease expires? On a related note, the section does not specify the lifetime of the configuration values, i.e. should they be renewed by the next IKE SA rekey, or reauthentication, or never? Room: [A gateway] SHOULD keep addresses alive when possible. What if not possible (e.g., DHCP refuses to renew address, or changes it)? May need to actually delete the IKE SA in order to get the client to notice that it has a problem - this also cleans up all the associated state (e.g., traffic selectors may not survive). Might want to introduce a notification that the SA is about to be deleted (may also apply to an EAP authentication that has to be renewed every x hours). Clients already have to expect IKE SA to be torn down at any time for any reason. Yaron: I read all the above as saying that the lifetime of the configuration params is identical to the IKE SA's lifetime. Let's clarify it. ------=_NextPart_001_007E_01C95879.F2E48740 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ------=_NextPart_001_007E_01C95879.F2E48740-- ------=_NextPart_000_007D_01C95879.F2E48740 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwNzEyNDE1NFowIwYJKoZIhvcNAQkEMRYEFOHeDtkRpwUM 5Rd1SVNG3j+yqv1xMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA aXyc8RPF067TSUgc/9dU6xyI8ueuHDkD1wOXWIp77KGIh00qwMbe3rRc07NfpJAc4V88KbEw1DAz WrdVZLbqGMSEgusp/KCIboV5TBpd6mOgs017prMJmRpz1a6BdToh4dhSP6s6eyziBpOFrYPnj/bs 3DHVLx4gPhV15Zp5Eci6UeckUMumANpll0Pqc2rxrLmxGIkECHV7abvM3jTQ/OaHaJwPpEVdGJ5f IRd/yovDClbCfo8xLAtEWjNF2L+avGovFxclnV25FX23XvAzMRUtsYDxCEL804IQweInjxLLmcoO LkjVlh5/Tm/BDd/j6yziSnbvmvGj2t451zZUuwAAAAAAAA== ------=_NextPart_000_007D_01C95879.F2E48740-- Email secured by Check Point --===============0535600733== 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 --===============0535600733==-- Email secured by Check Point From ipsec-bounces@ietf.org Sun Dec 7 08:14:35 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B7773A6998; Sun, 7 Dec 2008 08:14:35 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88E853A6998 for ; Sun, 7 Dec 2008 08:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.515 X-Spam-Level: X-Spam-Status: No, score=-1.515 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 chV59AWdZAYa for ; Sun, 7 Dec 2008 08:14:33 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3D6F23A6833 for ; Sun, 7 Dec 2008 08:14:32 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EBF5429C004; Sun, 7 Dec 2008 17:09:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0FEB829C006 for ; Sun, 7 Dec 2008 17:09:25 +0200 (IST) X-CheckPoint: {493BE642-10004-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB7F9MfI004659 for ; Sun, 7 Dec 2008 17:09:24 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 7 Dec 2008 17:09:23 +0200 From: Yaron Sheffer To: IPsecme WG Date: Sun, 7 Dec 2008 17:09:22 +0200 Thread-Topic: #40: Floating to port 4500 'by default', and use of UDP when no NAT detected Thread-Index: AclYaIKCPF2HRxMtR56E1h+yIRF3LQ== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017A@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] #40: Floating to port 4500 'by default', and use of UDP when no NAT detected 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="===============0639645844==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0639645844== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0075_01C95879.4616DB80" ------=_NextPart_000_0075_01C95879.4616DB80 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0076_01C95879.4616DB80" ------=_NextPart_001_0076_01C95879.4616DB80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tero: We should also list whether it is allowed to float to port 4500 even when no NAT is detected (I think the answer is yes). And even if we float to port 4500, the UDP encapsulation should not be enabled or expected unless NAT between is really detected. Discussion: IKEv1 NAT traversal is a mess, but widely deployed as inter-vendor interoperability is not widely relied upon. mobike floats to port #4500 if the implementation supports NAT-T, even if it doesn't detect a NAT. Yaron Sheffer: if floating to port #4500, do UDP, even if there's no NAT detected. [Yaron: I wish to retract this opinion, given that reality is different. This should not be taken as a precedent.] Tero Kivinen: mobike only turns on UDP if it finds a NAT, but always floats to port #4500 if it has NAT-T support. Greg Lebovitz: May need to do this with asymmetric paths, one of which is not NAT'ed (e.g., multiple exit points). UDP encap is prohibited on port #500. Ok to have a port #4500-only implementation (e.g., client that expects NATs). UDP encap can get IKEv2 through a firewall that only allows UDP and TCP. This is a reason to always use UDP encap, even if no NAT detected. This has to start on port #4500. Summary of open questions: 1. Do we allow to float immediately into port 4500, e.g. to have port 4500-only originators? 2. Do we always require UDP encapsulation when using port 4500 (the scope here does NOT include MOBIKE). 3. Do we care about asymmetric paths, where NAT only happens in one direction? If so, what is the correct behavior? ------=_NextPart_001_0076_01C95879.4616DB80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tero: We should also list whether it is allowed to float to port 4500 even when no NAT is detected (I think the = answer is yes). And even if we float to port 4500, the UDP encapsulation should = not be enabled or expected unless NAT between is really = detected.

 

Discussion: IKEv1 NAT traversal is a mess, =
but widely deployed as inter-vendor interoperability is not widely =
relied upon.  mobike floats to port #4500 if the implementation =
supports NAT-T, even if it doesn't detect a =
NAT.
 
Yaron Sheffer: =
if floating to port #4500, do UDP, even if there's no NAT detected. =
[Yaron: I wish to retract this opinion, given that reality is different. =
This should not be taken as a precedent.]
 
Tero =
Kivinen: mobike only turns on UDP if it finds a NAT, but always floats =
to port #4500 if it has NAT-T =
support.
 
Greg =
Lebovitz: May need to do this with asymmetric paths, one of which is not =
NAT'ed (e.g., multiple exit =
points).
 
UDP encap =
is prohibited on port #500.
 
Ok to =
have a port #4500-only implementation (e.g., client that =
expects
        =
NATs).
 
UDP encap =
can get IKEv2 through a firewall that only allows UDP and =
TCP.
        =
This is a reason to always use UDP encap, even if no NAT =
detected.
        =
This has to start on port #4500.

 

Summary of open = questions:

 

  1. Do we allow to float = immediately into port 4500, e.g. to have port 4500-only = originators?
  2. Do we always require = UDP encapsulation when using port 4500 (the scope here does NOT include = MOBIKE).
  3. Do we care about = asymmetric paths, where NAT only happens in one direction? If so, what is the = correct behavior?
------=_NextPart_001_0076_01C95879.4616DB80-- ------=_NextPart_000_0075_01C95879.4616DB80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwNzEyMzcwNFowIwYJKoZIhvcNAQkEMRYEFEoEiIO0sQSO zKBMQTeLy/+kc23uMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Szxiq8j62Czqw0x7vXUf5zcL0Is+a7neYPZAQWQ9m9HPzpr3qEsdTj7zRVdWAe3M3meumq1UxXKH 7ukbYseTeXT9hrdpf16phMUdkglwEI4r/16rODvDMk1taw03fMZ2pntqDVg5N5S2kzRKUa78KAwc R4UhuuxSDNZH3mF0fEY/J68xuCdyThb3BXvZlSeLvYrn2bdQn1yBKI+Kx2cqyiOYQZX5GT5SYRwO 2XqeOzwVRy1eHCQSIumlTSRD00D6+cmnULA1/HfQbx1dgnqMFuIESezI6CiB3Kk3Mu5cvEOQzMbO wDvlIKjdq8QdAVr8ms4FjPL3zNC/cn4QFbYmEgAAAAAAAA== ------=_NextPart_000_0075_01C95879.4616DB80-- Email secured by Check Point --===============0639645844== 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 --===============0639645844==-- Email secured by Check Point From ipsec-bounces@ietf.org Sun Dec 7 08:34:55 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A36733A69C2; Sun, 7 Dec 2008 08:34:55 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 689E83A69C2 for ; Sun, 7 Dec 2008 08:34:53 -0800 (PST) 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 0-ZXPAq2ma8g for ; Sun, 7 Dec 2008 08:34:52 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 1362B3A677E for ; Sun, 7 Dec 2008 08:34:51 -0800 (PST) Received: from [10.20.30.163] (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 mB7GYXFj095854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Dec 2008 09:34:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <79AA52D4-58CA-4656-A07A-233E19ED0C2F@checkpoint.com> References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> <79AA52D4-58CA-4656-A07A-233E19ED0C2F@checkpoint.com> Date: Sun, 7 Dec 2008 08:34:32 -0800 To: Yoav Nir , Tero Kivinen From: Paul Hoffman Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 9:44 AM +0200 12/7/08, Yoav Nir wrote: >With IKEv2, although you don't have any traffic, you have to set up some kind of IPsec SA, which may never be used. One was that is suggested by RFC 4306 is for the client to offer a global selector for the entire Internet, and then the gateway narrows it down to the encryption domain. But if for implementation reasons it needs to be further narrowed down (for example, either the client or the gateway can only work with single ranges per SA and would send the SINGLE_PAIR_REQUIRED notification), the first SA may be a dummy. This was discussed a few times, and the general agreement was that the slight cost of a dummy SA was worth the benefit of of clarity of the spec. Personally, I think that having the remote access client always have a tunnel to an internal DNS server, even if there was no other tunnel, is a useful thing. >I know the current RFC does not allow creating only an IKE SA, and that we're not going to add such an option to the -bis, but I believe that it would make the whole client thing more sensible. We're not opening that up in IKEv2bis, so let's drop that thread. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From m.flaczeyk@agencjavectra.pl Sun Dec 7 09:12:51 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7EB23A6973 for ; Sun, 7 Dec 2008 09:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.628 X-Spam-Level: X-Spam-Status: No, score=-11.628 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBYg8fz7wlj5 for ; Sun, 7 Dec 2008 09:12:51 -0800 (PST) Received: from HSI-KBW-078-043-194-032.hsi4.kabel-badenwuerttemberg.de (HSI-KBW-078-043-194-032.hsi4.kabel-badenwuerttemberg.de [78.43.194.32]) by core3.amsl.com (Postfix) with SMTP id C06383A6868 for ; Sun, 7 Dec 2008 09:12:49 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207171250.C06383A6868@core3.amsl.com> Date: Sun, 7 Dec 2008 09:12:49 -0800 (PST) Having trouble viewing this email? Click here! From ipsec-bounces@ietf.org Sun Dec 7 09:21: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 8BF7A3A69CE; Sun, 7 Dec 2008 09:21:15 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 122B93A69C9 for ; Sun, 7 Dec 2008 09:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.098, 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 pxYMJKQnSrwU for ; Sun, 7 Dec 2008 09:21:13 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 460333A6989 for ; Sun, 7 Dec 2008 09:21:12 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3780729C00A; Sun, 7 Dec 2008 17:09:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A689D29C005 for ; Sun, 7 Dec 2008 17:09:24 +0200 (IST) X-CheckPoint: {493BE642-10002-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB7F9MfH004659 for ; Sun, 7 Dec 2008 17:09:24 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 7 Dec 2008 17:09:23 +0200 From: Yaron Sheffer To: IPsecme WG Date: Sun, 7 Dec 2008 17:09:22 +0200 Thread-Topic: #22: Add section on simultaneous IKE SA rekey Thread-Index: AclYZyE+dHKex+GiQ2Gs6K2KHAjszg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950179@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] #22: Add section on simultaneous IKE SA rekey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0603569210==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0603569210== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_006D_01C95877.E4CECB40" ------=_NextPart_000_006D_01C95877.E4CECB40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_006E_01C95877.E4CECB40" ------=_NextPart_001_006E_01C95877.E4CECB40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tero: Instead of simultaneous CHILD_SA rekeying, there should be section of simultaneous IKE SA rekeying. Simultaneous CHILD_SA rekeying just results few extra SAs that will disappear after next rekeys (at worst there will be 2 SA pairs, but all others will be deleted instead of being rekeyed as they are not used. The simultaneous IKE SA rekeying is much more important case to get correct, as both ends MUST agree on which IKE SA survive, as otherwise they will move the CHILD SA to wrong IKE SA and their state is completely messed up after that. This section should also explain that even if the simultaneous rekeying of IKE SA is noticed only AFTER the whole rekeying is already finished, both ends MUST still correctly detect it and act based on the fact which IKE SA will survive. This means that the old IKE SA should not be deleted too quickly after the IKE SA rekey finished, just in case there happened to be simultaneous rekey in progress. The one doing the delete should wait at least few minutes before deleting the old IKE SA, so it can be sure that other end does not have simultaneous rekey going on the IKE SA. Room: This (simultaneous IKE SA rekey) is not an easy situation to create for testing, but it does happen. Both sides need to agree on which SA survives, otherwise both IKE SAs could be torn down, losing everything. There is some text on this, but it needs attention, particularly for the case in which both IKE SAs get created. Also need text on how to recognize simultaneous IKE SA rekey (e.g., if packets lost during simultaneous rekey). Tero believes that the clarifications document covers this, but that text needs to be checked. ------=_NextPart_001_006E_01C95877.E4CECB40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tero: Instead of simultaneous CHILD_SA rekeying, there should be section of simultaneous IKE SA rekeying. = Simultaneous CHILD_SA rekeying just results few extra SAs that will disappear after = next rekeys (at worst there will be 2 SA pairs, but all others will be = deleted instead of being rekeyed as they are not used. The simultaneous IKE SA = rekeying is much more important case to get correct, as both ends MUST agree on = which IKE SA survive, as otherwise they will move the CHILD SA to wrong IKE SA = and their state is completely messed up after that. This section should also explain that even if the simultaneous rekeying of IKE SA is noticed only = AFTER the whole rekeying is already finished, both ends MUST still correctly = detect it and act based on the fact which IKE SA will survive. This means that = the old IKE SA should not be deleted too quickly after the IKE SA rekey = finished, just in case there happened to be simultaneous rekey in progress. The one = doing the delete should wait at least few minutes before deleting the old IKE SA, = so it can be sure that other end does not have simultaneous rekey going on the = IKE SA.

 

Room: This (simultaneous IKE SA rekey) is not =
an easy situation to create for testing, but it does happen.  Both =
sides need to agree on which SA survives, otherwise both IKE SAs could =
be torn down, losing everything. There is some text on this, but it =
needs attention, particularly for the case in which both IKE SAs get =
created.  Also need text on how to recognize simultaneous IKE SA =
rekey (e.g., if packets lost during simultaneous rekey).  Tero =
believes that the clarifications document covers this, but that text =
needs to be checked.

 

------=_NextPart_001_006E_01C95877.E4CECB40-- ------=_NextPart_000_006D_01C95877.E4CECB40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwNzEyMjcxMVowIwYJKoZIhvcNAQkEMRYEFGymoRru1yN9 q0LvTkOzxcFC9gTsMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA XcB0vFE+Gl9UuYYBZqNeYPc30qp222McIJ0rA4wPlS42SxdKSdKm8Aor0wdYheeJfmXBgcxQViex PTlTHQO2I4D6o28pCA+avr6reUnuloYBTyqypXPtqLvgwMKRTUhOcRrYNa6DKys/zvCohA14kovI 6VmEHo8w5fOABcdAXGjN1fByjdxvdT8UINvTTPu7g6Zist0+59MRo+v7P8X8hm26ZJDBzeYuru51 Dh9dEb5faYkZk7W7Udex3i+r/EAGkVqHTT3rV8ccGPiZNnjAnHrZ3DLBbh7aAyO1BKcIvqTroGFw EF0LvsFN+Iy7f5n4ZLeiTj9ttPTWv5hAKuxdoAAAAAAAAA== ------=_NextPart_000_006D_01C95877.E4CECB40-- Email secured by Check Point --===============0603569210== 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 --===============0603569210==-- Email secured by Check Point From ipsec-bounces@ietf.org Sun Dec 7 09:21: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 0BAD928C0CF; Sun, 7 Dec 2008 09:21:18 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F09D28C0CF for ; Sun, 7 Dec 2008 09:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.090, 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 tXdr6poNOcSm for ; Sun, 7 Dec 2008 09:21:15 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 038313A6989 for ; Sun, 7 Dec 2008 09:21:15 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0271729C008; Sun, 7 Dec 2008 17:09:28 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 5CB9E29C004 for ; Sun, 7 Dec 2008 17:09:24 +0200 (IST) X-CheckPoint: {493BE642-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB7F9MfG004659 for ; Sun, 7 Dec 2008 17:09:24 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 7 Dec 2008 17:09:22 +0200 From: Yaron Sheffer To: IPsecme WG Date: Sun, 7 Dec 2008 17:09:22 +0200 Thread-Topic: #65: Original initiator and rekeying Thread-Index: AclYZpSWZUQHfSuVRjaTnhbNQeu4cw== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950178@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] #65: Original initiator and rekeying 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="===============1565373495==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1565373495== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0047_01C95877.5823BF20" ------=_NextPart_000_0047_01C95877.5823BF20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0048_01C95877.5823BF20" ------=_NextPart_001_0048_01C95877.5823BF20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tero: The actual text in the rfc4306 or clarifications does not exactly specify when the message ids are reset and when the roles are changed. For me it was clear that of course the old IKE SA uses the old roles and old message IDs as otherwise it could not work at all, and the new IKE SA created by rekeying IKE SA will use the new message ID starting from 0, and new roles of the original initiator and responder (i.e. the Initiator flag in the header). After reading the RFC4306 and clarifications and latest draft, I think most of the text is there, but it is scattered so widely it is hard to find: Room: This is a small editorial issue. Only new IKE SA has roles reversed and message ID set to zero, rekeying does not affect roles and message ID for existing IKE SA. A diagram would make this clear. ------=_NextPart_001_0048_01C95877.5823BF20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tero: The actual text in the rfc4306 or = clarifications does not exactly specify when the message ids are reset and when the roles = are changed. For me it was clear that of course the old IKE SA uses the old = roles and old message IDs as otherwise it could not work at all, and the new = IKE SA created by rekeying IKE SA will use the new message ID starting from 0, = and new roles of the original initiator and responder (i.e. the Initiator flag = in the header). After reading the RFC4306 and clarifications and latest draft, I think most of the text is there, = but it is scattered so widely it is hard to find:

 

Room: This is a small editorial issue.  =
Only new IKE SA has roles reversed and message ID set to zero, rekeying =
does not affect roles and message ID for existing IKE SA.  A =
diagram would make this clear.

 

------=_NextPart_001_0048_01C95877.5823BF20-- ------=_NextPart_000_0047_01C95877.5823BF20 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwNzEyMjMxNVowIwYJKoZIhvcNAQkEMRYEFLz73gsEZKfd DNV8quwnybpZaUwbMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA JCfjtmMqBul/Nw81CYNvw3M/RM9dAa1llNPQRIdRlDLCiNk2kDTlXYd1FqfWwpQ71k2TKA4YKCav SOGHVRexxKCCbosfMLR2BJfO/l7tZEtF8n2XLgKfIyKHVDTZCCTkVUkGme4BCAEwLRIkcOYiou94 X8UCcc3iKomRvcZG4wIFlbhN/LYC3CWEcrB+CidRHACd5JPy7V4pZSun4kL3BfCA8nUKShro/NwR +AYgynLAMpxrpSxlUBjSu1G5Gjzo8eqF75m3GhcWm+ULNoncyR8syCeXq8EbOrKcDy4I3I7S2lJ1 cZX5o/A2uKc9+lvAOa8ScqyXZGaYE0nj1J3IHAAAAAAAAA== ------=_NextPart_000_0047_01C95877.5823BF20-- Email secured by Check Point --===============1565373495== 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 --===============1565373495==-- Email secured by Check Point From ipsec-bounces@ietf.org Sun Dec 7 10:27: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 4BAEC3A6925; Sun, 7 Dec 2008 10:27:56 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCEB53A6925 for ; Sun, 7 Dec 2008 10:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, 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 3qN3NWy9ZRMN for ; Sun, 7 Dec 2008 10:27:53 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6048A3A68F7 for ; Sun, 7 Dec 2008 10:27:52 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7232729C003; Sun, 7 Dec 2008 17:09:30 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 227A629C009 for ; Sun, 7 Dec 2008 17:09:26 +0200 (IST) X-CheckPoint: {493BE643-10005-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB7F9MfL004659 for ; Sun, 7 Dec 2008 17:09:25 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 7 Dec 2008 17:09:23 +0200 From: Yaron Sheffer To: IPsecme WG Date: Sun, 7 Dec 2008 17:09:23 +0200 Thread-Topic: #55: Exponential reuse - reference Thread-Index: AclYaiNE7dk2jQlzQAeQqedl2qisrA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017D@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] #55: Exponential reuse - reference 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="===============1438475141==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1438475141== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0094_01C9587A.E6D4CD10" ------=_NextPart_000_0094_01C9587A.E6D4CD10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0095_01C9587A.E6D4CD10" ------=_NextPart_001_0095_01C9587A.E6D4CD10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yaron: 2.12: Exponential reuse - can we give a reference on how to do it securely? Room: Does anyone have a reference? There may be a minor change involving multiplying old exponential by g (mod p) to produce a different exponential. When exponential reused, nonces force generated keys to be different. The request is for an external crypto or security analysis reference on this topic. [This is obviously still open - Yaron]. ------=_NextPart_001_0095_01C9587A.E6D4CD10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yaron: 2.12: Exponential reuse - can we = give a reference on how to do it securely?

 

Room: Does anyone have a reference?  =
There may be a minor change involving multiplying old exponential by g =
(mod p) to produce a different exponential.  When exponential =
reused, nonces force
generated =
keys to be different.  The request is for an external crypto or =
security analysis reference on this =
topic.
 

[This is obviously still open – = Yaron].

------=_NextPart_001_0095_01C9587A.E6D4CD10-- ------=_NextPart_000_0094_01C9587A.E6D4CD10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwNzEyNDg0M1owIwYJKoZIhvcNAQkEMRYEFNA7FS3NL1vK R4k7WJMURrRAfhW+MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA pcpEUiEe4OXZMUE7alBXh22AOh7Qm2iNNhtgYHgVy/l2poxGKUuprfemE7oF1vF5zIpbrwuo3FZk NaD+5q3X/mgOSzVap7RK7W9FOe40Tr008t2FbuxqJIFk3R2rCldvnAD3gRA/Ck8HOqOQKGhYLhdm 6j2eLfp1cxbp01H/za4hbEzPx6A7GnRUBqndyRZsp/xk93JPmIDq7NGmMuOXCG1yntnTRuHjlOZ0 9p+0qhIZOqlQnTr0SaE4ARjAbYBoLdTHdepAUJG18Uc//V/8AdyQngt2yLWP5rBTmmyr2+riHIBu 1AKyONkMYra8oBajzMjKUqnFqKxg03RASuc0wAAAAAAAAA== ------=_NextPart_000_0094_01C9587A.E6D4CD10-- Email secured by Check Point --===============1438475141== 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 --===============1438475141==-- Email secured by Check Point From ipsec-bounces@ietf.org Sun Dec 7 10:27: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 B727E3A6909; Sun, 7 Dec 2008 10:27:57 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 957CA3A69C6 for ; Sun, 7 Dec 2008 10:27:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.077, 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 AElMKF+NQeMq for ; Sun, 7 Dec 2008 10:27:55 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 22A6E3A6909 for ; Sun, 7 Dec 2008 10:27:55 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id F0CE129C005; Sun, 7 Dec 2008 17:09:29 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C2E6E29C007 for ; Sun, 7 Dec 2008 17:09:25 +0200 (IST) X-CheckPoint: {493BE643-10002-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB7F9MfK004659 for ; Sun, 7 Dec 2008 17:09:25 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 7 Dec 2008 17:09:23 +0200 From: Yaron Sheffer To: IPsecme WG Date: Sun, 7 Dec 2008 17:09:23 +0200 Thread-Topic: #30: Conflicts in DH proposals Thread-Index: AclYaY+HcIlVLmkPSh2FtySpLnHrPg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017C@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] #30: Conflicts in DH proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0227651087==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0227651087== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_008C_01C9587A.531577A0" ------=_NextPart_000_008C_01C9587A.531577A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_008D_01C9587A.531577A0" ------=_NextPart_001_008D_01C9587A.531577A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tero: One of the questions that have been out long time, is that do all of the offered proposals must have identical Diffie-Hellman group lists. What does it mean if one of the proposals have different list than some other proposal. Can the KE payload include then be from such group that only exists in one of the lists. Also do the Diffie-Hellman groups need to be repeated on every single proposal. I think we should add some text explaining that. Room: This may be missing functionality involving how an endpoint deals with a KE payload that is wrong for the selected proposal. Charlie Kaufman: Should always start with stronger KE payload, there is text on this, but can benefit from clarification. ------=_NextPart_001_008D_01C9587A.531577A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tero: One of the questions that have been out long time, is that = do all of the offered proposals must have identical Diffie-Hellman group lists. = What does it mean if one of the proposals have different list than some other proposal. Can the KE payload include then be from such group that only = exists in one of the lists. Also do the Diffie-Hellman groups need to be = repeated on every single proposal.

I think we should add some text explaining that. 

Room: This =
may be missing functionality involving how an endpoint deals with a KE =
payload that is wrong for the selected proposal. Charlie Kaufman: Should =
always start with stronger KE payload, there is text on this, but can =
benefit from clarification.
------=_NextPart_001_008D_01C9587A.531577A0-- ------=_NextPart_000_008C_01C9587A.531577A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIwNzEyNDQzNVowIwYJKoZIhvcNAQkEMRYEFDOAt2Fyh1cN q+EB/xi8cc70Q3UHMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA PZfy9xUbNKpTFQkN/YAkIE6RaIUFkJWTfzqvOli6nHkDUTvhioo/1Y4MjQI6FoAXEh1Hmih+YIVT XRUfAatqJTZUUPSB/sWI2wGZRX/EfZeqcDF3F5YHdJALQh9w2uT/OtKLBIHgCpTXODZt/hAUL2Ba PCTJ+Tw68eAlWE1OdxmPmq/d9xpPI26kaB2EfGnRYQRwBDmJsJOWtvGBJBP/22US1k5ZT0E8V0Ys z2xrZlPWKDjkFXYDgR2OtKXJHrjQDm7YDDQvWHtH1lGCM6lsVw/Xy2BWWauIHX+6cbbN5g1OhWRx A4+jd/JsYdnY9AsWIh5aFUhqeks5ntk8Lx9DXgAAAAAAAA== ------=_NextPart_000_008C_01C9587A.531577A0-- Email secured by Check Point --===============0227651087== 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 --===============0227651087==-- Email secured by Check Point From ipsec-bounces@ietf.org Sun Dec 7 11:23: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 D960A3A67B4; Sun, 7 Dec 2008 11:23:03 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C23533A67B4 for ; Sun, 7 Dec 2008 11:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGPyDNwQax7h for ; Sun, 7 Dec 2008 11:23:02 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id E21EB3A677C for ; Sun, 7 Dec 2008 11:23:01 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 010A129C001; Sun, 7 Dec 2008 21:22:55 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2E1C82004A9 for ; Sun, 7 Dec 2008 21:22:55 +0200 (IST) Received: from [172.31.21.19] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB7JMffF025308 for ; Sun, 7 Dec 2008 21:22:54 +0200 (IST) Message-Id: From: Yoav Nir To: ipsec@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 7 Dec 2008 18:11:32 +0200 X-Mailer: Apple Mail (2.929.2) Subject: [IPsec] Comments about "IKEv2 Redirect" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi. I've read through the IKEv2 Redirect draft, and I have some comments: 1. Section 5 ("Gateway Initiated Redirect") does not specify what the client and gateway should do after the redirect message is sent and acknowledged. Obviously the client should setup SAs with the new gateway. What is less clear is what happens to the IKE and child SAs with the first gateway. One option is to make the REDIRECT/REDIRECT_ACK pair imply a delete of the IKE SAs. In that case all further IPsec traffic will be rejected. In that case the text should say this clearly. Another option is that the SAs remain valid until either side explicitly closes them. In that case the text should say this, and also recommend which side should close the old SAs and how soon (for example: the client should delete as soon as it starts setting up the new IKE SAs, the gateway should delete after allowing enough time to set up new SAs - one minute?) 2. Section 9: s/with who, /with whom / I feel really pedantic for this one... 3. Abstract. "IKEv2 is a popular protocol..." this is not strictly true. I would lost the "popular". Also, since the abstract gives the reasons why we might want to redirect, I think it should include, in addition to the overloaded gateway and mobile IPv6 case, the case of draining a remote access gateway for maintenance. 4. Introduction. "widely" - same as "popular" in the abstract. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nn@3abn.org Sun Dec 7 13:01:02 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6D03A689E for ; Sun, 7 Dec 2008 13:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.054 X-Spam-Level: X-Spam-Status: No, score=-16.054 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAUPFsCPODT7 for ; Sun, 7 Dec 2008 13:01:01 -0800 (PST) Received: from dynamic-acs-72-23-138-240.zoominternet.net (dynamic-acs-72-23-138-240.zoominternet.net [72.23.138.240]) by core3.amsl.com (Postfix) with SMTP id BAD023A67AB for ; Sun, 7 Dec 2008 13:00:51 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081207210054.BAD023A67AB@core3.amsl.com> Date: Sun, 7 Dec 2008 13:00:51 -0800 (PST) Having trouble viewing this email? Click here! From ipsec-bounces@ietf.org Mon Dec 8 08:37:15 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B535E3A69B9; Mon, 8 Dec 2008 08:37:15 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F2C93A69B9 for ; Mon, 8 Dec 2008 08:37:14 -0800 (PST) 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 j2kwLS+yjGxB for ; Mon, 8 Dec 2008 08:37:13 -0800 (PST) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.191]) by core3.amsl.com (Postfix) with ESMTP id 03A193A68E3 for ; Mon, 8 Dec 2008 08:37:12 -0800 (PST) Received: by gv-out-0910.google.com with SMTP id e6so185630gvc.15 for ; Mon, 08 Dec 2008 08:37:06 -0800 (PST) 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=53aYh0eMrpfwwM4qK+9ZVquYGpverzqLpeAa6guBwjk=; b=dlLzqaB8FP4EnIpBoqc5HM57maM7GNSIB/vbea0lmB9FT+Cg2S/5aSC2DiY0SjD+ts Mf58RuodhFLQzSd9MVr2ME/05E37JetPgDtVSOQnwiMeCj7/ATNiA+Ga0WYqsjLgjmvu jyxOrRMU2IioplBXnBa0NolLjxE8PsBUoux0g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=n+NnxoiY5fWrheM1+z3XShgfH26o6v+LUGk4BuCk7GqcVCdu3NqE3bH63K1uE/3cEb Zm3GqxLoWqd7DLKQ6MsktqWBE5FD36SPlk1CyiP8zA+EzVAzfR4pIGk+XKqWUs706gNk cBm1pJxGQBmcnCiG0wri5T6viAnnw9pQu6dRo= Received: by 10.86.59.18 with SMTP id h18mr2742314fga.35.1228754219370; Mon, 08 Dec 2008 08:36:59 -0800 (PST) Received: by 10.86.57.20 with HTTP; Mon, 8 Dec 2008 08:36:58 -0800 (PST) Message-ID: <99043b4a0812080836h65d0c95awcc45cf6805bc397c@mail.gmail.com> Date: Mon, 8 Dec 2008 17:36:58 +0100 From: "Matthew Cini Sarreo" To: ipsec@ietf.org MIME-Version: 1.0 Subject: [IPsec] IKEv2: Behavior when IKE_SA_INIT Message 1 has an unacceptable DH group 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="===============0517341897==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0517341897== Content-Type: multipart/alternative; boundary="----=_Part_42580_8949096.1228754218470" ------=_Part_42580_8949096.1228754218470 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, Let's consider the following scenario: Two IKEv2 peers, A and B want to initiate an IKE_SA (this is the first SA), and A (Initiator), who is configured to request just one, specific DH Group, not a group of groups, guesses an unacceptable DH Group (say, it is configured to use MODP_2048 but B only supports MODP_1024). The first message is sent, using a KE payload with MODP_2048 as DH group. When B parses the proposal for MODP_2048, it realizes that it does not support that group. What does B do? The options (atleast, that come to my mind) are: 1) Disregard the group and use the highest possible group (i.e MODP_1024). To me, this does not seem plausible. 2) Wait until A resends a proposal with the correct DH Group. This would probabbly cause a deadlock, as A will assume that the peer is dead after DPD runs out. 3) Send somekind of reply to tell A that the Group was inacepptable, and to use another one. Preferibly, this other group would also be included. To my understanding, an Informational Message with INVALID_KE_PAYLOAD would be the the correct way to follow this point (3) and the correct way to behave in this scenario. I got this understanding from Par 7 in Section 2.7 of draft-ietf-ipsecme-ikev2bis-01, which reads: Since the initiator sends its Diffie-Hellman value in the > IKE_SA_INIT, it must guess the Diffie-Hellman group that the > responder will select from its list of supported groups. If the > initiator guesses wrong, the responder will respond with a Notify > payload of type INVALID_KE_PAYLOAD indicating the selected group. > This seems to make it clear that at this point, the IKE_SA has not yet been established due to an error in the IKE_SA_INIT exchange. But, section 1.5 states that: > If it does not have such an IKE SA, it MAY > send an Informational message without cryptographic protection to the > source IP address. Such a message is not part of an informational > exchange, and the receiving node MUST NOT respond to it. Doing so > could cause a message loop. > > .... > {{ Clarif-7.7 }} There are two cases when such a one-way notification > is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are > sent outside of an IKE SA. Note that such notifications are > explicitly not Informational exchanges; these are one-way messages > that must not be responded to. > > The confusion lies here: does a one way Informational Message exist only in the case when a known Peer sends a message with an invalid SPI to a peer that it already had an SPI with (say, a crash caused a state loss), or whenever any IKE_SA is not available, these are the only two possible things to do? Logically, I would say that if Informational Messages CAN happen before the IKE_SA is established, but this does not seem to be clearly stated. I am sorry if this question has an obvious answer, this is my first experience with something similar to IKE. Regards, Matthew ------=_Part_42580_8949096.1228754218470 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,

Let's consider the following scenario:
Two IKEv2 peers, A and B want to initiate an IKE_SA (this is the first SA), and A (Initiator), who is configured to request just one, specific DH Group, not a group of groups, guesses an unacceptable DH Group (say, it is configured to use MODP_2048 but B only supports MODP_1024).

The first message is sent, using a KE payload with MODP_2048 as DH group. When B parses the proposal for MODP_2048, it realizes that it does not support that group. What does B do? The options (atleast, that come to my mind) are:
1) Disregard the group and use the highest possible group (i.e MODP_1024). To me, this does not seem plausible.
2) Wait until A resends a proposal with the correct DH Group. This would probabbly cause a deadlock, as A will assume that the peer is dead after DPD runs out.
3) Send somekind of reply to tell A that the Group was inacepptable, and to use another one. Preferibly, this other group would also be included. To my understanding, an Informational Message with INVALID_KE_PAYLOAD would be the the correct way to follow this point (3) and the correct way to behave in this scenario. I got this understanding from Par 7 in Section 2.7 of draft-ietf-ipsecme-ikev2bis-01, which reads:

Since the initiator sends its Diffie-Hellman value in the
IKE_SA_INIT, it must guess the Diffie-Hellman group that the
responder will select from its list of supported groups. If the
initiator guesses wrong, the responder will respond with a Notify
payload of type INVALID_KE_PAYLOAD indicating the selected group.

This seems to make it clear that at this point, the IKE_SA has not yet been established due to an error in the IKE_SA_INIT exchange. But, section 1.5 states that:
   If it does not have such an IKE SA, it MAY
   send an Informational message without cryptographic protection to the
   source IP address.  Such a message is not part of an informational

   exchange, and the receiving node MUST NOT respond to it.  Doing so 
   could cause a message loop.
.... 
{{ Clarif-7.7 }} There are two cases when such a one-way notification
   is sent: INVALID_IKE_SPI and INVALID_SPI.  These notifications are
   sent outside of an IKE SA.  Note that such notifications are

   explicitly not Informational exchanges; these are one-way messages
   that must not be responded to.
 
The confusion lies here: does a one way Informational Message exist only in the case when a known Peer sends a message with an invalid SPI to a peer that it already had an SPI with (say, a crash caused a state loss), or whenever any IKE_SA is not available, these are the only two possible things to do? Logically, I would say that if Informational Messages CAN happen before the IKE_SA is established, but this does not seem to be clearly stated.

I am sorry if this question has an obvious answer, this is my first experience with something similar to IKE.

Regards,
Matthew
------=_Part_42580_8949096.1228754218470-- --===============0517341897== 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 --===============0517341897==-- From ipsec-bounces@ietf.org Mon Dec 8 09:09:05 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 116FB3A69EC; Mon, 8 Dec 2008 09:09:05 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBDF23A69EC for ; Mon, 8 Dec 2008 09:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 2pY+ZdgVf4sH for ; Mon, 8 Dec 2008 09:09:02 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 190CD3A67BD for ; Mon, 8 Dec 2008 09:09:01 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB8H8p4v011179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 19:08:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB8H8ouX025699; Mon, 8 Dec 2008 19:08:50 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18749.21666.801967.227066@fireball.kivinen.iki.fi> Date: Mon, 8 Dec 2008 19:08:50 +0200 From: Tero Kivinen To: "fan zhao" In-Reply-To: References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 18 min Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org fan zhao writes: > I do not see why adding the REDIRECT payload can affect the authentication > combination. The authentication of the last IKE_AUTH message is done > independently and actually before the processing of the REDIRECT payload. > Sure, we should consider all possible cases. Do you find anything broken? The number of packets sent in the IKE_AUTH will change for EAP for example, and the REDIRECT payload changes location depending what authentication method is used (i.e. it would be in the last). This means that at least EAP vs non EAP case is mandatory to test, but in general good QA will test all possible combinations to make sure there is nothing that breaks when other authentication methods are used. I agree that making bug that is only affected by certain authentication combination might not be the most common bug to make, but on the other hand bugs do not tend to be very predictable in general. > > * 2). It needs to be tested with other initial exchange combinations, > > i.e. INVALID_KE_PAYLOAD and COOKIE notification cases, it needs to be > > tested with MOBIKE extensions, it needs to be tested with NAT > > traversal cases, etc. > Still I do not see anyhting could be broken. To my best knowledgement, > I do not see this can break MOBIKE and NAT traversal either. > Can you give me an example? For example for NAT traversal you still need to make sure the client uses correct port to connect the new server. The current draft does not say whether client should connect to directly to port 4500 or restart at port 500. Both of them do have benefits. With mobike the complication could be for example that IP-addresses change between IKE_SA_INIT and IKE_AUTH, or when combininig MOBIKE with NAT traversal, you do the port float to port 4500 before you start IKE_AUTH etc. I cannot really guess what kind of bugs people tend to write... But implementations usually do have bugs, and implementations needs to be tested before they can be put out. The more options we have the more testing there is to do. > By the testing effort, do you mean the "conditions" in the program > or the testing cases? There are many different ways for > implementation. From the protocol perspective, the state transition > is simple: after all the processing, specified in the IKEv2 > protocol, of the last IKE_AUTH message, then the client processes > the REDIRECT payload. I mean the test done by the QA before any release is done, and also interoperability testing done in the IPsec interoperability events. > I worry more about the "consequence" of packet reordering/loss. That is something your current QA people should already be testing before you release anything, as it is critical security feature, and if that is broken, then your implementation is unsecure. This is something that MUST be done for the plain IKEv2 already, this extension does not add any new requirements for this part. > I agree that packet reordering/loss can be handled. But even so, delay and > overhead are introduced. As an example, assume that the server sends > the last IKE_AUTH message and then a informational message with > the REDIRECT payload. If the informational message is lost during the > transmission, the server does not know until it receives an IPsec packet > from the client again; Server will know the informational packet was lost, as it does not receive reply back from the client. This again is standard IKEv2 feature, that must be tested by the QA before any products can be put out, as it affects the whole IKEv2 protocol implementation. > then the server needs to send another informational > message with the REDIRECT payload to the client. The server would not send another informational message, he would resend the previous request, and he will resend it until the client will reply. If the client will not reply then server will tear down the IKE SA and assume the connection is broken. Again this is standard operation that must be correctly handled by all implementations, which means it should be tested by the QA already (hopefully part of their automatic testing suite). > In this case, the client would waste a packet and IPsec processing > time on this packet, and the client cannot connect to the correct > server as soon as possible. This is not good especially when there > is existing session between the client and the correct server. As the server most likely already responded with the NO_ADDITIONAL_SAS error during the IKE_AUTH, the server and client do not have IPsec SA between them. They only have IKE SA. And the exactly same delay will happen if the packet containing N(REDIRECT) is lost, regardless whether it is part of the IKE_AUTH or INFORMATIONAL exchange. > Thanks for explanation. Yes I agree with you: so in the redirection > case, if the REDIRECT payload is received before the last AUTH > message (i.e. reordering), the client shoudl reject it. Yes. > Then the > sqerver would have to send another REDIRECT payload to the client > again after it realizes that the client is not redirected yet, > right? Thanks. It will resend the packet containing the N(REDIRECT) notify when it realizeds it has not received reply packet for that. Meaning it will resend it after 0.5-1 second or so. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 8 09:15:29 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5607228C0FD; Mon, 8 Dec 2008 09:15:29 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FBC28C0FD for ; Mon, 8 Dec 2008 09:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 TyevIKHyFY3I for ; Mon, 8 Dec 2008 09:15:28 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 4B7BD28C0F8 for ; Mon, 8 Dec 2008 09:15:27 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB8HF5bH004333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 19:15:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB8HF4GO026742; Mon, 8 Dec 2008 19:15:04 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18749.22040.361182.649984@fireball.kivinen.iki.fi> Date: Mon, 8 Dec 2008 19:15:04 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <79AA52D4-58CA-4656-A07A-233E19ED0C2F@checkpoint.com> References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> <79AA52D4-58CA-4656-A07A-233E19ED0C2F@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > I know the current RFC does not allow creating only an IKE SA, and > that we're not going to add such an option to the -bis, but I believe > that it would make the whole client thing more sensible. Or just remove the "connect" button, as it is not needed... And do not even allow things like per port SAs, as those are not needed either :-) (Yes, we do support per-host, port-protocol, per-port SAs mostly because our QA would kill us if we removed them, as they are very useful in the stress testing, i.e. like creating thousands SAs with very few machines. On the other hand there is not usually that good reasons for using them in real world, and they actually weaken the security as they allow much easier traffic flow tracking than wider SAs). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 8 09:21: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 ACC2A28B23E; Mon, 8 Dec 2008 09:21:51 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2A443A6A7A for ; Mon, 8 Dec 2008 09:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYbvuSnH3fWq for ; Mon, 8 Dec 2008 09:21:50 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 84A2928B23E for ; Mon, 8 Dec 2008 09:21:46 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB8HLbRn018121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 19:21:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB8HLbxs012663; Mon, 8 Dec 2008 19:21:37 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18749.22433.463492.864413@fireball.kivinen.iki.fi> Date: Mon, 8 Dec 2008 19:21:37 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950177@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950177@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: IPsecme WG Subject: [IPsec] #9: Notification when creation of CHILD_SA fails 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 writes: > > same IP address. The initiator begins negotiation of a CHILD_SA > > using the SAi2 payload. The final fields (starting with SAi2) are > > described in the description of the CREATE_CHILD_SA exchange. > > > > <-- HDR, SK {IDr, [CERT,] AUTH, > > SAr2, TSi, TSr} > > > > The responder asserts its identity with the IDr payload, optionally > > sends one or more certificates (again with the certificate containing > > the public key used to verify AUTH listed first), authenticates its > > identity and protects the integrity of the second message with the > > AUTH payload, and completes negotiation of a CHILD_SA with the > > additional fields described below in the CREATE_CHILD_SA exchange. > > > > The recipients of messages 3 and 4 MUST verify that all signatures > > and MACs are computed correctly and that the names in the ID payloads > > correspond to the keys used to generate the AUTH payload. > > > > {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange > > fails for some reason, the IKE_SA is still created as usual. The > > list of responses in the IKE_AUTH exchange that do not prevent an > > IKE_SA from being set up include at least the following: > > NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, > > INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. > > Tero: In the case of the that kind of failure the return packet will then be > without the SAr2, Tsi, and TSr, i.e.: > > <-- HDR, SK {IDr, [CERT,] AUTH, > N(error_for_child_sa)} > > If the authentication fails in such ways that the entries cannot > create IKE SA (authentication failure or similar), then the response > will be unencrypted, unauthenticated notify. There is no point of > sending the notify encrypted and integrity protected, as it is not > authenticated (as initiator and responder have not yet verified the > AUTH payloads): > > <-- HDR, N(error_for_ike_sa) > > The initiator receiving such reply MUST NOT immediately stop the SA > creation, but it should still retransmit the message few times, in > case that error notify was forgery and the real responder will reply > with valid reply. It can use the recipient of such message as a hint > to tell that authentication failed, thus it can shorten the > retransmission timers from few minutes down to few tens of seconds. > > Paul: Not done. This is interesting, but should be discussed on the list. > > Room: Scenario: IKE SA creation proceeds immediately to first CHILD SA > creation. What if CHILD SA can't be created, but IKE SA is ok? Text should > make it clear that failure of CHILD SA creation should not tear down IKE SA > (e.g., avoids losing work to create the IKE SA based on guessing wrong about > a child traffic selector). > > Yaron: seems to me the ticket discusses one thing (IKE SA creation > fails because of bad authentication), while the room's discussion is > about a different thing (IKE SA successful). Comments on the > original ticket are welcome. The ticket actually has two cases, the most important one is that first part, i.e. where it says that we need to explicitly describe the case where the IPsec SA creation fails, but IKE SA creation succeeds. The clarification already says that, but I think we could add explicit example messages out of that. The ticket also talks about the second case, where the IKE SA fails, i.e. the case when IKE SA is not created, and we need to send error message back about that. As I explained in my text there is no point of encrypting that as it will not be authenticated anyways. We might want to split this to two different tickets. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 8 09:39: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 D56673A6A90; Mon, 8 Dec 2008 09:39:54 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF673A6A90 for ; Mon, 8 Dec 2008 09:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 EHtHmxNixNp0 for ; Mon, 8 Dec 2008 09:39:53 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 93D383A6A8F for ; Mon, 8 Dec 2008 09:39:51 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB8Hdg0L005318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 19:39:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB8Hdgba028205; Mon, 8 Dec 2008 19:39:42 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18749.23518.256159.306659@fireball.kivinen.iki.fi> Date: Mon, 8 Dec 2008 19:39:42 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017A@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017A@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 15 min Cc: IPsecme WG Subject: [IPsec] #40: Floating to port 4500 'by default', and use of UDP when no NAT detected 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 writes: > UDP encap can get IKEv2 through a firewall that only allows UDP and TCP. > This is a reason to always use UDP encap, even if no NAT detected. > This has to start on port #4500. Note, that client (or server) can trivially fake NAT to be on the path, by just sending incorrect NAT_DETECTION_*_IP payloads. This will cause both ends to enable UDP encapsulation. > Summary of open questions: > 1. Do we allow to float immediately into port 4500, e.g. to have port > 4500-only originators? I would say yes. > 2. Do we always require UDP encapsulation when using port 4500 (the > scope here does NOT include MOBIKE). I would say no (especially if the first question is allowed, as client might want to start at port 4500, but still might not want to waste extra bytes for UDP encapsulation if it is needed) > 3. Do we care about asymmetric paths, where NAT only happens in one > direction? If so, what is the correct behavior? Can someone tell me any reason to someone to have asymmetric NAT, and how it is supposed to work. It does not work with TCP for example, as the incoming IP-addresses do not match. Other questions: 4. If other end does not support NAT-T, do we allow other end still sending UDP encapsulated packets. (My answer would be NO) 5. If both ends do support NAT-T, but no NAT is detected, is the other end still allowed to send UDP encapsulated packets (MOBIKE mandates this). This is regardless whether we have floated to port 4500 or not. (My answer would be YES) 6. If the answer to 5 is YES, then how are reply packets sent out, plain ESP, or UDP encapsulated ESP, or either way (if the answer to question 5 is YES, then other end must accept them in either way anyways). (My answer would be SHOULD ESP or either way, as that is what MOBIKE assumes, as after the IP-address change from behind NAT to address not behind NAT, we still might receive few UDP encapsulated packets before the other end realizes the situation, but if we make both ends to reply using same encapsulation this will not be resolved, but we keep on going with UDP encapsulation forever.) In summary my answers would be: Initiator can float to port 4500, regardless whether there is NAT or not, and he can also do that from the beginning. If NAT-T is supported, all devices MUST be able to receive both UDP encapsulated and non-UDP encapsulated packets at any time, and process them both. Encapsulation of incoming packets do not affect the encapsulation of the sent packets, all devices decide sending format independly. If NAT is detected all devices MUST enable sending UDP encapsulated packets. As all devices must be able to receive and process both formats at any time, the sender can change the encapsulation based on local implementation matters (unless there is NAT detected, in which case they MUST send packets UDP encapsulated). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 8 09: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 1607728C10B; Mon, 8 Dec 2008 09:53:34 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B510628C105 for ; Mon, 8 Dec 2008 09:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 KeNHSKSBXmna for ; Mon, 8 Dec 2008 09:53:32 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6C77728C101 for ; Mon, 8 Dec 2008 09:53:31 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB8HrHg2007787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 19:53:17 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB8HrGX7021395; Mon, 8 Dec 2008 19:53:16 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18749.24332.970941.151598@fireball.kivinen.iki.fi> Date: Mon, 8 Dec 2008 19:53:16 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950179@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950179@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 12 min Cc: IPsecme WG Subject: [IPsec] #22: Add section on simultaneous IKE SA rekey X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yaron Sheffer writes: > Room: This (simultaneous IKE SA rekey) is not an easy situation to create > for testing, but it does happen. Easiest way to create this for testing is to set rekey times to be same very short time period, but configure retransmission timers to be much longer than normally. Then set the IKE SAs up and then disconnect cable between the devices. Now wait for both ends to start doing rekey of IKE SA, i.e. sending the first packet out. After both ends have started that you reconnect the cable, and you have simultaneous rekey. If the retransmission timers are long enough you might even get the case where first rekey finishes completely before the one to other direction even starts. > Both sides need to agree on which SA > survives, otherwise both IKE SAs could be torn down, losing everything. > There is some text on this, but it needs attention, particularly for the > case in which both IKE SAs get created. Also need text on how to recognize > simultaneous IKE SA rekey (e.g., if packets lost during simultaneous rekey). > Tero believes that the clarifications document covers this, but that text > needs to be checked. The section 5.11.4 in the RFC4718 talks about this. The twist care there should be taken care of by making sure the req3 D() is not sent out before few minutes has passed, so host B's retransmissions of req2 will reach host A, and it will detect there was simultaneous rekey. The section 5.11.8 also talks bit about similar cases, and there the same solution works, i.e. delay the deletation of the old IKE SA so that other end has option to finish the existing exchanges. The delay is also needed for the device to know which one of the IKE SAs is the surviving one, so they cannot send delete notification to the old IKE SA before they know which of the new IKE SAs survived, meaning which of the nodes should send it. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 8 09:55: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 E2FF928C11C; Mon, 8 Dec 2008 09:55:38 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35CAF28C11C for ; Mon, 8 Dec 2008 09:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.238 X-Spam-Level: X-Spam-Status: No, score=-2.238 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St3GkB+qExvf for ; Mon, 8 Dec 2008 09:55:37 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 95F0D28C105 for ; Mon, 8 Dec 2008 09:55:35 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB8HtQDk021520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 19:55:26 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB8HtQbS003567; Mon, 8 Dec 2008 19:55:26 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18749.24462.466484.170826@fireball.kivinen.iki.fi> Date: Mon, 8 Dec 2008 19:55:26 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950178@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950178@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: IPsecme WG Subject: [IPsec] #65: Original initiator and rekeying 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 writes: > Tero: The actual text in the rfc4306 > or clarifications does not exactly specify when the message ids are reset > and when the roles are changed. For me it was clear that of course the old > IKE SA uses the old roles and old message IDs as otherwise it could not work > at all, and the new IKE SA created by rekeying IKE SA will use the new > message ID starting from 0, and new roles of the original initiator and > responder (i.e. the Initiator flag in the header). After reading the RFC4306 > and clarifications and latest draft, I > think most of the text is there, but it is scattered so widely it is hard to > find: > > > > Room: This is a small editorial issue. Only new IKE SA has roles reversed > and message ID set to zero, rekeying does not affect roles and message ID > for existing IKE SA. A diagram would make this clear. My original email had diagram about this, that can be included to the draft: ---------------------------------------------------------------------- x.x.x Example of IKE SA Rekey by Original Initiator Here is full example of the IKE SA rekey, including the IKE SPIs, message id, and the Initiator and Response bit on the header. SPIA* are IKE SA SPIs allocated by Alice, and SPIB* are IKE SA SPIs allocated by Bob. HDR(I,R,M,F) format is used to explain fields in the header. I, and R are the initiator and responder IKE SA SPIs, M is the message id (in this example we assume the next one to be used by initiator is 33, and the next one to be used by responder is 44). The F is the flags field of the header, having Initiator and/or Response if those flags are set in the header. In this first example the Alice is the original initiator, and Bob is the original responder, and the Alice starts the IKE SA rekey. SPIA1 and SPIB1 are the SPIs of the old IKE SA and SPIA2 and SPIB2 are the SPIs for the new IKE SA. Alice Bob ------------------------------------------------------------------- HDR(SPIA1,SPIB1,33,Initiator), SK {SA(SPIA2), Ni, [KEi]} --> <-- HDR(SPIA1,SPIB1,33,Response), SK {SA(SPIB2), Nr,[KEr]} Now the IKE SA is rekeyed, and next the party who started the rekey deletes the old IKE SA, i.e. in this case it will be Alice. The delete sent as last message to the old IKE SA. Alice Bob ------------------------------------------------------------------- HDR(SPIA1,SPIB1,34,Initiator), SK {D(Protocol ID=1,No SPI} --> <-- HDR(SPIA1,SPIB1,34,Response), SK {} The next request sent by the Alice and Bob will have headers as following, first the request from Alice and Bob's reply to it: Alice Bob ------------------------------------------------------------------- HDR(SPIA2,SPIB2,0,Initiator), ... --> <--- HDR(SPIA2,SPIB2,0,Response), ... The Bob's first request and Alice's reply to it will be like this: Alice Bob ------------------------------------------------------------------- <--- HDR(SPIA2,SPIB2,0,), ... HDR(SPIA2,SPIB2,0,Initiator Response), ... --> x.x.x Example of IKE SA Rekey by Original Responder In this second example the Alice is still original initiator, and Bob is the original responder, but now Bob starts the IKE SA rekey. Alice Bob ------------------------------------------------------------------- <-- HDR(SPIA1,SPIB1,44,), SK {SA(SPIB2), Nr,[KEr]} HDR(SPIA1,SPIB1,44,Initiator Response), SK {SA(SPIA2), Ni, [KEi]} --> After this the Bob deletes the old IKE SA, and send his delete request as last exchange for the old IKE SA. Note, that the old IKE SA still keeps the original initiator and responder roles, and the message ID is still incremented as normally. Alice Bob ------------------------------------------------------------------- <-- HDR(SPIA1,SPIB1,45,), SK {D(Protocol ID=1,No SPI} HDR(SPIA1,SPIB1,45,Initiator Response), SK {} --> The new IKE SA on the other hand will have original initiator roles reversed compared to the original IKE SA. The next request sent by Alice and Bob's reply to it will have following headers: Alice Bob ------------------------------------------------------------------- HDR(SPIB2,SPIA2,0,), ... --> <--- HDR(SPIB2,SPIA2,0,Initiator Response), ... Note, that the SPIs in the header are reversed (i.e. the SPI allocated by the Bob is first, and the Initiator bit is set on those packets sent by Bob, not those sent by Alice as it was in the old IKE SA). The Bob's first request and Alice's reply to it will be like this: Alice Bob ------------------------------------------------------------------- <--- HDR(SPIB2,SPIA2,0,Initiator), ... HDR(SPIB2,SPIA2,0,Response), ... --> -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 8 09:57: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 7414F3A682F; Mon, 8 Dec 2008 09:57:53 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 251F13A6951 for ; Mon, 8 Dec 2008 09:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 BS7dsIbeAzQa for ; Mon, 8 Dec 2008 09:57:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1E8303A6864 for ; Mon, 8 Dec 2008 09:57:50 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB8HvgS9002613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 19:57:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB8HvgKR025310; Mon, 8 Dec 2008 19:57:42 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18749.24598.321512.769027@fireball.kivinen.iki.fi> Date: Mon, 8 Dec 2008 19:57:42 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: ipsec@ietf.org Subject: [IPsec] Comments about "IKEv2 Redirect" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > Another option is that the SAs remain valid until either side > explicitly closes them. In that case the text should say this, and > also recommend which side should close the old SAs and how soon (for > example: the client should delete as soon as it starts setting up the > new IKE SAs, the gateway should delete after allowing enough time to > set up new SAs - one minute?) I think this option would be better. That would be much more in line with how IKEv2 do things (i.e. for example IKE SA rekeys). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 8 10:10:16 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5507428C132; Mon, 8 Dec 2008 10:10:16 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71FDB28C132 for ; Mon, 8 Dec 2008 10:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 4eUo4A2CyqAt for ; Mon, 8 Dec 2008 10:10:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 96FD028C11A for ; Mon, 8 Dec 2008 10:10:13 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB8IA3JX008153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Dec 2008 20:10:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB8IA3Ue000905; Mon, 8 Dec 2008 20:10:03 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18749.25339.224201.764074@fireball.kivinen.iki.fi> Date: Mon, 8 Dec 2008 20:10:03 +0200 From: Tero Kivinen To: "Matthew Cini Sarreo" In-Reply-To: <99043b4a0812080836h65d0c95awcc45cf6805bc397c@mail.gmail.com> References: <99043b4a0812080836h65d0c95awcc45cf6805bc397c@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 11 min Cc: ipsec@ietf.org Subject: [IPsec] IKEv2: Behavior when IKE_SA_INIT Message 1 has an unacceptable DH group 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 Matthew Cini Sarreo writes: > Let's consider the following scenario: > Two IKEv2 peers, A and B want to initiate an IKE_SA (this is the first SA), > and A (Initiator), who is configured to request just one, specific DH Group, > not a group of groups, guesses an unacceptable DH Group (say, it is > configured to use MODP_2048 but B only supports MODP_1024). If both ends are configured that way, then there is no way they can ever get any IKE SAs up, thus it does not really matter that much how you fail it. > The first message is sent, using a KE payload with MODP_2048 as DH group. > When B parses the proposal for MODP_2048, it realizes that it does not > support that group. What does B do? The options (atleast, that come to my > mind) are: > 1) Disregard the group and use the highest possible group (i.e MODP_1024). > To me, this does not seem plausible. The responder cannot select any group that is not proposed by the initiator, and if initiator only offered 2048 bit group, then he do not have options. He either selects that or fails the exchange. > 2) Wait until A resends a proposal with the correct DH Group. This would > probabbly cause a deadlock, as A will assume that the peer is dead after DPD > runs out. If A is configured to use only 2048 bit group, it will not ever change to any other group unless someone manually fixes the policy. > 3) Send somekind of reply to tell A that the Group was inacepptable, and to > use another one. The correct solution is to send NO_PROPOSAL_CHOSEN, as none of the proposals sent by the initiator is acceptable for B. The use of INVALID_KE_PAYLOAD is only possible if the A proposed something that would be acceptable for the B, but just selected wrong group for the KE payload. I.e. the INVALID_KE_PAYLOAD will indicate the selected group B selected from the offer given by A. If none of the offers were acceptable then NO_PROPOSAL_CHOSEN is the sent instead. > > {{ Clarif-7.7 }} There are two cases when such a one-way notification > > is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are > > sent outside of an IKE SA. Note that such notifications are > > explicitly not Informational exchanges; these are one-way messages > > that must not be responded to. That clarification talks about ONE-WAY notifications. NO_PROPOSAL_CHOSEN or INVALID_KE_PAYLOAD are not one-way notifications, they are error notifications replies that are part of the normal IKE_SA_INIT exchange. > The confusion lies here: does a one way Informational Message exist only in > the case when a known Peer sends a message with an invalid SPI to a peer > that it already had an SPI with (say, a crash caused a state loss), or > whenever any IKE_SA is not available, these are the only two possible things > to do? Logically, I would say that if Informational Messages CAN happen > before the IKE_SA is established, but this does not seem to be clearly > stated. INFORMATIONAL exchanges are not used in the case you explained, it is using normal reply to the IKE_SA_INIT exchange but the contents will be the error notification. If you check out the section 2.4 of the RFC4718 that has some diagrams explaining the situation more. All the messages shown there do have IKE_SA_INIT in their exchange type field, and all sent by initiator will have R(esponse) bit set to 0, and all sent by responder will have the R(esponse) bit set to 1 in the flags of the header. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 8 11:00:12 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9D028C13B; Mon, 8 Dec 2008 11:00:12 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4FD28C13B for ; Mon, 8 Dec 2008 11:00:10 -0800 (PST) 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 reatXAGdavkU for ; Mon, 8 Dec 2008 11:00:10 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id EBA3428C12D for ; Mon, 8 Dec 2008 11:00:09 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB8IxKAr015831 for ; Mon, 8 Dec 2008 11:59:20 -0700 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB8Ixnbn226860 for ; Mon, 8 Dec 2008 11:59:51 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB8IxnR4029906 for ; Mon, 8 Dec 2008 11:59:49 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB8IxnnY029900 for ; Mon, 8 Dec 2008 11:59:49 -0700 In-Reply-To: To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Keith Welter X-MIMETrack: S/MIME Sign by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 12/08/2008 10:59:47 AM, Serialize by Notes Client on Keith Welter/Raleigh/IBM(Release 7.0 HF277|June 21, 2006) at 12/08/2008 10:59:47 AM, Serialize complete at 12/08/2008 10:59:47 AM, S/MIME Sign failed at 12/08/2008 10:59:47 AM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_10262008HFIGS1|October 26, 2008) at 12/08/2008 11:59:49, Serialize complete at 12/08/2008 11:59:49 Message-ID: Date: Mon, 8 Dec 2008 10:59:48 -0800 Subject: Re: [IPsec] #46: Exchange type for INVALID_IKE_SPI outside of an IKE_SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0254036491==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0254036491== Content-Type: multipart/alternative; boundary="=_alternative 006859BB88257519_=" This is a multipart message in MIME format. --=_alternative 006859BB88257519_= Content-Type: text/plain; charset="US-ASCII" > For the one-way INVALID_IKE_SPI notification described in RFC 4306 > section 1.5, it is unclear to me what > the Exchange Type should be in the IKE header. Should it be 37 > (INFORMATIONAL) or should it be copied from the request that contained the > unrecognized SPI? > The room: Kero Tivinen doesn't care as long as there is *exactly* one > answer. > Comment made that copying this [from the request] is implied by existing > text [i.e. need to clarify]. My preference is to copy the exchange type from the request since that conveys more information than always using 37 (INFORMATIONAL). Keith Welter IBM Enterprise Networking Solutions --=_alternative 006859BB88257519_= Content-Type: text/html; charset="US-ASCII"
> For the one-way INVALID_IKE_SPI notification described in RFC 4306
> <http://tools.ietf.org/html/rfc4306>  section 1.5, it is unclear to me what
> the Exchange Type should be in the IKE header.  Should it be 37
> (INFORMATIONAL) or should it be copied from the request that contained the
> unrecognized SPI?

> The room: Kero Tivinen doesn't care as long as there is *exactly* one
> answer.
> Comment made that copying this [from the request] is implied by existing
> text [i.e. need to clarify].
My preference is to copy the exchange type from the request since that
conveys more information than always using 37 (INFORMATIONAL).

Keith Welter
IBM Enterprise Networking Solutions --=_alternative 006859BB88257519_=-- --===============0254036491== 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 --===============0254036491==-- From ipsec-bounces@ietf.org Mon Dec 8 11:50:55 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D758C28C170; Mon, 8 Dec 2008 11:50:55 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4C0D28C170; Mon, 8 Dec 2008 11:50:54 -0800 (PST) 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 WhsgU5rbKAxL; Mon, 8 Dec 2008 11:50:53 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 2264428C12D; Mon, 8 Dec 2008 11:50:53 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB8JnKVN029356; Mon, 8 Dec 2008 12:49:20 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB8Jok0L187160; Mon, 8 Dec 2008 12:50:46 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB8JogmZ030673; Mon, 8 Dec 2008 12:50:44 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB8Jocui030526; Mon, 8 Dec 2008 12:50:39 -0700 In-Reply-To: <18749.23518.256159.306659@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017A@il-ex01.ad.checkpoint.com> <18749.23518.256159.306659@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 1AD90F1E:15429601-85257519:00694EBE; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 12/08/2008 02:50:22 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 12/08/2008 02:50:22 PM, Serialize complete at 12/08/2008 02:50:22 PM, S/MIME Sign failed at 12/08/2008 02:50:22 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_10262008HFIGS1|October 26, 2008) at 12/08/2008 12:50:39, Serialize complete at 12/08/2008 12:50:39 Message-ID: Date: Mon, 8 Dec 2008 14:50:38 -0500 Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] #40: Floating to port 4500 'by default', and use of UDP when no NAT detected 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="===============1134578477==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1134578477== Content-Type: multipart/alternative; boundary="=_alternative 006CFB7F85257519_=" This is a multipart message in MIME format. --=_alternative 006CFB7F85257519_= Content-Type: text/plain; charset="US-ASCII" Some replies to Yaron and Tero: Tero says: > Note, that client (or server) can trivially fake NAT to be on the > path, by just sending incorrect NAT_DETECTION_*_IP payloads. This will > cause both ends to enable UDP encapsulation. True, but I think we should strongly recommend against that practice, because there can be subtle problems in some cases (especially double NATs or gateways located behind NATs). For example, if a security gateway falsely represents itself as being behind a NAT, it is implying that the entire address space behind it is private, which is not the case. A peer initiating to it then has a dilemma in choosing which address to place in TSr, or even wondering whether it has enough information to choose an appropriate TSr at all. > 1. Do we allow to float immediately into port 4500, e.g. to have port > 4500-only originators? > > I would say yes. I think that is ok. Should we clarify that once you receive a message on port 4500, even if you do not detect a NAT, you must send messages from port 4500? > 2. Do we always require UDP encapsulation when using port 4500 (the > scope here does NOT include MOBIKE). > > I would say no (especially if the first question is allowed, as client > might want to start at port 4500, but still might not want to waste > extra bytes for UDP encapsulation if it is needed) I agree with Tero -- I prefer that we do not require UDP encap whenever floated. > 4. If other end does not support NAT-T, do we allow other end still > sending UDP encapsulated packets. > > (My answer would be NO) I agree with Tero -- I prefer that we do not use UDP-encap if no NAT notify payloads were exchanged. > 5. If both ends do support NAT-T, but no NAT is detected, is the other > end still allowed to send UDP encapsulated packets (MOBIKE mandates > this). This is regardless whether we have floated to port 4500 or > not. > > (My answer would be YES) I disagree with Tero. I would prefer that we do not allow UDP-encap if no NAT was detected. The biggest concern that I have is that implementations may have built UDP-encap support only into IPv4 paths, whereas this is a statement that seems to apply to both IPv4 and IPv6. This is true in our implementation; our IPv6 header processing does not support IPv6 UDP-encap. So I would prefer to allow UDP-encap only when a NAT was actually detected. > 6. If the answer to 5 is YES, then how are reply packets sent out, > plain ESP, or UDP encapsulated ESP, or either way (if the answer to > question 5 is YES, then other end must accept them in either way > anyways). > > (My answer would be SHOULD ESP or either way, ... While my answer to #5 is no, if the group consensus is yes, then my answer to #6 is to agree with Tero -- I prefer SHOULD ESP and MAY UDP-encap. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Yaron Sheffer Cc: IPsecme WG Date: 12/08/2008 12:40 PM Subject: [IPsec] #40: Floating to port 4500 'by default', and use of UDP when no NAT detected Yaron Sheffer writes: > UDP encap can get IKEv2 through a firewall that only allows UDP and TCP. > This is a reason to always use UDP encap, even if no NAT detected. > This has to start on port #4500. Note, that client (or server) can trivially fake NAT to be on the path, by just sending incorrect NAT_DETECTION_*_IP payloads. This will cause both ends to enable UDP encapsulation. > Summary of open questions: > 1. Do we allow to float immediately into port 4500, e.g. to have port > 4500-only originators? I would say yes. > 2. Do we always require UDP encapsulation when using port 4500 (the > scope here does NOT include MOBIKE). I would say no (especially if the first question is allowed, as client might want to start at port 4500, but still might not want to waste extra bytes for UDP encapsulation if it is needed) > 3. Do we care about asymmetric paths, where NAT only happens in one > direction? If so, what is the correct behavior? Can someone tell me any reason to someone to have asymmetric NAT, and how it is supposed to work. It does not work with TCP for example, as the incoming IP-addresses do not match. Other questions: 4. If other end does not support NAT-T, do we allow other end still sending UDP encapsulated packets. (My answer would be NO) 5. If both ends do support NAT-T, but no NAT is detected, is the other end still allowed to send UDP encapsulated packets (MOBIKE mandates this). This is regardless whether we have floated to port 4500 or not. (My answer would be YES) 6. If the answer to 5 is YES, then how are reply packets sent out, plain ESP, or UDP encapsulated ESP, or either way (if the answer to question 5 is YES, then other end must accept them in either way anyways). (My answer would be SHOULD ESP or either way, as that is what MOBIKE assumes, as after the IP-address change from behind NAT to address not behind NAT, we still might receive few UDP encapsulated packets before the other end realizes the situation, but if we make both ends to reply using same encapsulation this will not be resolved, but we keep on going with UDP encapsulation forever.) In summary my answers would be: Initiator can float to port 4500, regardless whether there is NAT or not, and he can also do that from the beginning. If NAT-T is supported, all devices MUST be able to receive both UDP encapsulated and non-UDP encapsulated packets at any time, and process them both. Encapsulation of incoming packets do not affect the encapsulation of the sent packets, all devices decide sending format independly. If NAT is detected all devices MUST enable sending UDP encapsulated packets. As all devices must be able to receive and process both formats at any time, the sender can change the encapsulation based on local implementation matters (unless there is NAT detected, in which case they MUST send packets UDP encapsulated). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 006CFB7F85257519_= Content-Type: text/html; charset="US-ASCII"
Some replies to Yaron and Tero:

Tero says:
> Note, that client (or server) can trivially fake NAT to be on the
> path, by just sending incorrect NAT_DETECTION_*_IP payloads. This will
> cause both ends to enable UDP encapsulation.

True, but I think we should strongly recommend against that practice, because there can be subtle problems in some cases (especially double NATs or gateways located behind NATs).  For example, if a security gateway falsely represents itself as being behind a NAT, it is implying that the entire address space behind it is private, which is not the case.  A peer initiating to it then has a dilemma in choosing which address to place in TSr, or even wondering whether it has enough information to choose an appropriate TSr at all.

> 1.                 Do we allow to float immediately into port 4500, e.g. to have port
> 4500-only originators?
>
> I would say yes.

I think that is ok.  Should we clarify that once you receive a message on port 4500, even if you do not detect a NAT, you must send messages from port 4500?

> 2.                 Do we always require UDP encapsulation when using port 4500 (the
> scope here does NOT include MOBIKE).
>
> I would say no (especially if the first question is allowed, as client
> might want to start at port 4500, but still might not want to waste
> extra bytes for UDP encapsulation if it is needed)

I agree with Tero -- I prefer that we do not require UDP encap whenever floated.

> 4. If other end does not support NAT-T, do we allow other end still
>    sending UDP encapsulated packets.
>
> (My answer would be NO)

I agree with Tero -- I prefer that we do not use UDP-encap if no NAT notify payloads were exchanged.

> 5. If both ends do support NAT-T, but no NAT is detected, is the other
>    end still allowed to send UDP encapsulated packets (MOBIKE mandates
>    this). This is regardless whether we have floated to port 4500 or
>    not.
>
> (My answer would be YES)

I disagree with Tero.  I would prefer that we do not allow UDP-encap if no NAT was detected.  The biggest concern that I have is that implementations may have built UDP-encap support only into IPv4 paths, whereas this is a statement that seems to apply to both IPv4 and IPv6.  This is true in our implementation; our IPv6 header processing does not support IPv6 UDP-encap.  So I would prefer to allow UDP-encap only when a NAT was actually detected.

> 6. If the answer to 5 is YES, then how are reply packets sent out,
>    plain ESP, or UDP encapsulated ESP, or either way (if the answer to
>    question 5 is YES, then other end must accept them in either way
>    anyways).
>
> (My answer would be SHOULD ESP or either way, ...
While my answer to #5 is no, if the group consensus is yes, then my answer to #6 is to agree with Tero -- I prefer SHOULD ESP and MAY UDP-encap.


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


From: Tero Kivinen <kivinen@iki.fi>
To: Yaron Sheffer <yaronf@checkpoint.com>
Cc: IPsecme WG <ipsec@ietf.org>
Date: 12/08/2008 12:40 PM
Subject: [IPsec]  #40: Floating to port 4500 'by default', and use of UDP when no NAT detected




Yaron Sheffer writes:
> UDP encap can get IKEv2 through a firewall that only allows UDP and TCP.
>         This is a reason to always use UDP encap, even if no NAT detected.
>         This has to start on port #4500.

Note, that client (or server) can trivially fake NAT to be on the
path, by just sending incorrect NAT_DETECTION_*_IP payloads. This will
cause both ends to enable UDP encapsulation.

> Summary of open questions:
> 1.                 Do we allow to float immediately into port 4500, e.g. to have port
> 4500-only originators?

I would say yes.

> 2.                 Do we always require UDP encapsulation when using port 4500 (the
> scope here does NOT include MOBIKE).

I would say no (especially if the first question is allowed, as client
might want to start at port 4500, but still might not want to waste
extra bytes for UDP encapsulation if it is needed)

> 3.                 Do we care about asymmetric paths, where NAT only happens in one
> direction? If so, what is the correct behavior?

Can someone tell me any reason to someone to have asymmetric NAT, and
how it is supposed to work. It does not work with TCP for example, as
the incoming IP-addresses do not match.

Other questions:

4. If other end does not support NAT-T, do we allow other end still
  sending UDP encapsulated packets.

(My answer would be NO)

5. If both ends do support NAT-T, but no NAT is detected, is the other
  end still allowed to send UDP encapsulated packets (MOBIKE mandates
  this). This is regardless whether we have floated to port 4500 or
  not.

(My answer would be YES)

6. If the answer to 5 is YES, then how are reply packets sent out,
  plain ESP, or UDP encapsulated ESP, or either way (if the answer to
  question 5 is YES, then other end must accept them in either way
  anyways).

(My answer would be SHOULD ESP or either way, as that is what MOBIKE
assumes, as after the IP-address change from behind NAT to address not
behind NAT, we still might receive few UDP encapsulated packets before
the other end realizes the situation, but if we make both ends to
reply using same encapsulation this will not be resolved, but we keep
on going with UDP encapsulation forever.)

In summary my answers would be:

Initiator can float to port 4500, regardless whether there is NAT or
not, and he can also do that from the beginning. If NAT-T is
supported, all devices MUST be able to receive both UDP encapsulated
and non-UDP encapsulated packets at any time, and process them both.
Encapsulation of incoming packets do not affect the encapsulation of
the sent packets, all devices decide sending format independly. If NAT
is detected all devices MUST enable sending UDP encapsulated packets.
As all devices must be able to receive and process both formats at any
time, the sender can change the encapsulation based on local
implementation matters (unless there is NAT detected, in which case
they MUST send packets UDP encapsulated).
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 006CFB7F85257519_=-- --===============1134578477== 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 --===============1134578477==-- From ipsec-bounces@ietf.org Mon Dec 8 12:14: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 E5BE528C18F; Mon, 8 Dec 2008 12:14:08 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6161D28C18B for ; Mon, 8 Dec 2008 12:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lnatlyOpvmG for ; Mon, 8 Dec 2008 12:14:03 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 9CDF828C15C for ; Mon, 8 Dec 2008 12:14:03 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id mB8KDw4Y001586 for ; Mon, 8 Dec 2008 20:13:58 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 mB8KDvd7029438 for ; Mon, 8 Dec 2008 15:13:57 -0500 (EST) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB8K68MA010053 for ; Mon, 8 Dec 2008 15:06:13 -0500 (EST) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB8K63an010051 for ipsec@ietf.org; Mon, 8 Dec 2008 15:06:03 -0500 (EST) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Mon, 8 Dec 2008 15:06:03 -0500 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20081208200603.GM8258@sun.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017A@il-ex01.ad.checkpoint.com> <18749.23518.256159.306659@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [IPsec] #40: Floating to port 4500 'by default', and use of UDP when no NAT detected 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, Dec 08, 2008 at 02:50:38PM -0500, Scott C Moonen wrote: > Some replies to Yaron and Tero: Likewise. > > 1. Do we allow to float immediately into port 4500, e.g. to > have port > > 4500-only originators? > > > > I would say yes. > > I think that is ok. Should we clarify that once you receive a message on > port 4500, even if you do not detect a NAT, you must send messages from > port 4500? Start at 4500, stay at 4500? Why not? (I'm also assuming this is IKEv2 only, not needed for retrofitting onto IKEv1...) > > 2. Do we always require UDP encapsulation when using port > 4500 (the > > scope here does NOT include MOBIKE). > > > > I would say no (especially if the first question is allowed, as client > > might want to start at port 4500, but still might not want to waste > > extra bytes for UDP encapsulation if it is needed) > > I agree with Tero -- I prefer that we do not require UDP encap whenever > floated. Add me to that list. I prefer to avoid the extra bytes if possible. > > 4. If other end does not support NAT-T, do we allow other end still > > sending UDP encapsulated packets. > > > > (My answer would be NO) > > I agree with Tero -- I prefer that we do not use UDP-encap if no NAT > notify payloads were exchanged. Again, add me to that list. > > 5. If both ends do support NAT-T, but no NAT is detected, is the other > > end still allowed to send UDP encapsulated packets (MOBIKE mandates > > this). This is regardless whether we have floated to port 4500 or > > not. > > > > (My answer would be YES) > > I disagree with Tero. I would prefer that we do not allow UDP-encap if no > NAT was detected. The biggest concern that I have is that implementations > may have built UDP-encap support only into IPv4 paths, whereas this is a > statement that seems to apply to both IPv4 and IPv6. This is true in our > implementation; our IPv6 header processing does not support IPv6 > UDP-encap. So I would prefer to allow UDP-encap only when a NAT was > actually detected. I agree with Scott. I know MOBIKE mandates UDP encapsulation, but IIRC, MOBIKE has its own signalling/indicators for this as well, so just make the odd behavior happen only when indicated. > > 6. If the answer to 5 is YES, then how are reply packets sent out, > > plain ESP, or UDP encapsulated ESP, or either way (if the answer to > > question 5 is YES, then other end must accept them in either way > > anyways). > > > > (My answer would be SHOULD ESP or either way, ... > > While my answer to #5 is no, if the group consensus is yes, then my answer > to #6 is to agree with Tero -- I prefer SHOULD ESP and MAY UDP-encap. Agreed, but I'm opposed enough to a YES in #5 that I'd be writing my code with one hand, while the other holds my nose closed. Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 8 12:36: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 52C043A67F1; Mon, 8 Dec 2008 12:36:27 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552EF3A68DA; Mon, 8 Dec 2008 12:36:26 -0800 (PST) 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 qQzrKENm3AHU; Mon, 8 Dec 2008 12:36:24 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id 803853A6774; Mon, 8 Dec 2008 12:36:24 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB8KYnTo021754; Mon, 8 Dec 2008 13:34:49 -0700 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB8KZvBd231768; Mon, 8 Dec 2008 13:35:58 -0700 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id mB8KZu3v021964; Mon, 8 Dec 2008 13:35:56 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id mB8KZuSN021961; Mon, 8 Dec 2008 13:35:56 -0700 In-Reply-To: <18749.22433.463492.864413@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB950177@il-ex01.ad.checkpoint.com> <18749.22433.463492.864413@fireball.kivinen.iki.fi> To: Tero Kivinen MIME-Version: 1.0 X-KeepSent: 2226FC05:92A82152-85257519:006F1C45; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 12/08/2008 03:35:38 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 12/08/2008 03:35:38 PM, Serialize complete at 12/08/2008 03:35:38 PM, S/MIME Sign failed at 12/08/2008 03:35:38 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_10262008HFIGS1|October 26, 2008) at 12/08/2008 13:35:56, Serialize complete at 12/08/2008 13:35:56 Message-ID: Date: Mon, 8 Dec 2008 15:35:56 -0500 Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] #9: Notification when creation of CHILD_SA fails 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="===============1228148867==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1228148867== Content-Type: multipart/alternative; boundary="=_alternative 0071203085257519_=" This is a multipart message in MIME format. --=_alternative 0071203085257519_= Content-Type: text/plain; charset="US-ASCII" Tero writes: > The ticket also talks about the second case, where the IKE SA fails, > i.e. the case when IKE SA is not created, and we need to send error > message back about that. As I explained in my text there is no point > of encrypting that as it will not be authenticated anyways. We might > want to split this to two different tickets. I think that this response should be encrypted. The IKE_SA_INIT exchange constitutes an agreement to use certain algorithms to protect subsequent messages. Even if the peers cannot successfully authenticate one another, I think that encrypting the response is the right thing to do. Consider section 1.2 of the draft (and similar statements in RFCs 4306, 4718): . . . All messages following the initial exchange are cryptographically protected using the cryptographic algorithms and keys negotiated in the the IKE_SA_INIT exchange. . . . All subsequent messages include an Encrypted Payload, . . . . . . . . . The messages that follow [IKE_SA_INIT] are encrypted and integrity protected in their entirety . . . I think any existing IKEv2 implementation is going to make the assumption that the response in this case is encrypted, and just ignore a non-encrypted response. Moreover, having the response encrypted and HMACed is advantageous. Even if the peers are not authenticated, receiving an HMACed response at least proves that the message came from the peer we're talking to, so it allows the initiator to take immediate action without waiting for a plaintext response to be contradicted. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen To: Yaron Sheffer Cc: IPsecme WG Date: 12/08/2008 12:23 PM Subject: [IPsec] #9: Notification when creation of CHILD_SA fails Yaron Sheffer writes: > > same IP address. The initiator begins negotiation of a CHILD_SA > > using the SAi2 payload. The final fields (starting with SAi2) are > > described in the description of the CREATE_CHILD_SA exchange. > > > > <-- HDR, SK {IDr, [CERT,] AUTH, > > SAr2, TSi, TSr} > > > > The responder asserts its identity with the IDr payload, optionally > > sends one or more certificates (again with the certificate containing > > the public key used to verify AUTH listed first), authenticates its > > identity and protects the integrity of the second message with the > > AUTH payload, and completes negotiation of a CHILD_SA with the > > additional fields described below in the CREATE_CHILD_SA exchange. > > > > The recipients of messages 3 and 4 MUST verify that all signatures > > and MACs are computed correctly and that the names in the ID payloads > > correspond to the keys used to generate the AUTH payload. > > > > {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange > > fails for some reason, the IKE_SA is still created as usual. The > > list of responses in the IKE_AUTH exchange that do not prevent an > > IKE_SA from being set up include at least the following: > > NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, > > INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. > > Tero: In the case of the that kind of failure the return packet will then be > without the SAr2, Tsi, and TSr, i.e.: > > <-- HDR, SK {IDr, [CERT,] AUTH, > N(error_for_child_sa)} > > If the authentication fails in such ways that the entries cannot > create IKE SA (authentication failure or similar), then the response > will be unencrypted, unauthenticated notify. There is no point of > sending the notify encrypted and integrity protected, as it is not > authenticated (as initiator and responder have not yet verified the > AUTH payloads): > > <-- HDR, N(error_for_ike_sa) > > The initiator receiving such reply MUST NOT immediately stop the SA > creation, but it should still retransmit the message few times, in > case that error notify was forgery and the real responder will reply > with valid reply. It can use the recipient of such message as a hint > to tell that authentication failed, thus it can shorten the > retransmission timers from few minutes down to few tens of seconds. > > Paul: Not done. This is interesting, but should be discussed on the list. > > Room: Scenario: IKE SA creation proceeds immediately to first CHILD SA > creation. What if CHILD SA can't be created, but IKE SA is ok? Text should > make it clear that failure of CHILD SA creation should not tear down IKE SA > (e.g., avoids losing work to create the IKE SA based on guessing wrong about > a child traffic selector). > > Yaron: seems to me the ticket discusses one thing (IKE SA creation > fails because of bad authentication), while the room's discussion is > about a different thing (IKE SA successful). Comments on the > original ticket are welcome. The ticket actually has two cases, the most important one is that first part, i.e. where it says that we need to explicitly describe the case where the IPsec SA creation fails, but IKE SA creation succeeds. The clarification already says that, but I think we could add explicit example messages out of that. The ticket also talks about the second case, where the IKE SA fails, i.e. the case when IKE SA is not created, and we need to send error message back about that. As I explained in my text there is no point of encrypting that as it will not be authenticated anyways. We might want to split this to two different tickets. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0071203085257519_= Content-Type: text/html; charset="US-ASCII"
Tero writes:
> The ticket also talks about the second case, where the IKE SA fails,
> i.e. the case when IKE SA is not created, and we need to send error
> message back about that. As I explained in my text there is no point
> of encrypting that as it will not be authenticated anyways. We might
> want to split this to two different tickets.

I think that this response should be encrypted.  The IKE_SA_INIT exchange constitutes an agreement to use certain algorithms to protect subsequent messages.  Even if the peers cannot successfully authenticate one another, I think that encrypting the response is the right thing to do.  Consider section 1.2 of the draft (and similar statements in RFCs 4306, 4718):

   . . . All messages following the initial exchange are cryptographically
   protected using the cryptographic algorithms and keys negotiated in
   the the IKE_SA_INIT exchange. . . .  All
   subsequent messages include an Encrypted Payload, . . .

   . . .

   . . . The messages that
   follow [IKE_SA_INIT] are encrypted and integrity protected in their entirety
   . . .

I think any existing IKEv2 implementation is going to make the assumption that the response in this case is encrypted, and just ignore a non-encrypted response.  Moreover, having the response encrypted and HMACed is advantageous.  Even if the peers are not authenticated, receiving an HMACed response at least proves that the message came from the peer we're talking to, so it allows the initiator to take immediate action without waiting for a plaintext response to be contradicted.


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


From: Tero Kivinen <kivinen@iki.fi>
To: Yaron Sheffer <yaronf@checkpoint.com>
Cc: IPsecme WG <ipsec@ietf.org>
Date: 12/08/2008 12:23 PM
Subject: [IPsec]  #9: Notification when creation of CHILD_SA fails




Yaron Sheffer writes:
> >     same IP address.  The initiator begins negotiation of a CHILD_SA
> >     using the SAi2 payload.  The final fields (starting with SAi2) are
> >     described in the description of the CREATE_CHILD_SA exchange.
> >
> >                                  <--  HDR, SK {IDr, [CERT,] AUTH,
> >                                           SAr2, TSi, TSr}
> >
> >     The responder asserts its identity with the IDr payload, optionally
> >     sends one or more certificates (again with the certificate containing
> >     the public key used to verify AUTH listed first), authenticates its
> >     identity and protects the integrity of the second message with the
> >     AUTH payload, and completes negotiation of a CHILD_SA with the
> >     additional fields described below in the CREATE_CHILD_SA exchange.
> >
> >     The recipients of messages 3 and 4 MUST verify that all signatures
> >     and MACs are computed correctly and that the names in the ID payloads
> >     correspond to the keys used to generate the AUTH payload.
> >
> >     {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange
> >     fails for some reason, the IKE_SA is still created as usual.  The
> >     list of responses in the IKE_AUTH exchange that do not prevent an
> >     IKE_SA from being set up include at least the following:
> >     NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
> >     INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
>  
> Tero: In the case of the that kind of failure the return packet will then be
> without the SAr2, Tsi, and TSr, i.e.:
>  
>                                  <--  HDR, SK {IDr, [CERT,] AUTH,
>                                           N(error_for_child_sa)}
>  
> If the authentication fails in such ways that the entries cannot
> create IKE SA (authentication failure or similar), then the response
> will be unencrypted, unauthenticated notify. There is no point of
> sending the notify encrypted and integrity protected, as it is not
> authenticated (as initiator and responder have not yet verified the
> AUTH payloads):
>  
>                                  <--  HDR, N(error_for_ike_sa)
>  
> The initiator receiving such reply MUST NOT immediately stop the SA
> creation, but it should still retransmit the message few times, in
> case that error notify was forgery and the real responder will reply
> with valid reply. It can use the recipient of such message as a hint
> to tell that authentication failed, thus it can shorten the
> retransmission timers from few minutes down to few tens of seconds.
>  
> Paul: Not done. This is interesting, but should be discussed on the list.
>  
> Room: Scenario: IKE SA creation proceeds immediately to first CHILD SA
> creation.  What if CHILD SA can't be created, but IKE SA is ok?  Text should
> make it clear that failure of CHILD SA creation should not tear down IKE SA
> (e.g., avoids losing work to create the IKE SA based on guessing wrong about
> a child traffic selector).
>  
> Yaron: seems to me the ticket discusses one thing (IKE SA creation
> fails because of bad authentication), while the room's discussion is
> about a different thing (IKE SA successful). Comments on the
> original ticket are welcome.

The ticket actually has two cases, the most important one is that
first part, i.e. where it says that we need to explicitly describe
the case where the IPsec SA creation fails, but IKE SA creation
succeeds. The clarification already says that, but I think we could
add explicit example messages out of that.

The ticket also talks about the second case, where the IKE SA fails,
i.e. the case when IKE SA is not created, and we need to send error
message back about that. As I explained in my text there is no point
of encrypting that as it will not be authenticated anyways. We might
want to split this to two different tickets.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 0071203085257519_=-- --===============1228148867== 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 --===============1228148867==-- From ipsec-bounces@ietf.org Mon Dec 8 13:16: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 D7E433A697E; Mon, 8 Dec 2008 13:16:36 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 797AE3A697E; Mon, 8 Dec 2008 13:16:35 -0800 (PST) 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 8u2kGiOJumek; Mon, 8 Dec 2008 13:16:34 -0800 (PST) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by core3.amsl.com (Postfix) with ESMTP id C36693A696E; Mon, 8 Dec 2008 13:16:30 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB8LF0qc014819; Mon, 8 Dec 2008 14:15:00 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB8LGN2S199530; Mon, 8 Dec 2008 14:16:23 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB8LGMFp018973; Mon, 8 Dec 2008 14:16:22 -0700 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mB8LGM3L018966; Mon, 8 Dec 2008 14:16:22 -0700 In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017C@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017C@il-ex01.ad.checkpoint.com> To: Yaron Sheffer MIME-Version: 1.0 X-KeepSent: BF222F02:0E7A425D-85257519:0071F02B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 12/08/2008 04:15:38 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.1 HF105|April 10, 2008) at 12/08/2008 04:15:38 PM, Serialize complete at 12/08/2008 04:15:38 PM, S/MIME Sign failed at 12/08/2008 04:15:38 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Build V85_10262008HFIGS1|October 26, 2008) at 12/08/2008 14:16:22, Serialize complete at 12/08/2008 14:16:22 Message-ID: Date: Mon, 8 Dec 2008 16:16:22 -0500 Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] #30: Conflicts in DH proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1433617532==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1433617532== Content-Type: multipart/alternative; boundary="=_alternative 0074C9F685257519_=" This is a multipart message in MIME format. --=_alternative 0074C9F685257519_= Content-Type: text/plain; charset="US-ASCII" We already allow flexibility in expressing proposals; i.e., P=(AES256,{SHA1|MD5}) is equivalent to (P1=(AES256,SHA1), P2=(AES256,MD5)) and neither is prohibited by the RFCs. I think this should lead us to explicitly extend the flexibility to DH groups. In fact, I had assumed from my reading of the RFCs that this was already allowed implicitly. If we are to add any explicit text for this issue, I would advocate that we: 1) Explicitly allow for multiple proposals with distinct sets of DH groups. 2) For the case where a responder chooses a set of transforms from a proposal, and where the chosen DH transform does not match the KE payload, explicitly specify that the responder should respond with N(INVALID_KE_PAYLOAD) based on the DH group that the responder would have chosen from the given proposals. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: IPsecme WG Date: 12/07/2008 01:28 PM Subject: [IPsec] #30: Conflicts in DH proposals Tero: One of the questions that have been out long time, is that do all of the offered proposals must have identical Diffie-Hellman group lists. What does it mean if one of the proposals have different list than some other proposal. Can the KE payload include then be from such group that only exists in one of the lists. Also do the Diffie-Hellman groups need to be repeated on every single proposal. I think we should add some text explaining that. Room: This may be missing functionality involving how an endpoint deals with a KE payload that is wrong for the selected proposal. Charlie Kaufman: Should always start with stronger KE payload, there is text on this, but can benefit from clarification.[attachment "smime.p7s" deleted by Scott C Moonen/Raleigh/IBM] _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0074C9F685257519_= Content-Type: text/html; charset="US-ASCII"
We already allow flexibility in expressing proposals; i.e., P=(AES256,{SHA1|MD5}) is equivalent to (P1=(AES256,SHA1), P2=(AES256,MD5)) and neither is prohibited by the RFCs.  I think this should lead us to explicitly extend the flexibility to DH groups.  In fact, I had assumed from my reading of the RFCs that this was already allowed implicitly.  If we are to add any explicit text for this issue, I would advocate that we:

1) Explicitly allow for multiple proposals with distinct sets of DH groups.
2) For the case where a responder chooses a set of transforms from a proposal, and where the chosen DH transform does not match the KE payload, explicitly specify that the responder should respond with N(INVALID_KE_PAYLOAD) based on the DH group that the responder would have chosen from the given proposals.


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


From: Yaron Sheffer <yaronf@checkpoint.com>
To: IPsecme WG <ipsec@ietf.org>
Date: 12/07/2008 01:28 PM
Subject: [IPsec] #30: Conflicts in DH proposals




Tero: One of the questions that have been out long time, is that do all of the offered proposals must have identical Diffie-Hellman group lists. What does it mean if one of the proposals have different list than some other proposal. Can the KE payload include then be from such group that only exists in one of the lists. Also do the Diffie-Hellman groups need to be repeated on every single proposal.

I think we should add some text explaining that.
Room: This may be missing functionality involving how an endpoint deals with a KE payload that is wrong for the selected proposal. Charlie Kaufman: Should always start with stronger KE payload, there is text on this, but can benefit from clarification.[attachment "smime.p7s" deleted by Scott C Moonen/Raleigh/IBM] _______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--=_alternative 0074C9F685257519_=-- --===============1433617532== 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 --===============1433617532==-- From ipsec-bounces@ietf.org Mon Dec 8 13:23: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 805673A69D3; Mon, 8 Dec 2008 13:23:51 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0EEE3A69D3 for ; Mon, 8 Dec 2008 13:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-0.023, 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 Wvuq80aQ3U-Y for ; Mon, 8 Dec 2008 13:23:49 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 22D1F3A687B for ; Mon, 8 Dec 2008 13:23:49 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id CFF8B29C003; Mon, 8 Dec 2008 23:23:42 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 7EF3829C001 for ; Mon, 8 Dec 2008 23:23:01 +0200 (IST) X-CheckPoint: {493D8F47-10004-88241DC2-7B6} Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id mB8LN1fF014614 for ; Mon, 8 Dec 2008 23:23:01 +0200 (IST) Message-Id: <8ADA5BBD-2BC8-4997-91EB-2BB584963EB4@checkpoint.com> From: Yoav Nir To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017C@il-ex01.ad.checkpoint.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 8 Dec 2008 23:22:53 +0200 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017C@il-ex01.ad.checkpoint.com> X-Mailer: Apple Mail (2.929.2) Cc: IPsecme WG Subject: Re: [IPsec] #30: Conflicts in DH proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1535873109==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1535873109== Content-Type: multipart/alternative; boundary=Apple-Mail-2--791413547 --Apple-Mail-2--791413547 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Dec 7, 2008, at 5:09 PM, Yaron Sheffer wrote: > Tero: One of the questions that have been out long time, is that do > all of the offered proposals must have identical Diffie-Hellman > group lists. What does it mean if one of the proposals have > different list than some other proposal. Can the KE payload include > then be from such group that only exists in one of the lists. Also > do the Diffie-Hellman groups need to be repeated on every single > proposal. > > I think we should add some text explaining that. > > Room: This may be missing functionality involving how an endpoint > deals with a KE payload that is wrong for the selected proposal. > Charlie Kaufman: Should always start with stronger KE payload, there > is text on this, but can benefit from clarification. I don't think we should mandate that all proposals share the same set of D-H groups. I suggest replacing the following text from section 3.4: The DH Group # identifies the Diffie-Hellman group in which the Key Exchange Data was computed (see Section 3.3.2). If the selected proposal uses a different Diffie-Hellman group (other than NONE), the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD. with this: The DH Group # identifies the Diffie-Hellman group in which the Key Exchange Data was computed (see Section 3.3.2). This Group # MUST match a DH Group specified in a proposal in the SA payload that is sent in the same message, and SHOULD match the strongest DH Group in any of the proposals of that SA payload. If none of the proposals in that SA payload specifies a DH Group, the KE payload MUST NOT be present. If the selected proposal uses a different Diffie-Hellman group (other than NONE), the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD. Email secured by Check Point --Apple-Mail-2--791413547 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

On Dec 7, 2008, at = 5:09 PM, Yaron Sheffer wrote:

Tero: One of the = questions that have been out long time, is that do all of the offered = proposals must have identical Diffie-Hellman group lists. What does it = mean if one of the proposals have different list than some other = proposal. Can the KE payload include then be from such group that only = exists in one of the lists. Also do the Diffie-Hellman groups need to be = repeated on every single proposal.

I think we should add some text explaining = that.

Room: This =
may be missing functionality involving how an endpoint deals with a KE =
payload that is wrong for the selected proposal. Charlie Kaufman: Should =
always start with stronger KE payload, there is text on this, but can =
benefit from =
clarification.

<= div>I don't think we should mandate that all proposals share the same = set of D-H groups. 

I suggest replacing = the following text from section 3.4:

The DH Group # = identifies the Diffie-Hellman group in which the Key Exchange Data was computed (see Section 3.3.2). If the selected proposal uses a different Diffie-Hellman group (other than NONE), the message MUST be rejected with a Notify payload of type INVALID_KE_PAYLOAD.
   The DH Group # =
identifies the Diffie-Hellman group in which the Key
   Exchange Data was computed (see Section 3.3.2).  This Group # MUST 
   match a DH Group =
specified in a proposal in the SA payload that is
   sent in the same =
message, and SHOULD match the strongest DH Group
   in any of the proposals =
of that SA payload. If none of the proposals
   in that SA payload =
specifies a DH Group, the KE payload MUST NOT be
   present. If the =
selected proposal uses a different Diffie-Hellman 
   group (other than =
NONE), the message MUST be rejected with a Notify 
   payload of type =
INVALID_KE_PAYLOAD.


= =0D=0A
Email secured by Check Point=0D=0A

= = --Apple-Mail-2--791413547-- --===============1535873109== 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 --===============1535873109==-- From ipsec-bounces@ietf.org Mon Dec 8 13:34: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 48CE73A68DA; Mon, 8 Dec 2008 13:34:47 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2FE3A68DA for ; Mon, 8 Dec 2008 13:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opDSvb1kBvF0 for ; Mon, 8 Dec 2008 13:34:45 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1FD053A67EA for ; Mon, 8 Dec 2008 13:34:45 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6818329C002; Mon, 8 Dec 2008 23:34:39 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 45E5829C001; Mon, 8 Dec 2008 23:34:38 +0200 (IST) X-CheckPoint: {493D9200-10000-88241DC2-7B6} Received: from [172.31.21.155] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mB8LYbfE017264; Mon, 8 Dec 2008 23:34:37 +0200 (IST) Message-Id: <52EAC942-5D9D-4EF0-8CA4-728D1E3BA4D2@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18749.22040.361182.649984@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 8 Dec 2008 23:34:37 +0200 References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> <79AA52D4-58CA-4656-A07A-233E19ED0C2F@checkpoint.com> <18749.22040.361182.649984@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Dec 8, 2008, at 7:15 PM, Tero Kivinen wrote: > Yoav Nir writes: >> I know the current RFC does not allow creating only an IKE SA, and >> that we're not going to add such an option to the -bis, but I believe >> that it would make the whole client thing more sensible. > > Or just remove the "connect" button, as it is not needed... And do not > even allow things like per port SAs, as those are not needed either > :-) I agree with that, but after 10 years of trying, our customers still refuse to see the light and use certificates, and insist on using things like SecurID. They really hated it when we didn't have a "Connect" button and all of a sudden an authentication dialog box popped up and asked for the tokencode. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 8 13:37: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 6E7043A6A8F; Mon, 8 Dec 2008 13:37:06 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0627A3A6A84 for ; Mon, 8 Dec 2008 13:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3w+Xq7oRIRx for ; Mon, 8 Dec 2008 13:37:04 -0800 (PST) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 454543A6A82 for ; Mon, 8 Dec 2008 13:37:04 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[198.18.173.171]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1L9nme-0000EY-Cj; Mon, 08 Dec 2008 16:36:53 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <18749.22040.361182.649984@fireball.kivinen.iki.fi> References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> <79AA52D4-58CA-4656-A07A-233E19ED0C2F@checkpoint.com> <18749.22040.361182.649984@fireball.kivinen.iki.fi> Date: Mon, 8 Dec 2008 14:36:17 -0500 To: Tero Kivinen From: Stephen Kent Cc: ipsec@ietf.org, Yoav Nir , Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 7:15 PM +0200 12/8/08, Tero Kivinen wrote: >Yoav Nir writes: >> I know the current RFC does not allow creating only an IKE SA, and >> that we're not going to add such an option to the -bis, but I believe >> that it would make the whole client thing more sensible. > >Or just remove the "connect" button, as it is not needed... And do not >even allow things like per port SAs, as those are not needed either >:-) > >(Yes, we do support per-host, port-protocol, per-port SAs mostly >because our QA would kill us if we removed them, as they are very >useful in the stress testing, i.e. like creating thousands SAs with >very few machines. On the other hand there is not usually that good >reasons for using them in real world, and they actually weaken the >security as they allow much easier traffic flow tracking than wider >SAs). >-- Tero, A few years ago some of my colleagues at BBN showed (through analysis of real traffic flows) that per-port SAs do not really offer better traffic flow confidentiality than coarser grained SAs. A per-port SA (or an SA that accommodates an enumerated set of ports) is useful when one wants crypto enforcement of per-port access controls. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 8 14:02: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 8B33F3A6AA3; Mon, 8 Dec 2008 14:02:50 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002753A6A73 for ; Mon, 8 Dec 2008 14:02:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 59myen1yYkxF for ; Mon, 8 Dec 2008 14:02:48 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id A12153A6950 for ; Mon, 8 Dec 2008 14:02:46 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 98D7329C001; Tue, 9 Dec 2008 00:02:40 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8B25529C002; Tue, 9 Dec 2008 00:01:54 +0200 (IST) X-CheckPoint: {493D9864-10004-88241DC2-7B6} Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id mB8M1sfH023213; Tue, 9 Dec 2008 00:01:54 +0200 (IST) Message-Id: <30166DB2-ED78-4957-AE7E-14FC58B52EF5@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18749.23518.256159.306659@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 9 Dec 2008 00:01:49 +0200 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017A@il-ex01.ad.checkpoint.com> <18749.23518.256159.306659@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: IPsecme WG Subject: Re: [IPsec] #40: Floating to port 4500 'by default', and use of UDP when no NAT detected X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Dec 8, 2008, at 7:39 PM, Tero Kivinen wrote: > > Other questions: > > 4. If other end does not support NAT-T, do we allow other end still > sending UDP encapsulated packets. > > (My answer would be NO) I agree, sort of. > 5. If both ends do support NAT-T, but no NAT is detected, is the other > end still allowed to send UDP encapsulated packets (MOBIKE mandates > this). This is regardless whether we have floated to port 4500 or > not. > > (My answer would be YES) I don't see the point of going to the trouble of detecting whether or not the NAT device is there, if you're going to do the UDP encapsulation anyway. If the implementation wants to use UDP encapsulation anyway, it can force NAT detection, for example by sending a string of zeros instead of a SHA-1 hash of its addresses and ports. I don't know if we want to document something like this in an RFC, as it would definitely cause Dan to hold his nose, but such an implementation would not need to actually support NAT detection, and would still traverse a NAT device. > 6. If the answer to 5 is YES, then how are reply packets sent out, > plain ESP, or UDP encapsulated ESP, or either way (if the answer to > question 5 is YES, then other end must accept them in either way > anyways). > > (My answer would be SHOULD ESP or either way, as that is what MOBIKE > assumes, as after the IP-address change from behind NAT to address not > behind NAT, we still might receive few UDP encapsulated packets before > the other end realizes the situation, but if we make both ends to > reply using same encapsulation this will not be resolved, but we keep > on going with UDP encapsulation forever.) I agree. If you detected that there is no NAT, don't do it (unless you can't do ESP, because you're a user-space client with not enough privileges to open a raw socket) Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 8 14:22: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 867BA3A6AAB; Mon, 8 Dec 2008 14:22:23 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C0ED3A6AAD for ; Mon, 8 Dec 2008 14:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvTSZ+1TGZyA for ; Mon, 8 Dec 2008 14:22:21 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 8B1373A6AAB for ; Mon, 8 Dec 2008 14:22:21 -0800 (PST) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mB8MMFEL027506 for ; Mon, 8 Dec 2008 22:22:16 GMT Received: from everywhere.east.sun.com (everywhere.East.Sun.COM [129.148.19.2]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id mB8MMFur051676 for ; Mon, 8 Dec 2008 17:22:15 -0500 (EST) Received: from everywhere.east.sun.com (localhost [127.0.0.1]) by everywhere.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id mB8LqDFT010981; Mon, 8 Dec 2008 16:52:13 -0500 (EST) Received: (from danmcd@localhost) by everywhere.east.sun.com (8.14.3+Sun/8.14.3/Submit) id mB8Lq3cc010980; Mon, 8 Dec 2008 16:52:03 -0500 (EST) X-Authentication-Warning: everywhere.east.sun.com: danmcd set sender to danmcd@sun.com using -f Date: Mon, 8 Dec 2008 16:52:03 -0500 From: Dan McDonald To: Stephen Kent Message-ID: <20081208215203.GS8258@sun.com> References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> <79AA52D4-58CA-4656-A07A-233E19ED0C2F@checkpoint.com> <18749.22040.361182.649984@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Organization: Sun Microsystems, Inc. - Solaris Networking & Security User-Agent: Mutt/1.5.17 (2007-11-01) Cc: ipsec@ietf.org, Yoav Nir , Vijay Devarapalli , Tero Kivinen Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Mon, Dec 08, 2008 at 02:36:17PM -0500, Stephen Kent wrote: > A few years ago some of my colleagues at BBN showed (through analysis of > real traffic flows) that per-port SAs do not really offer better traffic > flow confidentiality than coarser grained SAs. A per-port SA (or an SA that > accommodates an enumerated set of ports) is useful when one wants crypto > enforcement of per-port access controls. OTOH, It's useful if your networking hardware has receive-rings which key off of the offset where TCP/UDP ports live AND where the IPsec SPI lives. If I have SAs per flow, I can have my 10Gig hardware demux them to different CPU cores. If my cores have dedicated crypto units... well, you see where this is going. :) Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From jeanbern5@amcham.ch Mon Dec 8 14:53:25 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 230653A6A92 for ; Mon, 8 Dec 2008 14:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.003 X-Spam-Level: X-Spam-Status: No, score=-23.003 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_EQ_DSL=1.129, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, J_CHICKENPOX_62=0.6, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, 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 PUsNcRTW1dAF for ; Mon, 8 Dec 2008 14:53:24 -0800 (PST) Received: from athedsl-68484.home.otenet.gr (athedsl-68484.home.otenet.gr [87.203.148.210]) by core3.amsl.com (Postfix) with SMTP id 488223A69AC for ; Mon, 8 Dec 2008 14:53:22 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081208225323.488223A69AC@core3.amsl.com> Date: Mon, 8 Dec 2008 14:53:22 -0800 (PST)
Click Here!

Little time left till the end of our offer!



found room and flashed a shot towards the bottom corner,he left the pitch and was replaced by Alan Smith, who
She got to meet the PM and was quoted saying: "Not a lotAfter nearly signing with United, From legolas@adams.net Mon Dec 8 15:39:13 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48973A6ABC for ; Mon, 8 Dec 2008 15:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.797 X-Spam-Level: X-Spam-Status: No, score=-15.797 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_UK=1.749, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTril8aapJIV for ; Mon, 8 Dec 2008 15:39:12 -0800 (PST) Received: from accountancyselection.co.uk (unknown [216.70.142.80]) by core3.amsl.com (Postfix) with SMTP id 2A84B3A687B for ; Mon, 8 Dec 2008 15:39:11 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081208233912.2A84B3A687B@core3.amsl.com> Date: Mon, 8 Dec 2008 15:39:11 -0800 (PST)
Click Here!

This offer is valid only for a limited time period, so hurry up!



Post, when the nations drug control policies better reflect the idealsUgandan judges end a week long strike after President
a unique position, he noted in The Chronicle of Philanthropy in its Septemberreason for others to mistrust him, or to be suspicious of him. From ipsec-bounces@ietf.org Tue Dec 9 04:41: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 6FC6F3A6B0C; Tue, 9 Dec 2008 04:41:53 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02353A6B06 for ; Tue, 9 Dec 2008 04:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 jaBg2VE+mpn9 for ; Tue, 9 Dec 2008 04:41:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A985F3A6883 for ; Tue, 9 Dec 2008 04:41:50 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB9CfTkH001632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 14:41:29 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB9CfShw005156; Tue, 9 Dec 2008 14:41:28 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18750.26488.154253.674238@fireball.kivinen.iki.fi> Date: Tue, 9 Dec 2008 14:41:28 +0200 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017A@il-ex01.ad.checkpoint.com> <18749.23518.256159.306659@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 177 min Cc: IPsecme WG Subject: Re: [IPsec] #40: Floating to port 4500 'by default', and use of UDP when no NAT detected X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Scott C Moonen writes: > Some replies to Yaron and Tero: > > Tero says: > > Note, that client (or server) can trivially fake NAT to be on the > > path, by just sending incorrect NAT_DETECTION_*_IP payloads. This will > > cause both ends to enable UDP encapsulation. > > True, but I think we should strongly recommend against that practice, > because there can be subtle problems in some cases (especially double NATs > or gateways located behind NATs). For example, if a security gateway > falsely represents itself as being behind a NAT, it is implying that the > entire address space behind it is private, which is not the case. A peer > initiating to it then has a dilemma in choosing which address to place in > TSr, or even wondering whether it has enough information to choose an > appropriate TSr at all. I agree that this is not something that should be encouraged, but there were some people who said they enabled UDP encapsulation always as they saw that UDP packets passed firewalls and such better than plain ESP packets. On the other hand quite a lot of those firewalls already has NAT. This is usually something that only the client wants to do, i.e. when you are initiating and you know you might be behind some firewalls or such that might stop ESP packets, then you can fake that your are behind NAT to enable UDP encapsulation. I do not really see reason for server to fake that he is behind NAT. > > 5. If both ends do support NAT-T, but no NAT is detected, is the other > > end still allowed to send UDP encapsulated packets (MOBIKE mandates > > this). This is regardless whether we have floated to port 4500 or > > not. > > > > (My answer would be YES) > > I disagree with Tero. I would prefer that we do not allow UDP-encap if no > NAT was detected. The biggest concern that I have is that implementations > may have built UDP-encap support only into IPv4 paths, whereas this is a > statement that seems to apply to both IPv4 and IPv6. This is true in our > implementation; our IPv6 header processing does not support IPv6 > UDP-encap. So I would prefer to allow UDP-encap only when a NAT was > actually detected. I really didn't think about this for IPv6 address point of view, but I do not think that changes the situation that much. The MOBIKE already mandates this so if you ever are going to implement MOBIKE you need to implement this. In our case the UDP encpasulation is checked in the generic code, so it is not IPv4 or IPv6 specific code, but code that is run regardless of the address family. The reason for allowing both UDP encapsulated and non-encapsulated packets when RECEIVING data is that it would be consistent with the be liberal what you accept principle, and I do not think it adds too much compexity to the incoming packet processing. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 9 05:00: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 C89693A69AD; Tue, 9 Dec 2008 05:00:11 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EBBB3A69AD for ; Tue, 9 Dec 2008 05:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 WlDc02O9gluz for ; Tue, 9 Dec 2008 05:00:09 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5D7843A67F9 for ; Tue, 9 Dec 2008 05:00:09 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB9D02RP005238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 15:00:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB9D01RY005084; Tue, 9 Dec 2008 15:00:01 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18750.27601.839649.300185@fireball.kivinen.iki.fi> Date: Tue, 9 Dec 2008 15:00:01 +0200 From: Tero Kivinen To: Dan McDonald In-Reply-To: <20081208200603.GM8258@sun.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017A@il-ex01.ad.checkpoint.com> <18749.23518.256159.306659@fireball.kivinen.iki.fi> <20081208200603.GM8258@sun.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 18 min Cc: ipsec@ietf.org Subject: Re: [IPsec] #40: Floating to port 4500 'by default', and use of UDP when no NAT detected X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dan McDonald writes: > Start at 4500, stay at 4500? Why not? (I'm also assuming this is IKEv2 > only, not needed for retrofitting onto IKEv1...) Yes, we are only discussing IKEv2 here (altough IKEv1 RFC3947 did mandate same thing, i.e. start at 4500 and stay at 4500 at section 4: "Any implementation that supports NAT traversal MUST support negotiations that begin on port 4500."). > > > 5. If both ends do support NAT-T, but no NAT is detected, is the other > > > end still allowed to send UDP encapsulated packets (MOBIKE mandates > > > this). This is regardless whether we have floated to port 4500 or > > > not. > > > > > > (My answer would be YES) > > > > I disagree with Tero. I would prefer that we do not allow UDP-encap if no > > NAT was detected. The biggest concern that I have is that implementations > > may have built UDP-encap support only into IPv4 paths, whereas this is a > > statement that seems to apply to both IPv4 and IPv6. This is true in our > > implementation; our IPv6 header processing does not support IPv6 > > UDP-encap. So I would prefer to allow UDP-encap only when a NAT was > > actually detected. > > I agree with Scott. I know MOBIKE mandates UDP encapsulation, but IIRC, > MOBIKE has its own signalling/indicators for this as well, so just make the > odd behavior happen only when indicated. We did have some support cases related to that, as I think there was some customer complaining that some other vendor sent them UDP encapsulated packets even when we didn't detect NAT, and our old versions (before MOBIKE) dropped those. I think we even backported the patch to the customer to allow receiving UDP encapsulated packets even when no NAT was seen. And yes, MOBIKE do have its own signalling etc thus we do not need to keep base IKEv2 and MOBIKE IKEv2 identical in this sense, but I would rather keep the changes as small as possible... -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 9 05:17: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 40A673A6883; Tue, 9 Dec 2008 05:17:04 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 820E03A67F9 for ; Tue, 9 Dec 2008 05:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+Nwd-rLx3qi for ; Tue, 9 Dec 2008 05:17:01 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6C35E3A67AA for ; Tue, 9 Dec 2008 05:17:01 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mB9DBmKr005203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2008 15:11:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mB9DBmZq002144; Tue, 9 Dec 2008 15:11:48 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18750.28308.704.651625@fireball.kivinen.iki.fi> Date: Tue, 9 Dec 2008 15:11:48 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <8ADA5BBD-2BC8-4997-91EB-2BB584963EB4@checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017C@il-ex01.ad.checkpoint.com> <8ADA5BBD-2BC8-4997-91EB-2BB584963EB4@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: IPsecme WG Subject: Re: [IPsec] #30: Conflicts in DH proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > I don't think we should mandate that all proposals share the same set > of D-H groups. I can accept that... > The DH Group # identifies the Diffie-Hellman group in which the Key > Exchange Data was computed (see Section 3.3.2). This Group # MUST > match a DH Group specified in a proposal in the SA payload that is > sent in the same message, and SHOULD match the strongest DH Group > in any of the proposals of that SA payload. If none of the proposals > in that SA payload specifies a DH Group, the KE payload MUST NOT be > present. If the selected proposal uses a different Diffie-Hellman > group (other than NONE), the message MUST be rejected with a Notify > payload of type INVALID_KE_PAYLOAD. I do not think we can add new "SHOULD" in this time, i.e. I would remove the ", and SHOULD match the strongest DH Group in any of the proposals of that SA payload" part. There are problems to define stength order for different Diffie-Hellman groups, especially if they use different methods, i.e. some use elliptic curves and some are MODP groups. Otherwise the text looks good. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 9 05:30: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 506943A6B28; Tue, 9 Dec 2008 05:30:07 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2613A6B28 for ; Tue, 9 Dec 2008 05:30:06 -0800 (PST) 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 0-5oLFuW0k4A for ; Tue, 9 Dec 2008 05:30:05 -0800 (PST) Received: from strongswan.org (sidv0150.hsr.ch [152.96.52.150]) by core3.amsl.com (Postfix) with ESMTP id 273D03A6B25 for ; Tue, 9 Dec 2008 05:30:05 -0800 (PST) Received: from [152.96.15.212] (unknown [152.96.15.212]) by strongswan.org (Postfix) with ESMTP id BC97EEF971 for ; Tue, 9 Dec 2008 14:30:01 +0100 (CET) Message-ID: <493E72D4.8070908@strongswan.org> Date: Tue, 09 Dec 2008 14:29:56 +0100 From: Martin Willi User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: IPsecme WG References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017A@il-ex01.ad.checkpoint.com> <18749.23518.256159.306659@fireball.kivinen.iki.fi> In-Reply-To: <18749.23518.256159.306659@fireball.kivinen.iki.fi> Subject: Re: [IPsec] #40: Floating to port 4500 'by default', and use of UDP when no NAT detected X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, > UDP encap can get IKEv2 through a firewall that only allows UDP and TCP. > This is a reason to always use UDP encap, even if no NAT detected. Yes, I've seen such firewall configurations more than once... > Note, that client (or server) can trivially fake NAT to be on the > path, by just sending incorrect NAT_DETECTION_*_IP payloads. This will > cause both ends to enable UDP encapsulation. ... and is the reason I've implemented exactly that. The question is if we should write this down. We additionally could suggest a fixed value, so the peer has a hint that we are enforcing UDP encapsulation. But this probably goes too far. > 1. Do we allow to float immediately into port 4500, e.g. to have port > 4500-only originators? I think this is problematic. Existing implementation might not tolerate such a behavior, even if they should. We already had interoperability problems when we introduced MOBIKE and switched to 4500 in the second exchange. > 4. If other end does not support NAT-T, do we allow other end still > sending UDP encapsulated packets. I don't see a reason to drop packets depending on their encapsulation mode. But without NAT-T support, it makes no sense to encapsulate packets, as a peer can't enforce me to do the same. So, I would give it a NO. > 5. If both ends do support NAT-T, but no NAT is detected, is the other > end still allowed to send UDP encapsulated packets (MOBIKE mandates > this). This is regardless whether we have floated to port 4500 or > not. Yes, but > The biggest concern that I have is that implementations may have built > UDP-encap support only into IPv4 paths, whereas this is a statement > that seems to apply to both IPv4 and IPv6. this is actually a problem (and one I'll have to fix, too). The question is if "NAT-T support" is family specific (it is not with MOBIKE). I would go for a YES to have a consistent rule for MOBIKE and non-MOBIKE implementations. > 6. If the answer to 5 is YES, then how are reply packets sent out, > plain ESP, or UDP encapsulated ESP, or either way (if the answer to > question 5 is YES, then other end must accept them in either way > anyways). > (My answer would be SHOULD ESP or either way, as that is what MOBIKE > assumes, as after the IP-address change from behind NAT to address not > behind NAT, we still might receive few UDP encapsulated packets before > the other end realizes the situation, but if we make both ends to > reply using same encapsulation this will not be resolved, but we keep > on going with UDP encapsulation forever.) Agree. Regards Martin _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From olp@alhamaco.com Tue Dec 9 13:04:53 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE32228C197 for ; Tue, 9 Dec 2008 13:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.347 X-Spam-Level: X-Spam-Status: No, score=-9.347 tagged_above=-999 required=5 tests=[BAYES_80=2, DNS_FROM_RFC_BOGUSMX=1.482, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hzn+y2fQ3URb for ; Tue, 9 Dec 2008 13:04:53 -0800 (PST) Received: from alicorp.com.pe (unknown [64.146.120.194]) by core3.amsl.com (Postfix) with SMTP id 6C05528C192 for ; Tue, 9 Dec 2008 13:04:52 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081209210452.6C05528C192@core3.amsl.com> Date: Tue, 9 Dec 2008 13:04:52 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Tue Dec 9 15:11: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 DDCA13A6A0B; Tue, 9 Dec 2008 15:11:45 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BBC93A6A5E for ; Tue, 9 Dec 2008 15:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_12=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 8cEq4oS5cMD4 for ; Tue, 9 Dec 2008 15:11:43 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id C091F3A68D3 for ; Tue, 9 Dec 2008 15:11:41 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 548203FE0156; Tue, 9 Dec 2008 15:11:36 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 9 Dec 2008 15:11:36 -0800 (PST) Message-ID: <64a056e13ae1fe2907d71f072ac96489.squirrel@www.trepanning.net> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017D@il-ex01.ad.checkpoint.com> Date: Tue, 9 Dec 2008 15:11:36 -0800 (PST) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 X-Priority: 3 (Normal) Importance: Normal Cc: IPsecme WG Subject: Re: [IPsec] #55: Exponential reuse - reference 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 Yaron, I think the notes on this discussion missed something. If you multiply the old exponential by g mod p the generated keys will be different regardless of the nonces. g^x and g^y gives g^xy, g^(x+1) and g^(y+1) gives g^(xy+x+y+1) which will be quite different. The resulting keys will be random to an attacker but will be related, and that's where the problem arises. "How to do it securely" depends on what kind of security you're talking about. It appears that a scheme that reuses D-H exponentials in this way can achieve IND-CPA-- indistinguishable under a chosen plaintext attack. That is, I believe, the weakest security notion based on the theorem of Bellare, Desai, Pointcheval, and Rogaway. I don't know whether IKEv2 has been proven secure under any security notion but I think if it can be proven to be IND-CPA then reusing Diffie-Hellman exponentials in this way will not weaken its security. If it's proven to be secure against a stronger notion then reusing Diffie-Hellman exponentials will weaken it to IND-CPA. (NB: I am not a cryptographer). As far as a reference is concerned, there is a nice discussion of this in section 4.3.0.2 of "Just Fast Keying: Key Agreement in a Hostile Environment", Aiello et al, ACM Transactions on Information and System Security, Vol. 7, No. 2, May 2004. Dan. On Sun, December 7, 2008 7:09 am, Yaron Sheffer wrote: > Yaron: 2.12: Exponential reuse - can we give a reference on how to do it > securely? > > > > Room: Does anyone have a reference? There may be a minor change involving > multiplying old exponential by g (mod p) to produce a different > exponential. > When exponential reused, nonces force > generated keys to be different. The request is for an external crypto or > security analysis reference on this topic. > > > [This is obviously still open - Yaron]. > > _______________________________________________ > 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 Dec 9 17:10:44 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 565213A67F4; Tue, 9 Dec 2008 17:10:44 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68C903A67F4 for ; Tue, 9 Dec 2008 17:10:43 -0800 (PST) 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 e8-xgZbghHhN for ; Tue, 9 Dec 2008 17:10:42 -0800 (PST) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 445AF3A67A8 for ; Tue, 9 Dec 2008 17:10:42 -0800 (PST) Received: by yx-out-2324.google.com with SMTP id 8so127280yxg.49 for ; Tue, 09 Dec 2008 17:10:35 -0800 (PST) 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=/z0UNB/sxRsPAXf2QMTcfH3ySARJy9S/BM7qgJ7Jqm4=; b=hhUQ4HM5CHy5K5GpzxDmqjnLy//emPkQ2Q+Uh1eoeAbdKVtcipOO/xS4agsjLaP+9p sjxhr1Y0AVQ8SRVvHXo0CmthWKs2DlmwZy9zXo6falp2rWHzxE4pEHxM4eU/LVNL7y2K vOv1StIMLf7u8tMNzCgC1ON27tymOdOFnWaBU= 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=OmrsmjcIKlbI4VWlTxcsBXMSAuKEzzaSRlOKfcljADKhXq/rg8smJU5HVTAJOLVboL OLfZPnXKa+BzzpHQ5K/Cf7rSFOLUbYEXdDZF5WDk3LbDyJcaFQy+Uo5PJfvbDWj7UB8f 1YzL4sQudsSzxFwMykMnYreNPbFFk+H1urZdw= Received: by 10.114.167.10 with SMTP id p10mr533899wae.198.1228871421107; Tue, 09 Dec 2008 17:10:21 -0800 (PST) Received: by 10.142.178.3 with HTTP; Tue, 9 Dec 2008 17:10:20 -0800 (PST) Message-ID: Date: Tue, 9 Dec 2008 17:10:20 -0800 From: "Vijay Devarapalli" To: "fan zhao" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Fan, On Wed, Dec 3, 2008 at 11:05 AM, fan zhao wrote: > Hi Tero, > > Thanks for your reply. > If you do not mind, I will call redirection in the last message > during the IKE_AUTH as "redirect_auth" and redirection during > the separate informational exchange as "redirect_info" in the following text. > > On Wed, Dec 3, 2008 at 4:51 AM, Tero Kivinen wrote: >> fan zhao writes: >>> 2) The IPsec client requests to set up the child SA during IKE_AUTH >>> client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH SAi2, TSi, TSr} >> >> If we want to allow redirection during the IKE_AUTH, I think this >> second option is the one we want to select. This would be identical to >> normal exchange, thus it will cause smaller changes, and it has good >> property that if server does NOT do redirect we get the IPsec SA done >> after this. > I think this property is also supported by the redirect_auth since if > the IPsec server does not want to do redirect, it simply does not include > the Redirect payload. > >> In any cause we MUST NOT define two different ways how to >> do this, as that would just add unnessary complexity. So if we are >> going to select one, lets select this one. > This is always a good principle to follow in general. However, in this case, my > understanding is that the redirect_auth and the redirect_info address > different needs. For example, when an IPsec server serving IPsec clients > realizes that it is overloaded or it needs to shut down for > administration reasons, > the server can inform the clients by using redirect_info. > On the other hand, when the IPsec server realizes that the client connects > to a different server from the one in the client's profile, it > performs the redirect_auth > that IMO is simpler and mroe efficient that the redirect_info in this case. > I do not see they are two different methods for the same purpose. This is an artificial demarcation. There is nothing wrong in using the informational REDIRECT exchange to re-direct the client to another gateway based on the client's profile. FWIW, I think think what we have in the draft currently is sufficient. I agree with many posts on this thread that said the additional mechanism is not required. So I will close the issue with no changes to the document. Vijay > >> >> On the other hand the difference between doing the IKE_AUTH to end and >> doing INFORMATINAL exchange after that to do redirect is even >> simplier, as we still want to support that option too, and the most >> time consuming part of the IKE_AUTH (Diffie-Hellman, Signing etc) is >> already done anyways, so doing it as separate INFOMRATIONL exchange, >> simply wastes 2 extra small packets but no extra round trips. Note, >> that server can reject the IPsec SA creation by returning suitable >> error message (for example NO_ADDITIONAL_SAS) in the IKE_AUTH, and >> then the full exchange would be: >> >> >> Initiator Responder >> ------------------------------------------------------------------- >> HDR, SAi1, KEi, Ni, >> N(REDIRECT_SUPPORTED) --> >> >> >> <-- HDR, SAr1, KEr, Nr, [CERTREQ] >> >> >> HDR, SK {IDi, [CERT,] [CERTREQ,] >> [IDr,] AUTH, SAi2, >> TSi, TSr} --> >> >> >> <-- HDR, SK {IDr, [CERT,] AUTH, >> N(NO_ADDITIONAL_SAS)} >> <-- HDR, SK {N(REDIRECT)} > What happens if these two messages from the server are reordered > during transmisstion, and either HDR, SK {N(REDIRECT)} or > HDR, SK {IDr, [CERT,] AUTH, N(NO_ADDITIONAL_SAS)} is dropped > during transmission? > > Thanks. > > Sincerely, > fan > >> >> >> HDR, SK {N(REDIRECT_ACK)} --> >> HDR, SAi1, KEi, Ni, >> N(REDIRECT_FROM) --> >> >> I.e. the server would reply N(NO_ADDITIONAL_SAS) and immediately after >> that send N(REDIRECT) notify as separate INFORMATINAL exchange. The >> initiator would first get the IKE_AUTH reply, process that, and >> immediately after that get INFORMATINAL exhange asking to N(REDIRECT). >> >> The initiator can start connection to the new IKE SA immediately when >> it receives the N(REDIRECT) thus it does not waste any single round >> trip, only wasted resource would be 2 small packets (less than 100 >> bytes each). >> >> I think this is simplier and cleaner way to get the same effect with >> no extra real cost. >> -- >> kivinen@iki.fi >> > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 9 17:29: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 60F103A69B5; Tue, 9 Dec 2008 17:29:49 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78AB73A69AB for ; Tue, 9 Dec 2008 17:29:48 -0800 (PST) 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 dl-uF9e4JN4H for ; Tue, 9 Dec 2008 17:29:47 -0800 (PST) Received: from mail-gx0-f10.google.com (mail-gx0-f10.google.com [209.85.217.10]) by core3.amsl.com (Postfix) with ESMTP id 713013A67A8 for ; Tue, 9 Dec 2008 17:29:47 -0800 (PST) Received: by gxk3 with SMTP id 3so272433gxk.13 for ; Tue, 09 Dec 2008 17:29:39 -0800 (PST) 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=ftS5aOArU7sTFGwHI3YllXV+RMyp9CNDxg0VgwQfeAg=; b=ZoVBBeCSsOibdIBnjWt0vxNUP0oU3kPQKlgXz4EqB+69OWgsEhAMzjoeOUi2XSKjwW ZezBXOw84PIx7PbYkFrWFy/2W4xCegu1z8adq70c7GkuE9haxbSvakqz5a89wSIWqDpI AJvWboyEnCIwbbDTd7J612lM91HyOFCkFIcQ8= 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=RzRln0fv67GzekDufP8/ZlIgJ0mod5DGChyKYoJqmBznvvWm6xkPL6Sv4PXB+PYaJA RuTqdvJWeyWVesUE6cEpTApwkAVbmtvkGlXdM9RYVZP39+RWRwFgnPGLV235AfwjWxXF BT8n92uhi2g0G0dsHPvjozcEWuCurrUtO1mGU= Received: by 10.115.110.6 with SMTP id n6mr565041wam.72.1228872579156; Tue, 09 Dec 2008 17:29:39 -0800 (PST) Received: by 10.142.178.3 with HTTP; Tue, 9 Dec 2008 17:29:39 -0800 (PST) Message-ID: Date: Tue, 9 Dec 2008 17:29:39 -0800 From: "Vijay Devarapalli" To: "Yoav Nir" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Cc: ipsec@ietf.org Subject: Re: [IPsec] Comments about "IKEv2 Redirect" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Yoav, On Sun, Dec 7, 2008 at 8:11 AM, Yoav Nir wrote: > Hi. > > I've read through the IKEv2 Redirect draft, and I have some comments: > > 1. Section 5 ("Gateway Initiated Redirect") does not specify what the client > and gateway should do after the redirect message is sent and acknowledged. > Obviously the client should setup SAs with the new gateway. What is less > clear is what happens to the IKE and child SAs with the first gateway. > One option is to make the REDIRECT/REDIRECT_ACK pair imply a delete of the > IKE SAs. In that case all further IPsec traffic will be rejected. In that > case the text should say this clearly. > Another option is that the SAs remain valid until either side explicitly > closes them. In that case the text should say this, and also recommend which > side should close the old SAs and how soon (for example: the client should > delete as soon as it starts setting up the new IKE SAs, the gateway should > delete after allowing enough time to set up new SAs - one minute?) I added the following text to section 5 Once the client responds to the gateway with the REDIRECT_ACK payload, it SHOULD delete the existing security associations with the old gateway. The gateway MAY also decide to delete the security associations without any signaling from the client. However, it should allow sufficient time for the client to setup the required security associations with the new security gateway. This time period should be configurable on the gateway. > 2. Section 9: s/with who, /with whom / > I feel really pedantic for this one... > > 3. Abstract. "IKEv2 is a popular protocol..." this is not strictly true. I > would lost the "popular". Also, since the abstract gives the reasons why we > might want to redirect, I think it should include, in addition to the > overloaded gateway and mobile IPv6 case, the case of draining a remote > access gateway for maintenance. > > 4. Introduction. "widely" - same as "popular" in the abstract. Removed the words "popular" and "widely". :) Vijay _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 9 23:22:16 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FD193A6AB5; Tue, 9 Dec 2008 23:22:16 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9670A3A6A73 for ; Tue, 9 Dec 2008 23:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 R4Pkbyb5tGul for ; Tue, 9 Dec 2008 23:22:13 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 67BC83A69A4 for ; Tue, 9 Dec 2008 23:22:13 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D077329C003; Wed, 10 Dec 2008 09:22:03 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 74AF729C001; Wed, 10 Dec 2008 09:22:02 +0200 (IST) X-CheckPoint: {493F6D20-10000-88241DC2-7B6} Received: from [91.90.139.118] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBA7M2fE026100; Wed, 10 Dec 2008 09:22:02 +0200 (IST) Message-Id: <4F68542D-E7EE-4B77-836D-9CB7FFDE604D@checkpoint.com> From: Yoav Nir To: Vijay Devarapalli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 10 Dec 2008 08:47:45 +0200 References: X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] Comments about "IKEv2 Redirect" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Vijay On Dec 10, 2008, at 3:29 AM, Vijay Devarapalli wrote: > Hi Yoav, > > On Sun, Dec 7, 2008 at 8:11 AM, Yoav Nir wrote: >> Hi. >> >> I've read through the IKEv2 Redirect draft, and I have some comments: >> >> 1. Section 5 ("Gateway Initiated Redirect") does not specify what >> the client >> and gateway should do after the redirect message is sent and >> acknowledged. >> Obviously the client should setup SAs with the new gateway. What is >> less >> clear is what happens to the IKE and child SAs with the first >> gateway. >> One option is to make the REDIRECT/REDIRECT_ACK pair imply a delete >> of the >> IKE SAs. In that case all further IPsec traffic will be rejected. >> In that >> case the text should say this clearly. >> Another option is that the SAs remain valid until either side >> explicitly >> closes them. In that case the text should say this, and also >> recommend which >> side should close the old SAs and how soon (for example: the client >> should >> delete as soon as it starts setting up the new IKE SAs, the gateway >> should >> delete after allowing enough time to set up new SAs - one minute?) > > I added the following text to section 5 > > Once the client responds to the gateway with the REDIRECT_ACK > payload, it SHOULD delete the existing security associations with > the > old gateway. The gateway MAY also decide to delete the security > associations without any signaling from the client. However, it > should allow sufficient time for the client to setup the required > security associations with the new security gateway. This time > period should be configurable on the gateway. > That still doesn't tell me if the deletion is implicit (if the gateway redirected, then obviously it doesn't want the SAs any more) or explicit (the gateway or the client MUST send deletes, and until then the SAs are valid) >> 2. Section 9: s/with who, /with whom / >> I feel really pedantic for this one... >> >> 3. Abstract. "IKEv2 is a popular protocol..." this is not strictly >> true. I >> would lost the "popular". Also, since the abstract gives the >> reasons why we >> might want to redirect, I think it should include, in addition to the >> overloaded gateway and mobile IPv6 case, the case of draining a >> remote >> access gateway for maintenance. >> >> 4. Introduction. "widely" - same as "popular" in the abstract. > > Removed the words "popular" and "widely". :) Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 10 07:54:29 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53E6A3A6946; Wed, 10 Dec 2008 07:54:29 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43443A68DD for ; Wed, 10 Dec 2008 07:54:27 -0800 (PST) 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 iIJrJYiQPqNS for ; Wed, 10 Dec 2008 07:54:27 -0800 (PST) Received: from rn-out-0910.google.com (rn-out-0910.google.com [64.233.170.186]) by core3.amsl.com (Postfix) with ESMTP id EE6AF3A68D4 for ; Wed, 10 Dec 2008 07:54:26 -0800 (PST) Received: by rn-out-0910.google.com with SMTP id j77so620813rne.18 for ; Wed, 10 Dec 2008 07:54:19 -0800 (PST) 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=cp/QfwLk346y705euhd5MwoiIgPy3fiBW4ufKNCCP9M=; b=TEsDX1CN1r/kQhRRiMlK/Jo01DKrE6jEvOUBhJKA3R1xjJnZzss0zktsHgRSVcCmRY f8NEiaNLfSzD1H2iSkZ3smw8oNIWbcWWyTsTua5NmHsM5xsnlXrqCEnUZdaxOv5EPgPp gwowjwkOGzMmfXWuxQODdWqULRQVfBQdy0ThA= 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=Uc6XT5mZ7KzbANvCh+tM3RUAgcmjPiNmSer8QpBPf09IJOpt+FTyhN9ipklCjsD6ii kYxMfbwvuUoqMy5Tm8vMC5OS2pZfVCg7ABYPEEyrI2/qUXPQeqCbHhjLUXvsVdT2AYn3 ENqsT26d62jDowhcrNqdCvxbLD03aFeWNEhaQ= Received: by 10.142.125.9 with SMTP id x9mr276286wfc.236.1228924459177; Wed, 10 Dec 2008 07:54:19 -0800 (PST) Received: by 10.142.178.3 with HTTP; Wed, 10 Dec 2008 07:54:19 -0800 (PST) Message-ID: Date: Wed, 10 Dec 2008 07:54:19 -0800 From: "Vijay Devarapalli" To: "Yoav Nir" In-Reply-To: <4F68542D-E7EE-4B77-836D-9CB7FFDE604D@checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline References: <4F68542D-E7EE-4B77-836D-9CB7FFDE604D@checkpoint.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] Comments about "IKEv2 Redirect" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Yoav, On Tue, Dec 9, 2008 at 10:47 PM, Yoav Nir wrote: >>> 1. Section 5 ("Gateway Initiated Redirect") does not specify what the >>> client >>> and gateway should do after the redirect message is sent and >>> acknowledged. >>> Obviously the client should setup SAs with the new gateway. What is less >>> clear is what happens to the IKE and child SAs with the first gateway. >>> One option is to make the REDIRECT/REDIRECT_ACK pair imply a delete of >>> the >>> IKE SAs. In that case all further IPsec traffic will be rejected. In that >>> case the text should say this clearly. >>> Another option is that the SAs remain valid until either side explicitly >>> closes them. In that case the text should say this, and also recommend >>> which >>> side should close the old SAs and how soon (for example: the client >>> should >>> delete as soon as it starts setting up the new IKE SAs, the gateway >>> should >>> delete after allowing enough time to set up new SAs - one minute?) >> >> I added the following text to section 5 >> >> Once the client responds to the gateway with the REDIRECT_ACK >> payload, it SHOULD delete the existing security associations with the >> old gateway. The gateway MAY also decide to delete the security >> associations without any signaling from the client. However, it >> should allow sufficient time for the client to setup the required >> security associations with the new security gateway. This time >> period should be configurable on the gateway. >> > > That still doesn't tell me if the deletion is implicit (if the gateway > redirected, then obviously it doesn't want the SAs any more) or explicit > (the gateway or the client MUST send deletes, and until then the SAs are > valid) The text above says the client "SHOULD" delete the SAs with the old gateway. I don't think we should use "MUST" here. If the client does not delete the SAs, the gateway can still delete the SAs if it wants. Or just let them expire. I am not sure what more we should specify here. Vijay _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 10 12:19:12 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1EA3A6B94; Wed, 10 Dec 2008 12:19:12 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4D323A6BB4 for ; Wed, 10 Dec 2008 12:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 OybU307gAU2r for ; Wed, 10 Dec 2008 12:19:09 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6E8773A6B94 for ; Wed, 10 Dec 2008 12:19:09 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 1325F29C003; Wed, 10 Dec 2008 22:19:03 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2824529C001; Wed, 10 Dec 2008 22:19:02 +0200 (IST) X-CheckPoint: {49402336-10000-88241DC2-7B6} Received: from [172.31.21.25] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBAKJ1fE019961; Wed, 10 Dec 2008 22:19:01 +0200 (IST) Message-Id: <52414128-F831-46FE-AA87-0177C70703C3@checkpoint.com> From: Yoav Nir To: Vijay Devarapalli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 10 Dec 2008 22:19:00 +0200 References: <4F68542D-E7EE-4B77-836D-9CB7FFDE604D@checkpoint.com> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] Comments about "IKEv2 Redirect" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Dec 10, 2008, at 5:54 PM, Vijay Devarapalli wrote: > Hi Yoav, > > On Tue, Dec 9, 2008 at 10:47 PM, Yoav Nir wrote: > >>>> 1. Section 5 ("Gateway Initiated Redirect") does not specify what >>>> the >>>> client >>>> and gateway should do after the redirect message is sent and >>>> acknowledged. >>>> Obviously the client should setup SAs with the new gateway. What >>>> is less >>>> clear is what happens to the IKE and child SAs with the first >>>> gateway. >>>> One option is to make the REDIRECT/REDIRECT_ACK pair imply a >>>> delete of >>>> the >>>> IKE SAs. In that case all further IPsec traffic will be rejected. >>>> In that >>>> case the text should say this clearly. >>>> Another option is that the SAs remain valid until either side >>>> explicitly >>>> closes them. In that case the text should say this, and also >>>> recommend >>>> which >>>> side should close the old SAs and how soon (for example: the client >>>> should >>>> delete as soon as it starts setting up the new IKE SAs, the gateway >>>> should >>>> delete after allowing enough time to set up new SAs - one minute?) >>> >>> I added the following text to section 5 >>> >>> Once the client responds to the gateway with the REDIRECT_ACK >>> payload, it SHOULD delete the existing security associations with >>> the >>> old gateway. The gateway MAY also decide to delete the security >>> associations without any signaling from the client. However, it >>> should allow sufficient time for the client to setup the required >>> security associations with the new security gateway. This time >>> period should be configurable on the gateway. >>> >> >> That still doesn't tell me if the deletion is implicit (if the >> gateway >> redirected, then obviously it doesn't want the SAs any more) or >> explicit >> (the gateway or the client MUST send deletes, and until then the >> SAs are >> valid) > > The text above says the client "SHOULD" delete the SAs with the old > gateway. I don't think we should use "MUST" here. If the client does > not delete the SAs, the gateway can still delete the SAs if it wants. > Or just let them expire. I am not sure what more we should specify > here. OK. That answers my question. What I meant (and I still think it should be said explicitly) is that the REDIRECT-REDIRECT_ACK pair does not implicitly delete the SAs. The client or the gateway still need to explicitly send DELETE payloads in a separate Informational exchange. Someone suggested off-list that this should be otherwise, and that SAs should be immediately deleted (with no further packets) after the REDIRECT_ACK is sent and received. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 10 14:07: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 A7E393A69D0; Wed, 10 Dec 2008 14:07:00 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 193B13A69D0 for ; Wed, 10 Dec 2008 14:06:59 -0800 (PST) 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 Ig7BMWpCMine for ; Wed, 10 Dec 2008 14:06:58 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.168]) by core3.amsl.com (Postfix) with ESMTP id 3B0D03A69CF for ; Wed, 10 Dec 2008 14:06:58 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so355888wfd.31 for ; Wed, 10 Dec 2008 14:06:51 -0800 (PST) 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=RpoFRKjhqaqpYgNG6XEBnmuGwa34V0vhpWTqnfwILmE=; b=UI50+tJjuFqalCUOYIoMOyiorvXn1fsNdcslNnrXxrmTYbN6T/0wHrnMq7UXFIQf2E 0KM2FA8G+sM1w9aK5TxsPkCg127oufJELr2yp5SJPRVt/zmwzWjnE1CZ0ropbCUJhYsn WfdZxB7UGcapAgqPVhyrk6M9LEKdiHx0VpAmI= 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=okqHMKFz4RHozR8eMCRdBQl9pYK/zxCcuAmT53bJ02mCltoIpSQH/MRIb8CaBwEHrr CKvl/ndhUMmiGbOFN3jxj9ygkcnkle95wSiRqvjY4o3Kkd7zulJ2ugI7bZJcv9Ifbv41 Xq6YwwigAPJPWcnMbT9v0U8JMmNOZh3f/VxgU= Received: by 10.142.142.14 with SMTP id p14mr430280wfd.29.1228946811568; Wed, 10 Dec 2008 14:06:51 -0800 (PST) Received: by 10.142.178.3 with HTTP; Wed, 10 Dec 2008 14:06:51 -0800 (PST) Message-ID: Date: Wed, 10 Dec 2008 14:06:51 -0800 From: "Vijay Devarapalli" To: "Yoav Nir" In-Reply-To: <52414128-F831-46FE-AA87-0177C70703C3@checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline References: <4F68542D-E7EE-4B77-836D-9CB7FFDE604D@checkpoint.com> <52414128-F831-46FE-AA87-0177C70703C3@checkpoint.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] Comments about "IKEv2 Redirect" 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, Dec 10, 2008 at 12:19 PM, Yoav Nir wrote: > > On Dec 10, 2008, at 5:54 PM, Vijay Devarapalli wrote: > >> Hi Yoav, >> >> On Tue, Dec 9, 2008 at 10:47 PM, Yoav Nir wrote: >> >>>>> 1. Section 5 ("Gateway Initiated Redirect") does not specify what the >>>>> client >>>>> and gateway should do after the redirect message is sent and >>>>> acknowledged. >>>>> Obviously the client should setup SAs with the new gateway. What is >>>>> less >>>>> clear is what happens to the IKE and child SAs with the first gateway. >>>>> One option is to make the REDIRECT/REDIRECT_ACK pair imply a delete of >>>>> the >>>>> IKE SAs. In that case all further IPsec traffic will be rejected. In >>>>> that >>>>> case the text should say this clearly. >>>>> Another option is that the SAs remain valid until either side >>>>> explicitly >>>>> closes them. In that case the text should say this, and also recommend >>>>> which >>>>> side should close the old SAs and how soon (for example: the client >>>>> should >>>>> delete as soon as it starts setting up the new IKE SAs, the gateway >>>>> should >>>>> delete after allowing enough time to set up new SAs - one minute?) >>>> >>>> I added the following text to section 5 >>>> >>>> Once the client responds to the gateway with the REDIRECT_ACK >>>> payload, it SHOULD delete the existing security associations with the >>>> old gateway. The gateway MAY also decide to delete the security >>>> associations without any signaling from the client. However, it >>>> should allow sufficient time for the client to setup the required >>>> security associations with the new security gateway. This time >>>> period should be configurable on the gateway. >>>> >>> >>> That still doesn't tell me if the deletion is implicit (if the gateway >>> redirected, then obviously it doesn't want the SAs any more) or explicit >>> (the gateway or the client MUST send deletes, and until then the SAs are >>> valid) >> >> The text above says the client "SHOULD" delete the SAs with the old >> gateway. I don't think we should use "MUST" here. If the client does >> not delete the SAs, the gateway can still delete the SAs if it wants. >> Or just let them expire. I am not sure what more we should specify >> here. > > OK. That answers my question. What I meant (and I still think it should be > said explicitly) is that the REDIRECT-REDIRECT_ACK pair does not implicitly > delete the SAs. The client or the gateway still need to explicitly send > DELETE payloads in a separate Informational exchange. Someone suggested > off-list that this should be otherwise, and that SAs should be immediately > deleted (with no further packets) after the REDIRECT_ACK is sent and > received. Well, what is proposed above is a mix of both. The client SHOULD delete the SAs. It if doesn't, the gateway goes ahead and deletes the SAs anyway. I am not sure the spec needs to say if the gateway should delete the SAs immediately after the REDIRECT_ACK message is received. Vijay _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 10 14:25: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 7FC7028C1E8; Wed, 10 Dec 2008 14:25:08 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F9728C1E8 for ; Wed, 10 Dec 2008 14:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 9RZ9D9xSJ9Jk for ; Wed, 10 Dec 2008 14:25:05 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 1E7033A69D4 for ; Wed, 10 Dec 2008 14:25:03 -0800 (PST) Received: by qyk4 with SMTP id 4so990639qyk.13 for ; Wed, 10 Dec 2008 14:24:56 -0800 (PST) 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=xCQv6opzxk8yyqp6Ym8Q3rGw7jj1yuxomWgr6GoOq5s=; b=N8gW//mSharsPsRh52GEte7F2aB/FW/i7OHwjsILcmme4w7N0b+Oefnudb2lu3GYin FdRRvo1kCz1Ra+XXw0pEHedhXiB/ifx+MM3H532N+jRdP6DelKKNAkblYK3LXcV+Xk8V vi1YYsIdwD3J6vI1nopPk8BJTNHRzaPwvRqbI= 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=sdwGDBwrOmLG+0a1/pjx75cu27uDKHDjwyfx7MD0mY3lucXvurTYmtCWR6uX6zY1wN R/gVxuesb6LmCd9EkHigZ54MkNFm6Z1whn0qV9KsFFq4T8FSGl6Ig2kMsq2RQCXOEJZW 0y3DgX610jWvSR8ebcBHngb2Bk7ls6rR2CmmE= Received: by 10.214.217.14 with SMTP id p14mr2807663qag.272.1228947896828; Wed, 10 Dec 2008 14:24:56 -0800 (PST) Received: by 10.215.14.1 with HTTP; Wed, 10 Dec 2008 14:24:56 -0800 (PST) Message-ID: Date: Wed, 10 Dec 2008 14:24:56 -0800 From: "fan zhao" To: "Vijay Devarapalli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Vijay, Sorry I could not respond to this thread earlier. I was moving during the last few days and have just settled down in the new place. Maybe the conclusion is made too earlier, since I want to reply several recent emails. Sincerely, fan On Tue, Dec 9, 2008 at 5:10 PM, Vijay Devarapalli wrote: > Hi Fan, > > On Wed, Dec 3, 2008 at 11:05 AM, fan zhao wrote: >> Hi Tero, >> >> Thanks for your reply. >> If you do not mind, I will call redirection in the last message >> during the IKE_AUTH as "redirect_auth" and redirection during >> the separate informational exchange as "redirect_info" in the following text. >> >> On Wed, Dec 3, 2008 at 4:51 AM, Tero Kivinen wrote: >>> fan zhao writes: >>>> 2) The IPsec client requests to set up the child SA during IKE_AUTH >>>> client -> gateway: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH SAi2, TSi, TSr} >>> >>> If we want to allow redirection during the IKE_AUTH, I think this >>> second option is the one we want to select. This would be identical to >>> normal exchange, thus it will cause smaller changes, and it has good >>> property that if server does NOT do redirect we get the IPsec SA done >>> after this. >> I think this property is also supported by the redirect_auth since if >> the IPsec server does not want to do redirect, it simply does not include >> the Redirect payload. >> >>> In any cause we MUST NOT define two different ways how to >>> do this, as that would just add unnessary complexity. So if we are >>> going to select one, lets select this one. >> This is always a good principle to follow in general. However, in this case, my >> understanding is that the redirect_auth and the redirect_info address >> different needs. For example, when an IPsec server serving IPsec clients >> realizes that it is overloaded or it needs to shut down for >> administration reasons, >> the server can inform the clients by using redirect_info. >> On the other hand, when the IPsec server realizes that the client connects >> to a different server from the one in the client's profile, it >> performs the redirect_auth >> that IMO is simpler and mroe efficient that the redirect_info in this case. >> I do not see they are two different methods for the same purpose. > > This is an artificial demarcation. There is nothing wrong in using the > informational REDIRECT exchange to re-direct the client to another > gateway based on the client's profile. > > FWIW, I think think what we have in the draft currently is sufficient. > I agree with many posts on this thread that said the additional > mechanism is not required. So I will close the issue with no changes > to the document. > > Vijay > >> >>> >>> On the other hand the difference between doing the IKE_AUTH to end and >>> doing INFORMATINAL exchange after that to do redirect is even >>> simplier, as we still want to support that option too, and the most >>> time consuming part of the IKE_AUTH (Diffie-Hellman, Signing etc) is >>> already done anyways, so doing it as separate INFOMRATIONL exchange, >>> simply wastes 2 extra small packets but no extra round trips. Note, >>> that server can reject the IPsec SA creation by returning suitable >>> error message (for example NO_ADDITIONAL_SAS) in the IKE_AUTH, and >>> then the full exchange would be: >>> >>> >>> Initiator Responder >>> ------------------------------------------------------------------- >>> HDR, SAi1, KEi, Ni, >>> N(REDIRECT_SUPPORTED) --> >>> >>> >>> <-- HDR, SAr1, KEr, Nr, [CERTREQ] >>> >>> >>> HDR, SK {IDi, [CERT,] [CERTREQ,] >>> [IDr,] AUTH, SAi2, >>> TSi, TSr} --> >>> >>> >>> <-- HDR, SK {IDr, [CERT,] AUTH, >>> N(NO_ADDITIONAL_SAS)} >>> <-- HDR, SK {N(REDIRECT)} >> What happens if these two messages from the server are reordered >> during transmisstion, and either HDR, SK {N(REDIRECT)} or >> HDR, SK {IDr, [CERT,] AUTH, N(NO_ADDITIONAL_SAS)} is dropped >> during transmission? >> >> Thanks. >> >> Sincerely, >> fan >> >>> >>> >>> HDR, SK {N(REDIRECT_ACK)} --> >>> HDR, SAi1, KEi, Ni, >>> N(REDIRECT_FROM) --> >>> >>> I.e. the server would reply N(NO_ADDITIONAL_SAS) and immediately after >>> that send N(REDIRECT) notify as separate INFORMATINAL exchange. The >>> initiator would first get the IKE_AUTH reply, process that, and >>> immediately after that get INFORMATINAL exhange asking to N(REDIRECT). >>> >>> The initiator can start connection to the new IKE SA immediately when >>> it receives the N(REDIRECT) thus it does not waste any single round >>> trip, only wasted resource would be 2 small packets (less than 100 >>> bytes each). >>> >>> I think this is simplier and cleaner way to get the same effect with >>> no extra real cost. >>> -- >>> kivinen@iki.fi >>> >> > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 10 14:42: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 124703A69E2; Wed, 10 Dec 2008 14:42:41 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FE3A3A69D7 for ; Wed, 10 Dec 2008 14:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 899UZGFtF1XC for ; Wed, 10 Dec 2008 14:42:38 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 133D93A6944 for ; Wed, 10 Dec 2008 14:42:37 -0800 (PST) Received: by qyk4 with SMTP id 4so996044qyk.13 for ; Wed, 10 Dec 2008 14:42:31 -0800 (PST) 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=wGWOZVh7kJ8ZTw8ApQrk30RS8z8OT/vQeN1x5qy5E5k=; b=GD5v5LOut7rsARbrEu10qXyr7ZVL5gx576VJ+x15k+5cLLTQYen9TRs3PAxVUqmr6v GCNw2Eafx9x7ip1JbLlCo2OFTnRRz5HGsCIlYpvC20y+6a5tBeZaYnFHO9LKe/ZSQvxN Y00iFULeWlaCT+dNkJSOLYy9/8688kSqA6i6c= 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=xjUpHPT5IAUF1Vi+vHiqLWp+Zrz8pLH9FD5Z0H3GnXEEHL2BYJEf6CIVUhVuYpsMzv UOg0lGM2v5RCxu7edZ5tSV5v4x6M3Ln+bKGdkXt2q1YFa/bKxYbdxceNHF7UMV4nnKAr 0QGIiKSTc8kFzuXJTRwneAMs/J+AmdhzpBTpk= Received: by 10.214.59.3 with SMTP id h3mr2849687qaa.70.1228948950966; Wed, 10 Dec 2008 14:42:30 -0800 (PST) Received: by 10.215.14.1 with HTTP; Wed, 10 Dec 2008 14:42:30 -0800 (PST) Message-ID: Date: Wed, 10 Dec 2008 14:42:30 -0800 From: "fan zhao" To: "Tero Kivinen" In-Reply-To: <18749.21666.801967.227066@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> <18749.21666.801967.227066@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero and all, Sorry I did not reply earlier. I was moving during last few days. After quickly going over your comments, I agree what you mentioned are valid issues and they should be considered and addressed during implementation. However, these issues are implementation specific, not related to protocol design and it is feasible to address such issues (bugs) during implementation. Furthermore, I agree that the IPsec server can wait for the timer to expire to detect whether the informational message with the redirect is lost or not. However, there is still delay that could affect performance very much. This is a flaw of design, IMHO, which means that even though the implementation is bug-free and very efficient, when reordering and paket loss happen, there is nothing we can do. The performance is very important to user experience. I would like argue that given such considerations, redirect should be enabled during IKE_AUTH. Sincerely, fan On Mon, Dec 8, 2008 at 9:08 AM, Tero Kivinen wrote: > fan zhao writes: >> I do not see why adding the REDIRECT payload can affect the authentication >> combination. The authentication of the last IKE_AUTH message is done >> independently and actually before the processing of the REDIRECT payload. >> Sure, we should consider all possible cases. Do you find anything broken? > > The number of packets sent in the IKE_AUTH will change for EAP for > example, and the REDIRECT payload changes location depending what > authentication method is used (i.e. it would be in the last). This > means that at least EAP vs non EAP case is mandatory to test, but in > general good QA will test all possible combinations to make sure there > is nothing that breaks when other authentication methods are used. > > I agree that making bug that is only affected by certain > authentication combination might not be the most common bug to make, > but on the other hand bugs do not tend to be very predictable in > general. > >> > * 2). It needs to be tested with other initial exchange combinations, >> > i.e. INVALID_KE_PAYLOAD and COOKIE notification cases, it needs to be >> > tested with MOBIKE extensions, it needs to be tested with NAT >> > traversal cases, etc. >> Still I do not see anyhting could be broken. To my best knowledgement, >> I do not see this can break MOBIKE and NAT traversal either. >> Can you give me an example? > > For example for NAT traversal you still need to make sure the client > uses correct port to connect the new server. The current draft does > not say whether client should connect to directly to port 4500 or > restart at port 500. Both of them do have benefits. With mobike the > complication could be for example that IP-addresses change between > IKE_SA_INIT and IKE_AUTH, or when combininig MOBIKE with NAT > traversal, you do the port float to port 4500 before you start > IKE_AUTH etc. > > I cannot really guess what kind of bugs people tend to write... But > implementations usually do have bugs, and implementations needs to be > tested before they can be put out. The more options we have the more > testing there is to do. > >> By the testing effort, do you mean the "conditions" in the program >> or the testing cases? There are many different ways for >> implementation. From the protocol perspective, the state transition >> is simple: after all the processing, specified in the IKEv2 >> protocol, of the last IKE_AUTH message, then the client processes >> the REDIRECT payload. > > I mean the test done by the QA before any release is done, and also > interoperability testing done in the IPsec interoperability events. > >> I worry more about the "consequence" of packet reordering/loss. > > That is something your current QA people should already be testing > before you release anything, as it is critical security feature, and > if that is broken, then your implementation is unsecure. > > This is something that MUST be done for the plain IKEv2 already, this > extension does not add any new requirements for this part. > >> I agree that packet reordering/loss can be handled. But even so, delay and >> overhead are introduced. As an example, assume that the server sends >> the last IKE_AUTH message and then a informational message with >> the REDIRECT payload. If the informational message is lost during the >> transmission, the server does not know until it receives an IPsec packet >> from the client again; > > Server will know the informational packet was lost, as it does not > receive reply back from the client. This again is standard IKEv2 > feature, that must be tested by the QA before any products can be put > out, as it affects the whole IKEv2 protocol implementation. > >> then the server needs to send another informational >> message with the REDIRECT payload to the client. > > The server would not send another informational message, he would > resend the previous request, and he will resend it until the client > will reply. If the client will not reply then server will tear down > the IKE SA and assume the connection is broken. Again this is standard > operation that must be correctly handled by all implementations, which > means it should be tested by the QA already (hopefully part of their > automatic testing suite). > >> In this case, the client would waste a packet and IPsec processing >> time on this packet, and the client cannot connect to the correct >> server as soon as possible. This is not good especially when there >> is existing session between the client and the correct server. > > As the server most likely already responded with the NO_ADDITIONAL_SAS > error during the IKE_AUTH, the server and client do not have IPsec SA > between them. They only have IKE SA. And the exactly same delay will > happen if the packet containing N(REDIRECT) is lost, regardless > whether it is part of the IKE_AUTH or INFORMATIONAL exchange. > >> Thanks for explanation. Yes I agree with you: so in the redirection >> case, if the REDIRECT payload is received before the last AUTH >> message (i.e. reordering), the client shoudl reject it. > > Yes. > >> Then the >> sqerver would have to send another REDIRECT payload to the client >> again after it realizes that the client is not redirected yet, >> right? Thanks. > > It will resend the packet containing the N(REDIRECT) notify when it > realizeds it has not received reply packet for that. Meaning it will > resend it after 0.5-1 second or so. > -- > kivinen@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 10 15:07: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 499EE3A6944; Wed, 10 Dec 2008 15:07:04 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86103A6944 for ; Wed, 10 Dec 2008 15:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfLEyYAs7EzT for ; Wed, 10 Dec 2008 15:07:03 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id 14DF63A676A for ; Wed, 10 Dec 2008 15:07:02 -0800 (PST) Received: by qyk4 with SMTP id 4so1003269qyk.13 for ; Wed, 10 Dec 2008 15:06:57 -0800 (PST) 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=cabQPyFbj3yUji50h5Gz0BfFenWs2s4djzlue8Evu0s=; b=ure44tv37iPRxhvtIYBCh6O6uLt2imLqWzvgCtGB0Ppkzz0P8x+smf8UGEzr01WHvs A4KSuuFeYTg0DDG/R9JnCogGML+qTnugcwGaXcUfTiSuKUfIpGlgcsmh/xGZRgUCcvq3 FpcRVLbhw+b9+4dgUs9BY5FW6LRsUPDETJniI= 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=ppawgxi26yOA5elT+AuQD2bLPnYIWfSGH4E0m6uVQA4sjaXvggocwNGsgL58krAm88 6yatHA/4futUdv2CiRe4PuWL3gBq4O7sPTIUkWnmSbit5nWSTpZ13kp6m5P0YIbuyJQ4 IC+55+uw18jk9CuTiLmg93yCd9GiKem4MugpE= Received: by 10.214.12.11 with SMTP id 11mr2865223qal.63.1228950416844; Wed, 10 Dec 2008 15:06:56 -0800 (PST) Received: by 10.215.14.1 with HTTP; Wed, 10 Dec 2008 15:06:56 -0800 (PST) Message-ID: Date: Wed, 10 Dec 2008 15:06:56 -0800 From: "fan zhao" To: "Tero Kivinen" In-Reply-To: <18749.24598.321512.769027@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <18749.24598.321512.769027@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Yoav Nir Subject: Re: [IPsec] Comments about "IKEv2 Redirect" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I also agree on this option. Sincerely, fan On Mon, Dec 8, 2008 at 9:57 AM, Tero Kivinen wrote: > Yoav Nir writes: >> Another option is that the SAs remain valid until either side >> explicitly closes them. In that case the text should say this, and >> also recommend which side should close the old SAs and how soon (for >> example: the client should delete as soon as it starts setting up the >> new IKE SAs, the gateway should delete after allowing enough time to >> set up new SAs - one minute?) > > I think this option would be better. That would be much more in line > with how IKEv2 do things (i.e. for example IKE SA rekeys). > -- > kivinen@iki.fi > _______________________________________________ > 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 Dec 10 15:08:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD15028C1E4; Wed, 10 Dec 2008 15:08:23 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05F1928C1E1 for ; Wed, 10 Dec 2008 15:08:23 -0800 (PST) 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 dXYhDZJSZZWu for ; Wed, 10 Dec 2008 15:08:22 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id DFB2428C1AA for ; Wed, 10 Dec 2008 15:08:21 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so221096qwe.31 for ; Wed, 10 Dec 2008 15:08:14 -0800 (PST) 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=G4KK2rbaxJ1jser9PJg+n7fZbztQe82pdpwf4nZBYCU=; b=UP6tC8CmAshJVHPHC+sfV2feqyaZSObN7j4zkhLc4N6NCYZKlFWdO+9IvQnUj3MDKy Z5Wietgy5cVj9vXIvnogJZm3dSTH+/eTQK4i3KXKA+ozzyGa+2zn6WsNjjxdyo4Gxx+N yEc7PCEvi/A+j0EWpd1EzxVDxo0DXDSXM/Cvk= 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=QY3jaYtli6Pmi78KZ2Vtr6njK/klAZYq5RffUJY276BYtD/jlKJK/BvULKhby3K1E8 Ih+cM+/B/W8EIVbVWQg+DCho14AWvcW/sIL8Vajfo7tdERfYViwPYb4vBG7l7+BbnW1Z HuqQnDMZ5cQP7KnEibWtrJkyKAzyxy+rLPi3A= Received: by 10.215.12.6 with SMTP id p6mr2856904qai.282.1228950494478; Wed, 10 Dec 2008 15:08:14 -0800 (PST) Received: by 10.215.14.1 with HTTP; Wed, 10 Dec 2008 15:08:14 -0800 (PST) Message-ID: Date: Wed, 10 Dec 2008 15:08:14 -0800 From: "fan zhao" To: "Yoav Nir" In-Reply-To: <52414128-F831-46FE-AA87-0177C70703C3@checkpoint.com> MIME-Version: 1.0 Content-Disposition: inline References: <4F68542D-E7EE-4B77-836D-9CB7FFDE604D@checkpoint.com> <52414128-F831-46FE-AA87-0177C70703C3@checkpoint.com> Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Comments about "IKEv2 Redirect" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I agree that to explicitly delete the SA, the delete payload should be sent in a separate message from the one with the redirect payload. Sincerely, fan On Wed, Dec 10, 2008 at 12:19 PM, Yoav Nir wrote: > > On Dec 10, 2008, at 5:54 PM, Vijay Devarapalli wrote: > >> Hi Yoav, >> >> On Tue, Dec 9, 2008 at 10:47 PM, Yoav Nir wrote: >> >>>>> 1. Section 5 ("Gateway Initiated Redirect") does not specify what the >>>>> client >>>>> and gateway should do after the redirect message is sent and >>>>> acknowledged. >>>>> Obviously the client should setup SAs with the new gateway. What is >>>>> less >>>>> clear is what happens to the IKE and child SAs with the first gateway. >>>>> One option is to make the REDIRECT/REDIRECT_ACK pair imply a delete of >>>>> the >>>>> IKE SAs. In that case all further IPsec traffic will be rejected. In >>>>> that >>>>> case the text should say this clearly. >>>>> Another option is that the SAs remain valid until either side >>>>> explicitly >>>>> closes them. In that case the text should say this, and also recommend >>>>> which >>>>> side should close the old SAs and how soon (for example: the client >>>>> should >>>>> delete as soon as it starts setting up the new IKE SAs, the gateway >>>>> should >>>>> delete after allowing enough time to set up new SAs - one minute?) >>>> >>>> I added the following text to section 5 >>>> >>>> Once the client responds to the gateway with the REDIRECT_ACK >>>> payload, it SHOULD delete the existing security associations with the >>>> old gateway. The gateway MAY also decide to delete the security >>>> associations without any signaling from the client. However, it >>>> should allow sufficient time for the client to setup the required >>>> security associations with the new security gateway. This time >>>> period should be configurable on the gateway. >>>> >>> >>> That still doesn't tell me if the deletion is implicit (if the gateway >>> redirected, then obviously it doesn't want the SAs any more) or explicit >>> (the gateway or the client MUST send deletes, and until then the SAs are >>> valid) >> >> The text above says the client "SHOULD" delete the SAs with the old >> gateway. I don't think we should use "MUST" here. If the client does >> not delete the SAs, the gateway can still delete the SAs if it wants. >> Or just let them expire. I am not sure what more we should specify >> here. > > OK. That answers my question. What I meant (and I still think it should be > said explicitly) is that the REDIRECT-REDIRECT_ACK pair does not implicitly > delete the SAs. The client or the gateway still need to explicitly send > DELETE payloads in a separate Informational exchange. Someone suggested > off-list that this should be otherwise, and that SAs should be immediately > deleted (with no further packets) after the REDIRECT_ACK is sent and > received. > > > Email secured by Check Point > _______________________________________________ > 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 Dec 10 15:53: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 DA97628C1D7; Wed, 10 Dec 2008 15:53:31 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58DB128C1D7 for ; Wed, 10 Dec 2008 15:53:31 -0800 (PST) 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 QTg8VAV9a2vl for ; Wed, 10 Dec 2008 15:53:30 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id E503E3A676A for ; Wed, 10 Dec 2008 15:53:29 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so223865qwe.31 for ; Wed, 10 Dec 2008 15:53:22 -0800 (PST) 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=RPFkTuACil5vVPWLkb7xDyODoFtJxxIbMCyQLAHhKGE=; b=otEx1yOEAnWUk+XMWEhtoc13FYkf4Cyb9c/wp0aeB5wzxxOusmLSLzWNV5+S4sRLsR sPIdvuNNk2+2XYx72Xv0Ae+txh4vIV4wMGxZ85r0ruVi50XAj4ttFB6jYges7zGg/id5 rVQwuCk43ZlJ+9GxMZ7kw9joTNPrCcKAieu3o= 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=OZlByn8mSfIDIkxYfBqvKTVCAeXqzAQVAjJ8jtUwgjiRVi+OXAn/YWjduj03gKTR0M mHNqoJ/QIO3DDcSBGQwNLfk6LuVFQPUoLYDHIIkeYeMEMcCzIOmG5Bp3pjid7fZLErUk q/qrn7hLQtf56FCMqjUVmnt9femRQBsiVnlmQ= Received: by 10.215.67.17 with SMTP id u17mr2909416qak.144.1228953202479; Wed, 10 Dec 2008 15:53:22 -0800 (PST) Received: by 10.215.14.1 with HTTP; Wed, 10 Dec 2008 15:53:22 -0800 (PST) Message-ID: Date: Wed, 10 Dec 2008 15:53:22 -0800 From: "fan zhao" To: "Tero Kivinen" In-Reply-To: <18749.21666.801967.227066@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> <18749.21666.801967.227066@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero and all, Please see some additional clarification below. >> In this case, the client would waste a packet and IPsec processing >> time on this packet, and the client cannot connect to the correct >> server as soon as possible. This is not good especially when there >> is existing session between the client and the correct server. > As the server most likely already responded with the NO_ADDITIONAL_SAS > error during the IKE_AUTH, the server and client do not have IPsec SA > between them. They only have IKE SA. And the exactly same delay will > happen if the packet containing N(REDIRECT) is lost, regardless > whether it is part of the IKE_AUTH or INFORMATIONAL exchange. The scenario I was considering is that previously the traffic between the client and its peer node is forwarded through a server, called server_a, with the IPsec functionality. The AAA server or other back-end server stores the address of server_a. However, the client does not set up the IPsec SA with the server_a when using some mobility protocol (such as Proxy Mobile IPv6). Now the client handovers to another access network where only a different mobility protocol (such as Mobile IPv6) is supported. Such mobility protocol requires that traffic between the client and its peer node to be forwarded through the IPsec tunnel between the client and the server_a. However, the client does not have the IP address of the server_a (since it does not need to know, with Proxy Mobile IPv6). After performing discovery, such as DNS, the client discovers a different server, called server_b, and starts the IKE procedure with the server_b. Then the server_b realizes (e.g. during interaction with the AAA/other server) that the client needs to set up the SA with server_a in order to continue the current session with the client's peer node. Thus redirection needs to be performed. During handover, it is important to minimize delay for network connectivity re-establishment in order to reduce packet delay and improve performance. Sincerely, fan On Mon, Dec 8, 2008 at 9:08 AM, Tero Kivinen wrote: > fan zhao writes: >> I do not see why adding the REDIRECT payload can affect the authentication >> combination. The authentication of the last IKE_AUTH message is done >> independently and actually before the processing of the REDIRECT payload. >> Sure, we should consider all possible cases. Do you find anything broken? > > The number of packets sent in the IKE_AUTH will change for EAP for > example, and the REDIRECT payload changes location depending what > authentication method is used (i.e. it would be in the last). This > means that at least EAP vs non EAP case is mandatory to test, but in > general good QA will test all possible combinations to make sure there > is nothing that breaks when other authentication methods are used. > > I agree that making bug that is only affected by certain > authentication combination might not be the most common bug to make, > but on the other hand bugs do not tend to be very predictable in > general. > >> > * 2). It needs to be tested with other initial exchange combinations, >> > i.e. INVALID_KE_PAYLOAD and COOKIE notification cases, it needs to be >> > tested with MOBIKE extensions, it needs to be tested with NAT >> > traversal cases, etc. >> Still I do not see anyhting could be broken. To my best knowledgement, >> I do not see this can break MOBIKE and NAT traversal either. >> Can you give me an example? > > For example for NAT traversal you still need to make sure the client > uses correct port to connect the new server. The current draft does > not say whether client should connect to directly to port 4500 or > restart at port 500. Both of them do have benefits. With mobike the > complication could be for example that IP-addresses change between > IKE_SA_INIT and IKE_AUTH, or when combininig MOBIKE with NAT > traversal, you do the port float to port 4500 before you start > IKE_AUTH etc. > > I cannot really guess what kind of bugs people tend to write... But > implementations usually do have bugs, and implementations needs to be > tested before they can be put out. The more options we have the more > testing there is to do. > >> By the testing effort, do you mean the "conditions" in the program >> or the testing cases? There are many different ways for >> implementation. From the protocol perspective, the state transition >> is simple: after all the processing, specified in the IKEv2 >> protocol, of the last IKE_AUTH message, then the client processes >> the REDIRECT payload. > > I mean the test done by the QA before any release is done, and also > interoperability testing done in the IPsec interoperability events. > >> I worry more about the "consequence" of packet reordering/loss. > > That is something your current QA people should already be testing > before you release anything, as it is critical security feature, and > if that is broken, then your implementation is unsecure. > > This is something that MUST be done for the plain IKEv2 already, this > extension does not add any new requirements for this part. > >> I agree that packet reordering/loss can be handled. But even so, delay and >> overhead are introduced. As an example, assume that the server sends >> the last IKE_AUTH message and then a informational message with >> the REDIRECT payload. If the informational message is lost during the >> transmission, the server does not know until it receives an IPsec packet >> from the client again; > > Server will know the informational packet was lost, as it does not > receive reply back from the client. This again is standard IKEv2 > feature, that must be tested by the QA before any products can be put > out, as it affects the whole IKEv2 protocol implementation. > >> then the server needs to send another informational >> message with the REDIRECT payload to the client. > > The server would not send another informational message, he would > resend the previous request, and he will resend it until the client > will reply. If the client will not reply then server will tear down > the IKE SA and assume the connection is broken. Again this is standard > operation that must be correctly handled by all implementations, which > means it should be tested by the QA already (hopefully part of their > automatic testing suite). > >> In this case, the client would waste a packet and IPsec processing >> time on this packet, and the client cannot connect to the correct >> server as soon as possible. This is not good especially when there >> is existing session between the client and the correct server. > > As the server most likely already responded with the NO_ADDITIONAL_SAS > error during the IKE_AUTH, the server and client do not have IPsec SA > between them. They only have IKE SA. And the exactly same delay will > happen if the packet containing N(REDIRECT) is lost, regardless > whether it is part of the IKE_AUTH or INFORMATIONAL exchange. > >> Thanks for explanation. Yes I agree with you: so in the redirection >> case, if the REDIRECT payload is received before the last AUTH >> message (i.e. reordering), the client shoudl reject it. > > Yes. > >> Then the >> sqerver would have to send another REDIRECT payload to the client >> again after it realizes that the client is not redirected yet, >> right? Thanks. > > It will resend the packet containing the N(REDIRECT) notify when it > realizeds it has not received reply packet for that. Meaning it will > resend it after 0.5-1 second or so. > -- > kivinen@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nnheae@a-mtool.com Thu Dec 11 02:16:40 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B6F3A6C2A for ; Thu, 11 Dec 2008 02:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.558 X-Spam-Level: X-Spam-Status: No, score=-28.558 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 sC2IeezhYX9X for ; Thu, 11 Dec 2008 02:16:40 -0800 (PST) Received: from 122-116-143-34.HINET-IP.hinet.net (122-116-143-34.HINET-IP.hinet.net [122.116.143.34]) by core3.amsl.com (Postfix) with SMTP id 8C7943A6A80 for ; Thu, 11 Dec 2008 02:16:38 -0800 (PST) To: Subject: RE: Message From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211101638.8C7943A6A80@core3.amsl.com> Date: Thu, 11 Dec 2008 02:16:38 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Thu Dec 11 03:16: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 48EF328C0D6; Thu, 11 Dec 2008 03:16:24 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3029028C0D6 for ; Thu, 11 Dec 2008 03:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, 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 yzm0v51LPEvI for ; Thu, 11 Dec 2008 03:16:21 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 118AE3A6A8C for ; Thu, 11 Dec 2008 03:16:20 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBBBG8UV024545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2008 13:16:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBBBG6fL003488; Thu, 11 Dec 2008 13:16:06 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18752.63094.766199.617640@fireball.kivinen.iki.fi> Date: Thu, 11 Dec 2008 13:16:06 +0200 From: Tero Kivinen To: "fan zhao" In-Reply-To: References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> <18749.21666.801967.227066@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org fan zhao writes: > Sorry I did not reply earlier. I was moving during last few days. > After quickly going over your comments, I agree what you mentioned > are valid issues and they should be considered and addressed during > implementation. However, these issues are implementation specific, > not related to protocol design and it is feasible to address such issues > (bugs) during implementation. Yes, and as those implementation details must be done correctly for the IKEv2 to be secure, there is no point of us to try to avoid such cases with redirct messages. > Furthermore, I agree that the IPsec server can wait for the timer to > expire to detect whether the informational message with the redirect > is lost or not. However, there is still delay that could affect performance > very much. This is a flaw of design, IMHO, which means > that even though the implementation is bug-free and very efficient, > when reordering and paket loss happen, there is nothing we can do. > The performance is very important to user experience. I would like > argue that given such considerations, redirect should be enabled > during IKE_AUTH. Regardless what we do if the IKE_AUTH reply packet is lost or if the INFORMATIONAL exchange having the REDIRECT notify is lost, there will be delay where we need to wait for retransmissions. It does not matter how we do the protocol, there will still be delays if we loose packets. Reordering does not need to cause any delay, as implementation can handle that internally and it can simply put the out of order packet on hold until IKE_AUTH is processed and then continue processing the other packet. Note, that doing the Diffie-Hellman and signature calculations twice here usually means about same order of magnitude delay than the one retranmission timer, thus even on those very rare cases where you have packet loss of hitting the INFORMATIONAL exchange packet, the delay should not really be visible to user (i.e. it should be less than one second). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From matumura@aic-jp.com Thu Dec 11 03:50:38 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40DEE28C0F2 for ; Thu, 11 Dec 2008 03:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -39.13 X-Spam-Level: X-Spam-Status: No, score=-39.13 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 oKStdHf9X7L5 for ; Thu, 11 Dec 2008 03:50:37 -0800 (PST) Received: from amaa.com (unknown [89.105.238.93]) by core3.amsl.com (Postfix) with SMTP id 5F90C3A6A1A for ; Thu, 11 Dec 2008 03:50:35 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211115036.5F90C3A6A1A@core3.amsl.com> Date: Thu, 11 Dec 2008 03:50:35 -0800 (PST)
Visit site now!

From miihaels@aeh.com.au Thu Dec 11 08:21:20 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B69EB3A6867 for ; Thu, 11 Dec 2008 08:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.53 X-Spam-Level: X-Spam-Status: No, score=-7.53 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVJuQjhqGPWW for ; Thu, 11 Dec 2008 08:21:20 -0800 (PST) Received: from afmsupply.com (unknown [190.188.64.160]) by core3.amsl.com (Postfix) with SMTP id EEB213A6782 for ; Thu, 11 Dec 2008 08:21:17 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211162117.EEB213A6782@core3.amsl.com> Date: Thu, 11 Dec 2008 08:21:17 -0800 (PST)
Visit site now!

From jhdd@alphatech.com Thu Dec 11 10:26:59 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 362F83A6A8E for ; Thu, 11 Dec 2008 10:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ak3TER353woG for ; Thu, 11 Dec 2008 10:26:58 -0800 (PST) Received: from host86-133-173-196.range86-133.btcentralplus.com (host86-133-173-196.range86-133.btcentralplus.com [86.133.173.196]) by core3.amsl.com (Postfix) with SMTP id 582433A6A8D for ; Thu, 11 Dec 2008 10:26:56 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211182657.582433A6A8D@core3.amsl.com> Date: Thu, 11 Dec 2008 10:26:56 -0800 (PST)
Visit site now!

From ipsec-bounces@ietf.org Thu Dec 11 11:00: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 65FEE3A69A0; Thu, 11 Dec 2008 11:00:03 -0800 (PST) X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1FF3C3A69A0; Thu, 11 Dec 2008 11:00:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081211190002.1FF3C3A69A0@core3.amsl.com> Date: Thu, 11 Dec 2008 11:00:02 -0800 (PST) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-02.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: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Re-direct Mechanism for IKEv2 Author(s) : V. Devarapalli, K. Weniger Filename : draft-ietf-ipsecme-ikev2-redirect-02.txt Pages : 13 Date : 2008-12-11 IKEv2 is a 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 or a VPN gateway that is being shut down for maintenance 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 in 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-ietf-ipsecme-ikev2-redirect-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-redirect-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-12-11104733.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --NextPart-- From mzakariya@advint.com Thu Dec 11 13:07:04 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908463A67D6 for ; Thu, 11 Dec 2008 13:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.409 X-Spam-Level: X-Spam-Status: No, score=-9.409 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roKO1CkQm24j for ; Thu, 11 Dec 2008 13:07:04 -0800 (PST) Received: from aktivsoftware.de (unknown [77.227.67.242]) by core3.amsl.com (Postfix) with SMTP id 9B2FE3A6774 for ; Thu, 11 Dec 2008 13:07:01 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211210702.9B2FE3A6774@core3.amsl.com> Date: Thu, 11 Dec 2008 13:07:01 -0800 (PST)
Visit site now!

From journalistic044@akc-web.de Thu Dec 11 15:58:24 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E12F3A699C for ; Thu, 11 Dec 2008 15:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.93 X-Spam-Level: X-Spam-Status: No, score=-7.93 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_IMG_ONLY=1.666, SARE_RECV_SKANOVA=0.66, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAN08kHCthx3 for ; Thu, 11 Dec 2008 15:58:23 -0800 (PST) Received: from h80n10c1o1039.bredband.skanova.com (h226n10c1o1039.bredband.skanova.com [81.230.37.226]) by core3.amsl.com (Postfix) with SMTP id 9C7493A6833 for ; Thu, 11 Dec 2008 15:58:21 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081211235822.9C7493A6833@core3.amsl.com> Date: Thu, 11 Dec 2008 15:58:21 -0800 (PST)
Visit site now!

From ipsec-bounces@ietf.org Thu Dec 11 18:02: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 8AE943A6A74; Thu, 11 Dec 2008 18:02:48 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35D93A69B1 for ; Thu, 11 Dec 2008 18:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puSE4rN+dniy for ; Thu, 11 Dec 2008 18:02:47 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by core3.amsl.com (Postfix) with ESMTP id 2210B3A6A74 for ; Thu, 11 Dec 2008 18:02:47 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so1162325rvf.49 for ; Thu, 11 Dec 2008 18:02:40 -0800 (PST) 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=UOfVXxCEqKzXMR7nzEQ+WZrI2vfGV26C4pXaonqEXlk=; b=gXQr2Tv7m6tKX8okGDvj0gIeum9rK0TpN1YDGqECp5U+8o0RVfcjH2XTf8KRNrf/+T K/gwTMW63yOy3DPSOSxugxOmME0jS+2opogyk+m59OHmiOiGmkFRrlQQgpBzyDQG2q76 HAX5z+WZwUeFL+/DpqbKA9lLQBA90uQPxeDkQ= 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=shcrl5Z6c8TjfcqbTZ9cHH9QUEIFLAbNaLnjJwxNowtz4xmtgM8/eiq/bjIwc3Q8nI ZDNio82y06t9LUaYPjR5b0NyPWGrbZp7weA7gqfDbnox88PsI5qS6NeoJKMlEdfc3IqM nKP2CbkssGmJHcEc3lvLhcG3uWSQMkcK/U/j8= Received: by 10.141.168.7 with SMTP id v7mr3465764rvo.0.1229047360683; Thu, 11 Dec 2008 18:02:40 -0800 (PST) Received: by 10.141.196.14 with HTTP; Thu, 11 Dec 2008 18:02:40 -0800 (PST) Message-ID: Date: Thu, 11 Dec 2008 18:02:40 -0800 From: "fan zhao" To: "Tero Kivinen" In-Reply-To: <18752.63094.766199.617640@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> <18749.21666.801967.227066@fireball.kivinen.iki.fi> <18752.63094.766199.617640@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, Thanks for your reply. Please see below. On Thu, Dec 11, 2008 at 3:16 AM, Tero Kivinen wrote: > fan zhao writes: >> Sorry I did not reply earlier. I was moving during last few days. >> After quickly going over your comments, I agree what you mentioned >> are valid issues and they should be considered and addressed during >> implementation. However, these issues are implementation specific, >> not related to protocol design and it is feasible to address such issues >> (bugs) during implementation. > > Yes, and as those implementation details must be done correctly for > the IKEv2 to be secure, there is no point of us to try to avoid such > cases with redirct messages. > >> Furthermore, I agree that the IPsec server can wait for the timer to >> expire to detect whether the informational message with the redirect >> is lost or not. However, there is still delay that could affect performance >> very much. This is a flaw of design, IMHO, which means >> that even though the implementation is bug-free and very efficient, >> when reordering and paket loss happen, there is nothing we can do. >> The performance is very important to user experience. I would like >> argue that given such considerations, redirect should be enabled >> during IKE_AUTH. > > Regardless what we do if the IKE_AUTH reply packet is lost or if the > INFORMATIONAL exchange having the REDIRECT notify is lost, there will > be delay where we need to wait for retransmissions. It does not matter > how we do the protocol, there will still be delays if we loose > packets. I agree that if the last IKE_AUTH reply message from the server is lost, no matter whether the REDIRECT is included or not, there will be the same amount of delay. Nevertheless, it is possible that the last IKE_AUTH message goes through and the informational message with the REDIRECT notify is lost. In this case, the delay is longer than if the REDIRECT notify is included in the last IKE_AUTH message. > Reordering does not need to cause any delay, as > implementation can handle that internally and it can simply put the > out of order packet on hold until IKE_AUTH is processed and then > continue processing the other packet. I understand this can be done to reduce the delay. However, this is probably not a standard behavior per RCF 4306 as it just mentions that after an IKE_SA is set up, an IKE end point can send multiple requests if the SET_WINDOW_SIZE is received from its peer. So interoperability between different implementations needs to be tested because another implementation of the client may simply drop the reordered informational message with the N(REDIRECT) and the implementation of the server needs to prepare if that happens, it needs to re-transmit the N(REDIRECT). Do I understand correctly? > > Note, that doing the Diffie-Hellman and signature calculations twice > here usually means about same order of magnitude delay than the one > retranmission timer, thus even on those very rare cases where you have > packet loss of hitting the INFORMATIONAL exchange packet, the delay > should not really be visible to user (i.e. it should be less than one > second). During handover, the delay needs to be smaller than 0.2 second; otherwise, it is noticeable to users. Sincerely, fan > -- > kivinen@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 11 23:41: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 88BD13A6AAC; Thu, 11 Dec 2008 23:41:41 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 041EA3A6A83 for ; Thu, 11 Dec 2008 23:39:55 -0800 (PST) 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 nMfyyryvETja for ; Thu, 11 Dec 2008 23:39:54 -0800 (PST) Received: from mail-gx0-f12.google.com (mail-gx0-f12.google.com [209.85.217.12]) by core3.amsl.com (Postfix) with ESMTP id 2961E3A69EC for ; Thu, 11 Dec 2008 23:39:53 -0800 (PST) Received: by gxk5 with SMTP id 5so810290gxk.13 for ; Thu, 11 Dec 2008 23:39:46 -0800 (PST) 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:references; bh=B0k0PdVPwnVdJvMzgDp28H+RpaVAbWruFJRr6CZLKns=; b=lWQFYGYZFy0QZHZYGVdmpwx2RrLRZ5+om7sm3jGwUP4rb8wDJY27+UefsrkXxCL9O/ 4Nom2GQzIY67JJ6gEWfb2FHEnxhj31Ocz+r2bYIN3/vpJlUtQ86m0P392cm8o607S0y1 dqPBgQIe0O9yPCr19brLwcqcgVsNmOX7Q0PGs= 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:references; b=Gq5i8ZVStW1uRiigfP06z/WQU9oAlBmqwQyW2cbqELc5jqrs8OtvlGOyadLkM46tEF Z1ZhrpfuyyNFC7NL0tAnarvUAHeYLOCY+PiJcI8SlZFnu0E93GN9ItQeW+C9tJFkauXh h3vTEa7c884NmP4Lkng3nZ5/974+DhpDuBhPI= Received: by 10.150.229.5 with SMTP id b5mr5866426ybh.147.1229067586564; Thu, 11 Dec 2008 23:39:46 -0800 (PST) Received: by 10.151.154.9 with HTTP; Thu, 11 Dec 2008 23:39:46 -0800 (PST) Message-ID: <64a9a4a70812112339i765d9812t194db001b6ec310b@mail.gmail.com> Date: Fri, 12 Dec 2008 15:39:46 +0800 From: Patricia To: ipsec@ietf.org In-Reply-To: <64a9a4a70812112331m25dd60b7w201f8beef4cc7952@mail.gmail.com> MIME-Version: 1.0 References: <64a9a4a70812112316p1ee69589k297b77721f4a488b@mail.gmail.com> <64a9a4a70812112331m25dd60b7w201f8beef4cc7952@mail.gmail.com> Subject: [IPsec] IKEv2 CP with CREATE-CHILD-SA exchange 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="===============1109731888==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1109731888== Content-Type: multipart/alternative; boundary="----=_Part_21441_29272233.1229067586532" ------=_Part_21441_29272233.1229067586532 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, When I was reading RFC4306 & 4718, I had one puzzle on IKEv2 CP. According to RFC4306 2.19, "A request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload." But I'm a little confused about how it is used with CREATE-CHILD-SA exchange and what it is used for. Does it mean that the IRAS is going to assign a different IP for each of CREATE-CHILD-SA exchange? If so, since there is no EAP at this stage, the IP can be got only from local pool but not from external server. Is it such case? Thanks, Patricia ------=_Part_21441_29272233.1229067586532 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,
When I was reading RFC4306 & 4718, I had one puzzle on IKEv2 CP. According to RFC4306 2.19,
"A request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload."
But I'm a little confused about how it is used with CREATE-CHILD-SA exchange and what it is used for. Does it mean that the IRAS is going to assign a different IP for each of CREATE-CHILD-SA exchange? If so, since there is no EAP at this stage, the IP can be got only from local pool but not from external server. Is it such case?
 
Thanks,
Patricia ------=_Part_21441_29272233.1229067586532-- --===============1109731888== 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 --===============1109731888==-- From ipsec-bounces@ietf.org Fri Dec 12 06:23: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 09DBB3A6B0A; Fri, 12 Dec 2008 06:23:20 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 271933A6B0A for ; Fri, 12 Dec 2008 06:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 2knfidWvzPyy for ; Fri, 12 Dec 2008 06:23:17 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id EC6E43A6AFE for ; Fri, 12 Dec 2008 06:23:16 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBCEN4fq024181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Dec 2008 16:23:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBCEN3DD003492; Fri, 12 Dec 2008 16:23:03 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18754.29639.787080.201046@fireball.kivinen.iki.fi> Date: Fri, 12 Dec 2008 16:23:03 +0200 From: Tero Kivinen To: "fan zhao" In-Reply-To: References: <18742.32982.788647.641072@fireball.kivinen.iki.fi> <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> <18749.21666.801967.227066@fireball.kivinen.iki.fi> <18752.63094.766199.617640@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org fan zhao writes: > > Reordering does not need to cause any delay, as > > implementation can handle that internally and it can simply put the > > out of order packet on hold until IKE_AUTH is processed and then > > continue processing the other packet. > I understand this can be done to reduce the delay. However, this is > probably not a standard behavior per RCF 4306 as it just mentions that after > an IKE_SA is set up, an IKE end point can send multiple requests > if the SET_WINDOW_SIZE is received from its peer. We are not talking about multiple requests, we are talking about one request that arrives before the IKE_AUTH is processed. If your environment is so delay critical that delay of 500 ms is unacceptable for it when those specific two packets happen to arrive out of order, then you should implement code to get rid of it. > So interoperability between different implementations needs to be > tested because another implementation of the client may simply drop > the reordered informational message with the N(REDIRECT) and the > implementation of the server needs to prepare if that happens, it > needs to re-transmit the N(REDIRECT). Do I understand correctly? There is no need to do interoperability testing, as both options are completely within the specifications and complient implementations MUST cope with both. The server always must be prepared to re-transmit its message regardless what other end does, as the packet might also get lost, not just get dropped. >From servers point of view it is either so that packet was dropped and it needed to be resent, or packet was accepted by other end (either in order, or out of order and reordered by client) and reply was sent back to server. Again this is standard IKEv2, and if IKEv2 implementations do not get their base retransmission algorithms working, then that implementation should not be used in anywhere... > > Note, that doing the Diffie-Hellman and signature calculations twice > > here usually means about same order of magnitude delay than the one > > retranmission timer, thus even on those very rare cases where you have > > packet loss of hitting the INFORMATIONAL exchange packet, the delay > > should not really be visible to user (i.e. it should be less than one > > second). > During handover, the delay needs to be smaller than 0.2 second; otherwise, > it is noticeable to users. During our mobike testing, we noticed that most of the delays caused by network because of mobility were in the order of tens of seconds, not in order of milliseconds. For example the DHCP usually takes about 5-20 seconds to get new IP address from the new network... 0.2 seconds is not really doable if you have round trip times of 200 ms (0.2 seconds) like I have from Finland to US... Also most of the Phones and similar has so slow CPU that Diffie-Hellman and the RSA signing takes close to that 0.2 seconds... -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Dec 13 08:46: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 0FBD428C110; Sat, 13 Dec 2008 08:46:56 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 170F03A6821 for ; Fri, 12 Dec 2008 08:21:43 -0800 (PST) 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 KDAtaF4CpyWv for ; Fri, 12 Dec 2008 08:21:40 -0800 (PST) Received: from exprod7og115.obsmtp.com (exprod7ob115.obsmtp.com [64.18.2.216]) by core3.amsl.com (Postfix) with SMTP id 9246C3A67F7 for ; Fri, 12 Dec 2008 08:21:39 -0800 (PST) Received: from source ([63.149.188.148]) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSUKPjQjQ5tQaKdOwEbS+Oh3IsturFhHV@postini.com; Fri, 12 Dec 2008 08:21:34 PST Received: from GBMDMail01.genband.com ([192.168.15.38]) by gbdmail1.genband.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Dec 2008 10:20:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 12 Dec 2008 11:20:52 -0500 Message-ID: <593E210EDC38444DA1C17E9E9F5E264B893FC3@GBMDMail01.genband.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question about D-H transform and PFS Thread-Index: AclcdtoW8N1+3phvQIGJ/0cKtpdp3g== From: "Jonathan Childs" To: X-OriginalArrivalTime: 12 Dec 2008 16:20:53.0690 (UTC) FILETIME=[9AECA9A0:01C95C75] X-Mailman-Approved-At: Sat, 13 Dec 2008 08:46:55 -0800 Subject: [IPsec] Question about D-H transform and PFS 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="===============0028673867==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0028673867== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C95C75.9A6AE9BD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C95C75.9A6AE9BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 We are having an interoperability problem and I couldn't seem to find the answer in any of the RFCs, so I was hoping someone on the list could give some input. Both sides are configured to do PFS but the problem appears to be that one side expects the D-H transform in every message (including the IKE_AUTH message) and the other only expects it only in the CREATE_CHILD_SA messages. So does anyone know the correct procedure here? Are the D-H transforms usually included in every message or just for IPSEC SAs after the 1st one that comes as part of the IKE negotiations? =20 Thanks Jon ------_=_NextPart_001_01C95C75.9A6AE9BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We are having an interoperability problem and I = couldn’t seem to find the answer in any of the RFCs, so I was hoping someone on = the list could give some input.  Both sides are configured to do PFS but the problem appears to be that one side expects the D-H transform in every = message (including the IKE_AUTH message) and the other only expects it only in =  the CREATE_CHILD_SA messages.  So does anyone know the correct = procedure here?  Are the D-H transforms usually included in every message or = just for IPSEC SAs after the 1st one that comes as part of the IKE negotiations?

 

Thanks

Jon

------_=_NextPart_001_01C95C75.9A6AE9BD-- --===============0028673867== 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 --===============0028673867==-- From ipsec-bounces@ietf.org Sat Dec 13 13:06:58 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF563A68A0; Sat, 13 Dec 2008 13:06:58 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27B5E3A68A0 for ; Sat, 13 Dec 2008 13:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.014, 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 BKEPhTkwoSVx for ; Sat, 13 Dec 2008 13:06:55 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 54B3F3A67EC for ; Sat, 13 Dec 2008 13:06:55 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D53FA29C002; Sat, 13 Dec 2008 23:06:47 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B10A829C001; Sat, 13 Dec 2008 23:06:03 +0200 (IST) X-CheckPoint: {494422A1-10000-88241DC2-7B6} Received: from [172.31.21.39] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBDL63fE000795; Sat, 13 Dec 2008 23:06:03 +0200 (IST) Message-Id: <2216F040-57EB-44DF-BD78-E7E2A093518F@checkpoint.com> From: Yoav Nir To: Jonathan Childs In-Reply-To: <593E210EDC38444DA1C17E9E9F5E264B893FC3@GBMDMail01.genband.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 13 Dec 2008 23:06:02 +0200 References: <593E210EDC38444DA1C17E9E9F5E264B893FC3@GBMDMail01.genband.com> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] Question about D-H transform and PFS 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="===============1276569088==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1276569088== Content-Type: multipart/alternative; boundary=Apple-Mail-1--360424483 --Apple-Mail-1--360424483 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Jon PFS never applies to the child SA created in the IKE_AUTH exchange. See Appendix A.2 and A.3 in RFC 4718. Also, section 1.3 of RFC 4306 has the following: In the CHILD_SA created as part of the initial exchange, a second KE payload and nonce MUST NOT be sent. The nonces from the initial exchange are used in computing the keys for the CHILD_SA. On Dec 12, 2008, at 6:20 PM, Jonathan Childs wrote: > Hi all, > > We are having an interoperability problem and I couldn=92t seem to =20 > find the answer in any of the RFCs, so I was hoping someone on the =20 > list could give some input. Both sides are configured to do PFS but =20= > the problem appears to be that one side expects the D-H transform in =20= > every message (including the IKE_AUTH message) and the other only =20 > expects it only in the CREATE_CHILD_SA messages. So does anyone =20 > know the correct procedure here? Are the D-H transforms usually =20 > included in every message or just for IPSEC SAs after the 1st one =20 > that comes as part of the IKE negotiations? > > Thanks > Jon =0D=0A Email secured by Check Point=0D=0A --Apple-Mail-1--360424483 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Jon

PFS = never applies to the child SA created in the IKE_AUTH = exchange. 

See Appendix A.2 and A.3 in RFC = 4718.

Also, section 1.3 of RFC 4306 has the = following:

   In the CHILD_SA created as part =
of the initial exchange, a second KE
   payload and nonce MUST NOT be sent.  The nonces from the initial
   exchange are used in computing the keys for the =
CHILD_SA.

On Dec 12, 2008, at 6:20 = PM, Jonathan Childs wrote:

Hi all,
 
We are having an = interoperability problem and I couldn=92t seem to find the answer in any = of the RFCs, so I was hoping someone on the list could give some = input.  Both sides are configured to do PFS but the problem appears = to be that one side expects the D-H transform in every message = (including the IKE_AUTH message) and the other only expects it only in =  the CREATE_CHILD_SA messages.  So does anyone know the = correct procedure here?  Are the D-H transforms usually included in = every message or just for IPSEC SAs after the 1st one that comes as part of = the IKE negotiations?
 
Thanks
X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D744F3A695D for ; Sun, 14 Dec 2008 03:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.351 X-Spam-Level: X-Spam-Status: No, score=-25.351 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HOST_EQ_D_D_D_DB=0.888, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_HEXIP=2.204, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DK=1.009, HELO_EQ_DSL=1.129, HELO_EQ_DYNAMIC=1.144, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 wBJve5zeVkqd for ; Sun, 14 Dec 2008 03:22:29 -0800 (PST) Received: from 0x50a14e64.odnxx3.dynamic.dsl.tele.dk (0x50a14e64.odnxx3.dynamic.dsl.tele.dk [80.161.78.100]) by core3.amsl.com (Postfix) with SMTP id 5E19D3A6956 for ; Sun, 14 Dec 2008 03:22:27 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 000773-1, 06-09-2007), Outbound message X-Antivirus-Status: Clean Message-Id: <20081214112228.5E19D3A6956@core3.amsl.com> Date: Sun, 14 Dec 2008 03:22:27 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Sun Dec 14 05:29: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 3172B3A6886; Sun, 14 Dec 2008 05:29:47 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB003A6886 for ; Sun, 14 Dec 2008 05:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.013, 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 L7owOkx1emGR for ; Sun, 14 Dec 2008 05:29:44 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 4F9443A63D3 for ; Sun, 14 Dec 2008 05:29:44 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D2B9629C003; Sun, 14 Dec 2008 15:29:36 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8870229C002; Sun, 14 Dec 2008 15:27:55 +0200 (IST) X-CheckPoint: {494508BA-10003-88241DC2-7B6} Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id mBEDRtfH011238; Sun, 14 Dec 2008 15:27:55 +0200 (IST) Message-Id: <682B1483-DDBE-4B90-AB17-6D734F6031C4@checkpoint.com> From: Yoav Nir To: Tero Kivinen In-Reply-To: <18750.28308.704.651625@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 14 Dec 2008 15:27:50 +0200 References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017C@il-ex01.ad.checkpoint.com> <8ADA5BBD-2BC8-4997-91EB-2BB584963EB4@checkpoint.com> <18750.28308.704.651625@fireball.kivinen.iki.fi> X-Mailer: Apple Mail (2.929.2) Cc: IPsecme WG Subject: Re: [IPsec] #30: Conflicts in DH proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Dec 9, 2008, at 3:11 PM, Tero Kivinen wrote: > >> The DH Group # identifies the Diffie-Hellman group in which the >> Key >> Exchange Data was computed (see Section 3.3.2). This Group # MUST >> match a DH Group specified in a proposal in the SA payload that is >> sent in the same message, and SHOULD match the strongest DH Group >> in any of the proposals of that SA payload. If none of the >> proposals >> in that SA payload specifies a DH Group, the KE payload MUST NOT >> be >> present. If the selected proposal uses a different Diffie-Hellman >> group (other than NONE), the message MUST be rejected with a >> Notify >> payload of type INVALID_KE_PAYLOAD. > > I do not think we can add new "SHOULD" in this time, i.e. I would > remove the ", and SHOULD match the strongest DH Group in any of the > proposals of that SA payload" part. There are problems to define > stength order for different Diffie-Hellman groups, especially if they > use different methods, i.e. some use elliptic curves and some are MODP > groups. > > Otherwise the text looks good. how about, ", and should match the DH group is the most preferred group in the most preferred proposal, if such exists" - lower case should? I'm fine with dropping it all together as you suggested. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From pagni@ambito.com.ar Sun Dec 14 06:44:26 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 231213A6848 for ; Sun, 14 Dec 2008 06:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.742 X-Spam-Level: X-Spam-Status: No, score=-28.742 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, 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 fzFo-0ZZeQI6 for ; Sun, 14 Dec 2008 06:44:25 -0800 (PST) Received: from 62-101-65-21.ip.fastwebnet.it (62-101-65-21.ip.fastwebnet.it [62.101.65.21]) by core3.amsl.com (Postfix) with SMTP id 46A633A6407 for ; Sun, 14 Dec 2008 06:44:23 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081214144424.46A633A6407@core3.amsl.com> Date: Sun, 14 Dec 2008 06:44:23 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Sun Dec 14 12:26:16 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242C23A6881; Sun, 14 Dec 2008 12:26:16 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0FE3A6817 for ; Sun, 14 Dec 2008 12:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 yd5iiuzQyEXT for ; Sun, 14 Dec 2008 12:26:14 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id CB22B3A67F4 for ; Sun, 14 Dec 2008 12:26:13 -0800 (PST) Received: by qyk4 with SMTP id 4so2365545qyk.13 for ; Sun, 14 Dec 2008 12:26:05 -0800 (PST) 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=rmd3TzGxK/1MsT+46D40jU+UNRvlhtqSX99mHSya2rg=; b=G0QAr7N3uL6nngc24+ypsbVCpLZvqAJE54hRK8G/nFQJrTN8ILTPMIEHO1kuzaOj4l rsciIJqnD3/eE8M0TvuN6+eD1IO009yG1yLr/JZeMOkzt6hkPbeLO55V4clCZ88eRvqx HaJmUwqnmfxEjvgyH4A9YZJxW3RosPzY0tBIA= 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=UhtrskXAVeceGtEE39NFGnjHv+F73WW+Cqn4G0uVilex5Wmr6F2+ZPyJgwlxdFPG0e ceTae9PpWzr/oNjV9K9f7mJQ/yCDWcE5KMrYUr4tPZc7XSfhyw7bpji0qbifdR98LGvS 7HpA0ZBAovMP1MIaTUG1LEz3mtNh4l0d2EgEY= Received: by 10.214.60.2 with SMTP id i2mr6916656qaa.364.1229286365833; Sun, 14 Dec 2008 12:26:05 -0800 (PST) Received: by 10.215.14.1 with HTTP; Sun, 14 Dec 2008 12:26:05 -0800 (PST) Message-ID: Date: Sun, 14 Dec 2008 12:26:05 -0800 From: "fan zhao" To: "Tero Kivinen" In-Reply-To: <18754.29639.787080.201046@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> <18749.21666.801967.227066@fireball.kivinen.iki.fi> <18752.63094.766199.617640@fireball.kivinen.iki.fi> <18754.29639.787080.201046@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, Please see below. On Fri, Dec 12, 2008 at 6:23 AM, Tero Kivinen wrote: > fan zhao writes: >> > Reordering does not need to cause any delay, as >> > implementation can handle that internally and it can simply put the >> > out of order packet on hold until IKE_AUTH is processed and then >> > continue processing the other packet. >> I understand this can be done to reduce the delay. However, this is >> probably not a standard behavior per RCF 4306 as it just mentions that after >> an IKE_SA is set up, an IKE end point can send multiple requests >> if the SET_WINDOW_SIZE is received from its peer. > > We are not talking about multiple requests, we are talking about one > request that arrives before the IKE_AUTH is processed. This is exactly my point. It is not clearly specified in the RFC that reordering of the last IKE_AUTH and sequent requests need to be handled. > If your > environment is so delay critical that delay of 500 ms is unacceptable > for it when those specific two packets happen to arrive out of order, > then you should implement code to get rid of it. I do not know exact reasons why the RFC does not specify how to handle the reordered AUTH message and the requests. Anyway, if it is not required by the RFC, then some (RFC-compliant) implementation may not support that. > >> So interoperability between different implementations needs to be >> tested because another implementation of the client may simply drop >> the reordered informational message with the N(REDIRECT) and the >> implementation of the server needs to prepare if that happens, it >> needs to re-transmit the N(REDIRECT). Do I understand correctly? > > There is no need to do interoperability testing, as both options are > completely within the specifications and complient implementations > MUST cope with both. Does RFC 4306 talk about storing the reordered request before processing last AUTH message? Maybe I miss something. > The server always must be prepared to re-transmit > its message regardless what other end does, as the packet might also > get lost, not just get dropped. I agree on this part. > > From servers point of view it is either so that packet was dropped and > it needed to be resent, or packet was accepted by other end (either in > order, or out of order and reordered by client) and reply was sent > back to server. > > Again this is standard IKEv2, and if IKEv2 implementations do not get > their base retransmission algorithms working, then that implementation > should not be used in anywhere... > >> > Note, that doing the Diffie-Hellman and signature calculations twice >> > here usually means about same order of magnitude delay than the one >> > retranmission timer, thus even on those very rare cases where you have >> > packet loss of hitting the INFORMATIONAL exchange packet, the delay >> > should not really be visible to user (i.e. it should be less than one >> > second). >> During handover, the delay needs to be smaller than 0.2 second; otherwise, >> it is noticeable to users. > > During our mobike testing, we noticed that most of the delays caused > by network because of mobility were in the order of tens of seconds, > not in order of milliseconds. For example the DHCP usually takes about > 5-20 seconds to get new IP address from the new network... 0.2 seconds > is not really doable if you have round trip times of 200 ms (0.2 > seconds) like I have from Finland to US... Yes, there are many factors affecting handover delay and there are various optimization solutions. For example, the IP configuration can be done proactively based on the fast handover for MIPv6 protocol. While it is possible that even with all kinds of optimizations, the handover delay is still larger than 0.2 second, the point here I am trying to make is that we should not make the (already unacceptable) delay become even worse. Even though the delay caused by packet loss/reordering is of the same order of magnitude or smaller than other kind of delay, I would like to argue that it is still beneficial to avoid adding such delay. Sincerely, fan > > Also most of the Phones and similar has so slow CPU that > Diffie-Hellman and the RSA signing takes close to that 0.2 seconds... > -- > kivinen@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From mail@alperaudi.com Mon Dec 15 02:03:38 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26493A68B4 for ; Mon, 15 Dec 2008 02:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -30.18 X-Spam-Level: X-Spam-Status: No, score=-30.18 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZuudFCYUCqY for ; Mon, 15 Dec 2008 02:03:38 -0800 (PST) Received: from allaboutwed.com (unknown [92.112.230.128]) by core3.amsl.com (Postfix) with SMTP id BEC793A68AD for ; Mon, 15 Dec 2008 02:03:37 -0800 (PST) To: Subject: Dear , December 33% off From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081215100337.BEC793A68AD@core3.amsl.com> Date: Mon, 15 Dec 2008 02:03:37 -0800 (PST) Click here to view as a webpage From p7zelapena@afip.gov.ar Mon Dec 15 02:32:05 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43F913A68E3 for ; Mon, 15 Dec 2008 02:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_ALMOST_IP=5.417, FH_HOST_ALMOST_IP=1.889, HELO_DYNAMIC_HCC=4.295, HELO_EQ_DSL=1.129, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AffeoTSpsAwX for ; Mon, 15 Dec 2008 02:32:05 -0800 (PST) Received: from BSN-95-245-223.dsl.siol.net (BSN-95-245-223.dsl.siol.net [193.95.245.223]) by core3.amsl.com (Postfix) with SMTP id 9BFE13A68C6 for ; Mon, 15 Dec 2008 02:32:02 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081215103203.9BFE13A68C6@core3.amsl.com> Date: Mon, 15 Dec 2008 02:32:02 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From msouza@abril.com.br Mon Dec 15 04:32:05 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA2C3A6994 for ; Mon, 15 Dec 2008 04:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.813 X-Spam-Level: X-Spam-Status: No, score=-11.813 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBGcIfv2cxRI for ; Mon, 15 Dec 2008 04:32:05 -0800 (PST) Received: from 4help.net (unknown [212.86.250.35]) by core3.amsl.com (Postfix) with SMTP id EA9413A69DF for ; Mon, 15 Dec 2008 04:31:50 -0800 (PST) To: Subject: , December 31% off From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081215123154.EA9413A69DF@core3.amsl.com> Date: Mon, 15 Dec 2008 04:31:50 -0800 (PST) Click here to view as a webpage From ipsec-bounces@ietf.org Mon Dec 15 05:41: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 C3CDF3A69EF; Mon, 15 Dec 2008 05:41:04 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9A83A69DF for ; Mon, 15 Dec 2008 05:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 1h2LdGwEWBQE for ; Mon, 15 Dec 2008 05:41:02 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 679823A69F2 for ; Mon, 15 Dec 2008 05:41:01 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBFDeccJ004601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 15:40:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBFDeacN005422; Mon, 15 Dec 2008 15:40:36 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18758.24148.531600.593865@fireball.kivinen.iki.fi> Date: Mon, 15 Dec 2008 15:40:36 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <682B1483-DDBE-4B90-AB17-6D734F6031C4@checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017C@il-ex01.ad.checkpoint.com> <8ADA5BBD-2BC8-4997-91EB-2BB584963EB4@checkpoint.com> <18750.28308.704.651625@fireball.kivinen.iki.fi> <682B1483-DDBE-4B90-AB17-6D734F6031C4@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: IPsecme WG Subject: Re: [IPsec] #30: Conflicts in DH proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > how about, ", and should match the DH group is the most preferred > group in the most preferred proposal, if such exists" - lower case > should? That would be fine. In that case we could even use capital "SHOULD", as I think the requirement of selecting most preferred group / proposal is ok. I just do not want to have word "strongest" there as that would be indicate we have some global strength order we could sort them. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 15 05:58: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 205EA3A6A09; Mon, 15 Dec 2008 05:58:38 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BEDA3A6A09 for ; Mon, 15 Dec 2008 05:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ddm6t2zMQsA2 for ; Mon, 15 Dec 2008 05:58:36 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 461453A69DF for ; Mon, 15 Dec 2008 05:58:35 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBFDwMc8008349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2008 15:58:22 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBFDwL68006888; Mon, 15 Dec 2008 15:58:21 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18758.25213.782363.148253@fireball.kivinen.iki.fi> Date: Mon, 15 Dec 2008 15:58:21 +0200 From: Tero Kivinen To: "fan zhao" In-Reply-To: References: <18743.55776.990379.921448@fireball.kivinen.iki.fi> <18745.4766.35985.750878@fireball.kivinen.iki.fi> <18749.21666.801967.227066@fireball.kivinen.iki.fi> <18752.63094.766199.617640@fireball.kivinen.iki.fi> <18754.29639.787080.201046@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 17 min Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org fan zhao writes: > >> > Reordering does not need to cause any delay, as > >> > implementation can handle that internally and it can simply put the > >> > out of order packet on hold until IKE_AUTH is processed and then > >> > continue processing the other packet. > >> I understand this can be done to reduce the delay. However, this is > >> probably not a standard behavior per RCF 4306 as it just mentions that after > >> an IKE_SA is set up, an IKE end point can send multiple requests > >> if the SET_WINDOW_SIZE is received from its peer. > > > > We are not talking about multiple requests, we are talking about one > > request that arrives before the IKE_AUTH is processed. > This is exactly my point. It is not clearly specified in the RFC that > reordering of the last IKE_AUTH and sequent requests need to > be handled. I disagree with you in that. The current RFC 4306 section 1 says: ... In all cases, all IKE_SA_INIT exchanges MUST complete before any other exchange type, then all IKE_AUTH exchanges MUST complete, and following that any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur in any order. For me that clearly says that such case must be handled, it is not left unspecified. The CREATE_CHILD_SA or INFORMATIONAL exchance MUST NOT be processed before the IKE_AUTH is processed. Whether that is done by dropping out of order CREATE_CHILD_SA or INFORMATIONAL exchange packets or whether is done by holding them, and processing IKE_AUTH first and then those packets on hold is implementation detail, that does not affect interoperablity. So the specification is quite clear that this case needs to be handled. It does not propose a way how to handle it, but lets that to be implementation detail as regardless how the implementation handles it does not affect interoperability. > > > If your > > environment is so delay critical that delay of 500 ms is unacceptable > > for it when those specific two packets happen to arrive out of order, > > then you should implement code to get rid of it. > I do not know exact reasons why the RFC does not specify how to > handle the reordered AUTH message and the requests. Anyway, if it is > not required by the RFC, then some (RFC-compliant) implementation > may not support that. That is fine. Reordering is not specified or required, as it does not affect interoperability. Regardless what the other end does two peers can still interoperate fine. We do not specify all small details for all possible cases, quite a lot of things which do not affect interoperability are left as in implementation details. > Does RFC 4306 talk about storing the reordered request before processing > last AUTH message? Maybe I miss something. No, but it does say that all IKE_AUTH exchange MUST be finished, before any other exchanges are allowed to be processed. > Yes, there are many factors affecting handover delay and there are various > optimization solutions. For example, the IP configuration can be done > proactively based on the fast handover for MIPv6 protocol. While it is possible > that even with all kinds of optimizations, the handover delay is still larger > than 0.2 second, the point here I am trying to make is that we should > not make the > (already unacceptable) delay become even worse. Even though the delay caused > by packet loss/reordering is of the same order of magnitude or smaller > than other > kind of delay, I would like to argue that it is still beneficial to > avoid adding such delay. You are NOT talking about the delay that happens all the time, you are talking about the delay that MIGHT happen if packets happens to get reordered. This is not usually that common situation and if it is going to be common situation in your network, then it is better to get such implementation which is specifically optimized for such environment, and knows that packets get reordered by network most of the time and has some specific implementation optimization that make it work efficently even in such environments. I think we have come very far from the original question whether we should allow 3 different ways of doing the REDIRECT or only 2. I say 2 is enough, and I do not want to add one more complication to the IKE_AUTH even when it would be 0.2 seconds faster in environments where IKE_AUTH reply and first INFORMATIONAL request from server are always reordered and the implementation used in the client end, in such wierd environment are not optimized for such wierd environment. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nawaratd@ais.co.th Mon Dec 15 08:52:11 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8023B3A68C9 for ; Mon, 15 Dec 2008 08:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.218 X-Spam-Level: X-Spam-Status: No, score=-13.218 tagged_above=-999 required=5 tests=[AWL=-8.750, BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvLiD1bUiYLE for ; Mon, 15 Dec 2008 08:52:11 -0800 (PST) Received: from 201-25-236-125.bnut3702.dsl.brasiltelecom.net.br (201-25-236-125.bnut3702.dsl.brasiltelecom.net.br [201.25.236.125]) by core3.amsl.com (Postfix) with SMTP id 8373D3A67F0 for ; Mon, 15 Dec 2008 08:52:07 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081215165208.8373D3A67F0@core3.amsl.com> Date: Mon, 15 Dec 2008 08:52:07 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From my008lqh@263.net Mon Dec 15 10:30:44 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A33C128C104 for ; Mon, 15 Dec 2008 10:30:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.162 X-Spam-Level: X-Spam-Status: No, score=0.162 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HELO_EQ_DSL=1.129, HELO_EQ_TELESP=1.245, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, SARE_RECV_SPAM_DOMN02=1.666, TVD_RCVD_IP=1.931, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fb9iG5TAg2bO for ; Mon, 15 Dec 2008 10:30:44 -0800 (PST) Received: from 200-158-18-210.dsl.telesp.net.br (200-158-18-210.dsl.telesp.net.br [200.158.18.210]) by core3.amsl.com (Postfix) with SMTP id 6411B3A6804 for ; Mon, 15 Dec 2008 10:30:42 -0800 (PST) To: Subject: Re: Order status From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081215183043.6411B3A6804@core3.amsl.com> Date: Mon, 15 Dec 2008 10:30:42 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Mon Dec 15 15:29: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 388653A691E; Mon, 15 Dec 2008 15:29:45 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D743A691E for ; Mon, 15 Dec 2008 15:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 GW+-MeHAcBba for ; Mon, 15 Dec 2008 15:29:43 -0800 (PST) Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com [209.85.221.11]) by core3.amsl.com (Postfix) with ESMTP id B28BD3A68B4 for ; Mon, 15 Dec 2008 15:29:42 -0800 (PST) Received: by qyk4 with SMTP id 4so2906325qyk.13 for ; Mon, 15 Dec 2008 15:29:35 -0800 (PST) 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=J2z7D8Z+jUZbX03baSwSdDdlR+03ebRtz1PLjb1Vdxc=; b=s5Yf3SoR3ejDiLYTU1EUYyjuyg1DaZr3Mih3ilUolCvHDG1GRbxXtl74oXm2d70O50 5AmmJYT4//oBcumJvdLzb7pe2zsDmKsUp+IHxOqbDi80Lj7deES6can4/gzNYcFOmP6s 9YFNkOCN+G+SVK2yzCvFxAZf7BeHfLxUDDhgg= 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=beUUHYd03Tz/ESR5GsJAsLsA2Q/rPG8MVa6cVU/YQH59+4N9QYUXegyvkg4kKcSQF1 H+Iau+e997zZbnnyZ5XRwF8heB1HBZRJTMe8AGyMPPIM+Zv8emQ7H5Shn5PNNCXCt0JL SzDTkByjKnYOTfCDOVItgJpC/Ds7xTPvXCflA= Received: by 10.214.148.5 with SMTP id v5mr8518678qad.312.1229383775544; Mon, 15 Dec 2008 15:29:35 -0800 (PST) Received: by 10.215.14.1 with HTTP; Mon, 15 Dec 2008 15:29:35 -0800 (PST) Message-ID: Date: Mon, 15 Dec 2008 15:29:35 -0800 From: "fan zhao" To: "Tero Kivinen" In-Reply-To: <18758.25213.782363.148253@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <18745.4766.35985.750878@fireball.kivinen.iki.fi> <18749.21666.801967.227066@fireball.kivinen.iki.fi> <18752.63094.766199.617640@fireball.kivinen.iki.fi> <18754.29639.787080.201046@fireball.kivinen.iki.fi> <18758.25213.782363.148253@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, Please see below. On Mon, Dec 15, 2008 at 5:58 AM, Tero Kivinen wrote: > fan zhao writes: >> >> > Reordering does not need to cause any delay, as >> >> > implementation can handle that internally and it can simply put the >> >> > out of order packet on hold until IKE_AUTH is processed and then >> >> > continue processing the other packet. >> >> I understand this can be done to reduce the delay. However, this is >> >> probably not a standard behavior per RCF 4306 as it just mentions that after >> >> an IKE_SA is set up, an IKE end point can send multiple requests >> >> if the SET_WINDOW_SIZE is received from its peer. >> > >> > We are not talking about multiple requests, we are talking about one >> > request that arrives before the IKE_AUTH is processed. >> This is exactly my point. It is not clearly specified in the RFC that >> reordering of the last IKE_AUTH and sequent requests need to >> be handled. > > I disagree with you in that. The current RFC 4306 section 1 says: > > ... In all cases, > all IKE_SA_INIT exchanges MUST complete before any other exchange > type, then all IKE_AUTH exchanges MUST complete, and following that > any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur > in any order. > > For me that clearly says that such case must be handled, it is not > left unspecified. The CREATE_CHILD_SA or INFORMATIONAL exchance MUST > NOT be processed before the IKE_AUTH is processed. Whether that is > done by dropping out of order CREATE_CHILD_SA or INFORMATIONAL > exchange packets or whether is done by holding them, and processing > IKE_AUTH first and then those packets on hold is implementation > detail, Yes, that is what I meant. > that does not affect interoperablity. > > So the specification is quite clear that this case needs to be > handled. It does not propose a way how to handle it, but lets that to > be implementation detail as regardless how the implementation handles > it does not affect interoperability. Fine with me. I think my point was made clear: some implementation may simply drop reordered requests and some implementaion may store them; both are compliant to the IKE spec. > >> >> > If your >> > environment is so delay critical that delay of 500 ms is unacceptable >> > for it when those specific two packets happen to arrive out of order, >> > then you should implement code to get rid of it. >> I do not know exact reasons why the RFC does not specify how to >> handle the reordered AUTH message and the requests. Anyway, if it is >> not required by the RFC, then some (RFC-compliant) implementation >> may not support that. > > That is fine. Reordering is not specified or required, as it does not > affect interoperability. Regardless what the other end does two peers > can still interoperate fine. We do not specify all small details for > all possible cases, quite a lot of things which do not affect > interoperability are left as in implementation details. Ok, though I am wondering if the client saves the requests before finishing processing the IKE_AUTH, does it open a window for the Denial-of-service attack? Because the eavesdroppers can flood the client with a lot of bogus requests, which consumes a lot of memory at the client since the client does not know whether they are from attackers or the server. Though the client can control how many requests can be stored, it seems to me that this introduces something additional to the implementation. > >> Does RFC 4306 talk about storing the reordered request before processing >> last AUTH message? Maybe I miss something. > > No, but it does say that all IKE_AUTH exchange MUST be finished, > before any other exchanges are allowed to be processed. > >> Yes, there are many factors affecting handover delay and there are various >> optimization solutions. For example, the IP configuration can be done >> proactively based on the fast handover for MIPv6 protocol. While it is possible >> that even with all kinds of optimizations, the handover delay is still larger >> than 0.2 second, the point here I am trying to make is that we should >> not make the >> (already unacceptable) delay become even worse. Even though the delay caused >> by packet loss/reordering is of the same order of magnitude or smaller >> than other >> kind of delay, I would like to argue that it is still beneficial to >> avoid adding such delay. > > You are NOT talking about the delay that happens all the time, you are > talking about the delay that MIGHT happen if packets happens to get > reordered. Yes, What I considered also includes the delay introduced when the N(REDIRECT) is dropped. > This is not usually that common situation and if it is > going to be common situation in your network, then it is better to get > such implementation which is specifically optimized for such > environment, and knows that packets get reordered by network most of > the time and has some specific implementation optimization that make > it work efficently even in such environments. It is very difficult to predict/model packet loss and reordering. Even though there are some implementaion optimization, the best way is to reduce the probability of loss/reordering. > > I think we have come very far from the original question whether we > should allow 3 different ways of doing the REDIRECT or only 2. I say 2 > is enough, and I do not want to add one more complication to the > IKE_AUTH even when it would be 0.2 seconds faster in environments > where IKE_AUTH reply and first INFORMATIONAL request from server are > always reordered and the implementation used in the client end, in > such wierd environment are not optimized for such wierd environment. Let us wrap up the discussion. Below is the summary, please feel free to add your oponions or correct it. N(Redirect) during IKE_AUTH Pros: 1) less overhead, including payloads sent over the wired/wireless link and cpu cycles/memory for additional packet processing 2) faster: no need to wait for another one way latency, i.e. transferring the N(Redirect) from the server to the client (this delay can be smaller e.g. if sending the N(Redirect) immediately after the IKE_AUTH) 3) reduce the probability of packet loss and reordering Cons: Increase complexity of implementaion, for example, more tests Fan: it is an implementation issue and can be addressed. I do not see such complexity can justify the sacrifice in performance. Thanks for discussion. Sincerely, fan > -- > kivinen@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From koehler@activemeta.net Mon Dec 15 17:54:07 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88E1D3A67AE for ; Mon, 15 Dec 2008 17:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -43.398 X-Spam-Level: X-Spam-Status: No, score=-43.398 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e38a+TxInjC for ; Mon, 15 Dec 2008 17:54:07 -0800 (PST) Received: from 124-171-136-217.dyn.iinet.net.au (124-171-136-217.dyn.iinet.net.au [124.171.136.217]) by core3.amsl.com (Postfix) with SMTP id A1F2D3A67E4 for ; Mon, 15 Dec 2008 17:54:02 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081216015405.A1F2D3A67E4@core3.amsl.com> Date: Mon, 15 Dec 2008 17:54:02 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Tue Dec 16 00:22: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 3D4753A6808; Tue, 16 Dec 2008 00:22:07 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC5323A6808 for ; Tue, 16 Dec 2008 00:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.012, 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 vkcEWb3CwYD3 for ; Tue, 16 Dec 2008 00:22:04 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 095C33A6358 for ; Tue, 16 Dec 2008 00:22:04 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 3DBE729C003; Tue, 16 Dec 2008 10:21:56 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4F04429C001; Tue, 16 Dec 2008 10:21:55 +0200 (IST) X-CheckPoint: {494763F2-10000-88241DC2-7B6} Received: from xpsp2-legit.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBG8LtfE006795; Tue, 16 Dec 2008 10:21:55 +0200 (IST) Message-Id: <7B78230D-4C3B-4846-859E-27ACC1E1B89B@checkpoint.com> From: Yoav Nir To: Patricia In-Reply-To: <64a9a4a70812112339i765d9812t194db001b6ec310b@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 16 Dec 2008 10:21:54 +0200 References: <64a9a4a70812112316p1ee69589k297b77721f4a488b@mail.gmail.com> <64a9a4a70812112331m25dd60b7w201f8beef4cc7952@mail.gmail.com> <64a9a4a70812112339i765d9812t194db001b6ec310b@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2 CP with CREATE-CHILD-SA exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Dec 12, 2008, at 9:39 AM, Patricia wrote: > Hi, > When I was reading RFC4306 & 4718, I had one puzzle on IKEv2 CP. > According to RFC4306 2.19, > "A request for such a temporary address can be included in any > request to create a CHILD_SA (including the implicit request in > message 3) by including a CP payload." > But I'm a little confused about how it is used with CREATE-CHILD-SA > exchange and what it is used for. Does it mean that the IRAS is > going to assign a different IP for each of CREATE-CHILD-SA exchange? > If so, since there is no EAP at this stage, the IP can be got only > from local pool but not from external server. Is it such case? > > Thanks, > Patricia Hi Patricia. I'm a little confused myself. The text you quoted is also present in the IKEv2bis document ( http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-01.txt ) It is somewhat misleading, as it implies just what you are saying, that the IRAS might assign a different IP for each IPsec SA. Even if this is permitted by the standard (more on in a few lines) this is not the way CP works. The usual way of doing things is to only assign one IP address during the IKE_AUTH exchange. That address persists at least until the deletion of the IKE SA (although if the SA is rekeyed or reauthenticated, the new IKE SA gets the old address) No implementation that I know of assigns an address at any other time. It actually makes no sense to assign several IP addresses like that, as IKEv2 does not have real address management features - there is no way to release the IP address other than tearing down the IKE SA. If you go to section 3.15 of RFC 4306, you'll see that the configuration payload can pass an attribute called INTERNAL_ADDRESS_EXPIRY. The theory was that you would pass that number to the client (probably the lifetime you got from the DHCP server) and the client would in a timely manner, ask the gateway to renew the address, and extend the DHCP lease. This may be the reason why CP payloads would be needed in CCSA and Informational exchanges. That option was deprecated in the bis document, so may be that CP-in- CCSA should be deprecated as well. If you are implementing IKEv2 client-side, you should probably not request an additional IP address in a CCSA exchange, only the IKE_AUTH exchange. If you are writing a server-side, you can probably safely ignore a CP payload in CCSA. Hope this helps Yoav Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 16 05:42:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D484A3A6910; Tue, 16 Dec 2008 05:42:17 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 709C93A6910 for ; Tue, 16 Dec 2008 05:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 F-hRvo+GlujT for ; Tue, 16 Dec 2008 05:42:15 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B64D53A63CB for ; Tue, 16 Dec 2008 05:42:12 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBGDfu1o020987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Dec 2008 15:41:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBGDftUm015966; Tue, 16 Dec 2008 15:41:55 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18759.45090.953053.62293@fireball.kivinen.iki.fi> Date: Tue, 16 Dec 2008 15:41:54 +0200 From: Tero Kivinen To: "fan zhao" In-Reply-To: References: <18745.4766.35985.750878@fireball.kivinen.iki.fi> <18749.21666.801967.227066@fireball.kivinen.iki.fi> <18752.63094.766199.617640@fireball.kivinen.iki.fi> <18754.29639.787080.201046@fireball.kivinen.iki.fi> <18758.25213.782363.148253@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 24 min X-Total-Time: 85 min Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org fan zhao writes: > Ok, though I am wondering if the client saves the requests before finishi= ng > processing the IKE_AUTH, does it open a window for the > Denial-of-service attack? Not really. The window size is usually still at one 1 at that point (provided there is even other implementations than ours that support bigger windows), so the responder needs to only keep one incoming message for optimized behavior. If the initiator has already announced bigger window size, it might keep as many request as it announced for its window size. I myself would only implemet at max of one packet holdout buffer there if I would need to really cope environments where reordering is such big problem that I really need to optimize for it, as that one packet buffer would be enough for the normal optimized case. > Because the eavesdroppers can flood the client with a lot of bogus reques= ts, > which consumes a lot of memory at the client since the client does not > know whether they are from attackers or the server. Though the client > can control how many requests can be stored, it seems to me that this > introduces something additional to the implementation. As complient implementation of the other end cannot send more than window size of requests to other end, then it is best to simply limit the buffer to that many packets. You need that kind of buffer anyways for IKEv2, as the current specification says that you MUST keep old packets forever for all packets that are still in the window, so this will NOT add any new memory resources to be used. > N(Redirect) during IKE_AUTH > Pros: > 1) less overhead, including payloads sent over the wired/wireless link and > cpu cycles/memory for additional packet processing And we are talking about 2 * 100 bytes (1600 =B5s at 1 MBit/s wireless link) of overhead here including about 2 * 40 bytes of symmetric encrypt/decrypt (2 * 1.1 =B5s (encrypt) + 2 * 1.6 =B5s (decrypt) for aes-128) and 2 * 90 bytes of MACed content (2 * 8 =B5s for hmac-sha1-96) so the total overhead is 21.4 =B5s for crypto and 1600 =B5s for 1Mbit/s wireless link. To be safe we can say the overhead is less than 2 ms... > 2) faster: no need to wait for another one way latency, i.e. transferring= the > N(Redirect) from the server to the client (this delay can be smaller > e.g. if sending the N(Redirect) immediately after the IKE_AUTH) There is no extra delay except for actual transmission time of that 100 byte long packet. There is no need to wait any one way latency or round trip times. = > 3) reduce the probability of packet loss and reordering > Cons: > Increase complexity of implementaion, for example, more tests > Fan: it is an implementation issue and can be addressed. I > do not see such complexity can justify the sacrifice in performance. As I do not really see any pros, and there is very large cons (complexity), I myself are clearly on the side of less complexity i.e lets not add yet another mode to the IKE with no real benefits. -- = kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 16 08:55: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 860A828C138; Tue, 16 Dec 2008 08:55:07 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BE0828C138 for ; Tue, 16 Dec 2008 08:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 aHcWXZDbs2jy for ; Tue, 16 Dec 2008 08:55:04 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 3A16F28C133 for ; Tue, 16 Dec 2008 08:55:03 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7F09229C002; Tue, 16 Dec 2008 18:54:55 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 851FD29C001; Tue, 16 Dec 2008 18:54:54 +0200 (IST) X-CheckPoint: {4947DC2A-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBGGsrfE027996; Tue, 16 Dec 2008 18:54:54 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 16 Dec 2008 18:54:53 +0200 From: Yaron Sheffer To: Yoav Nir Date: Tue, 16 Dec 2008 18:54:36 +0200 Thread-Topic: [IPsec] IKEv2 CP with CREATE-CHILD-SA exchange Thread-Index: AclfV2FzBvC0D3+VRpSL6siwaScAwwAR0ilg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D948F@il-ex01.ad.checkpoint.com> References: <64a9a4a70812112316p1ee69589k297b77721f4a488b@mail.gmail.com> <64a9a4a70812112331m25dd60b7w201f8beef4cc7952@mail.gmail.com> <64a9a4a70812112339i765d9812t194db001b6ec310b@mail.gmail.com> <7B78230D-4C3B-4846-859E-27ACC1E1B89B@checkpoint.com> In-Reply-To: <7B78230D-4C3B-4846-859E-27ACC1E1B89B@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Patricia Subject: Re: [IPsec] IKEv2 CP with CREATE-CHILD-SA exchange 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="===============1229664374==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1229664374== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0194_01C95FAF.BDA25DE0" ------=_NextPart_000_0194_01C95FAF.BDA25DE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Yoav, Please open an issue to cover this case. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Yoav Nir > Sent: Tuesday, December 16, 2008 10:22 > To: Patricia > Cc: ipsec@ietf.org > Subject: Re: [IPsec] IKEv2 CP with CREATE-CHILD-SA exchange > > On Dec 12, 2008, at 9:39 AM, Patricia wrote: > > > Hi, > > When I was reading RFC4306 & 4718, I had one puzzle on IKEv2 CP. > > According to RFC4306 2.19, > > "A request for such a temporary address can be included in any > > request to create a CHILD_SA (including the implicit request in > > message 3) by including a CP payload." > > But I'm a little confused about how it is used with CREATE-CHILD-SA > > exchange and what it is used for. Does it mean that the IRAS is > > going to assign a different IP for each of CREATE-CHILD-SA exchange? > > If so, since there is no EAP at this stage, the IP can be got only > > from local pool but not from external server. Is it such case? > > > > Thanks, > > Patricia > > Hi Patricia. > > I'm a little confused myself. The text you quoted is also present in > the IKEv2bis document ( http://www.ietf.org/internet-drafts/draft-ietf- > ipsecme-ikev2bis-01.txt > ) > > It is somewhat misleading, as it implies just what you are saying, > that the IRAS might assign a different IP for each IPsec SA. Even if > this is permitted by the standard (more on in a few lines) this is not > the way CP works. > > The usual way of doing things is to only assign one IP address during > the IKE_AUTH exchange. That address persists at least until the > deletion of the IKE SA (although if the SA is rekeyed or > reauthenticated, the new IKE SA gets the old address) > > No implementation that I know of assigns an address at any other > time. It actually makes no sense to assign several IP addresses like > that, as IKEv2 does not have real address management features - there > is no way to release the IP address other than tearing down the IKE SA. > > If you go to section 3.15 of RFC 4306, you'll see that the > configuration payload can pass an attribute called > INTERNAL_ADDRESS_EXPIRY. The theory was that you would pass that > number to the client (probably the lifetime you got from the DHCP > server) and the client would in a timely manner, ask the gateway to > renew the address, and extend the DHCP lease. This may be the reason > why CP payloads would be needed in CCSA and Informational exchanges. > That option was deprecated in the bis document, so may be that CP-in- > CCSA should be deprecated as well. > > If you are implementing IKEv2 client-side, you should probably not > request an additional IP address in a CCSA exchange, only the IKE_AUTH > exchange. If you are writing a server-side, you can probably safely > ignore a CP payload in CCSA. > > Hope this helps > > Yoav > > > > Email secured by Check Point > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0194_01C95FAF.BDA25DE0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIxNjE2NTQzNlowIwYJKoZIhvcNAQkEMRYEFDElz/4y293P Btc8b5bh0f7r3s/BMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA frdBxzvJpioFlhr1NwQx+ULeTbPeXWvSqX6Fsxy/LZZupE8juNM4N548uCmlAeFbiDm6eoSl+umy udNKIa4axlAlTqxjLg/5j71oRpAEwq2qkgx+JHpQCk7zyss547k+mDpzvRWw8n9GE+x605vcexMp Gx27Jwk9FB11s6wek7TgayJN1+FAze2fQ4BcfyXOZe+rnrmMraqqkNiavXHWPK7zlwFXKdgfzIbh RMfKzoNNI8Wi1UUgpZ0iI9ppeNkyyqSkAFZF/W19zC/ekeosXP6bsRCWERYsFVF0U3NxxbHDLIm1 WicMvC/wO9Wb9M2VxuokLB1JqTD0kSXkVUbqiAAAAAAAAA== ------=_NextPart_000_0194_01C95FAF.BDA25DE0-- --===============1229664374== 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 --===============1229664374==-- From nzuela@aegeanair.com Tue Dec 16 12:01:53 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A798E3A69C4 for ; Tue, 16 Dec 2008 12:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.168 X-Spam-Level: *** X-Spam-Status: No, score=3.168 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DSL=1.129, HOST_EQ_STATICB=1.372, HTML_FONT_LOW_CONTRAST=0.124, HTML_IMAGE_ONLY_08=1.787, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAVJ94ANSS0a for ; Tue, 16 Dec 2008 12:01:53 -0800 (PST) Received: from static-adsl201-232-99-17.epm.net.co (static-adsl201-232-99-17.epm.net.co [201.232.99.17]) by core3.amsl.com (Postfix) with SMTP id 453C628C177 for ; Tue, 16 Dec 2008 12:01:08 -0800 (PST) To: Subject: Your order From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081216200111.453C628C177@core3.amsl.com> Date: Tue, 16 Dec 2008 12:01:08 -0800 (PST)
Check it now!

Cherry-pick the most appropriate item for you!


University, who took part in the study found aToronto.
is able to control its own security.Carter said, "The lahar travelled down the path as From ipsec-bounces@ietf.org Tue Dec 16 12:09: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 247543A6870; Tue, 16 Dec 2008 12:09:47 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204A63A6800 for ; Tue, 16 Dec 2008 12:09:46 -0800 (PST) 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 Q4QfLJWXfECE for ; Tue, 16 Dec 2008 12:09:45 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id CDB593A677E for ; Tue, 16 Dec 2008 12:09:44 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so768516qwe.31 for ; Tue, 16 Dec 2008 12:09:36 -0800 (PST) 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=QeKhD+V+NsQbSg9n8sXuDVFQ015ScJcB25Li3niTLCg=; b=LOaFxIh5VvGrEyiKN6A9rwf9yfrm+RdNRu6g/agaE/4ZvBgN6Fr6h6pJLr4Px+Dx7V csQZTQUgCp+1zdHCc8Z+l7cezqiZVXF7VXwurzPZDW6PEbs8yXaN8RtSsNauP3qurVxj zIwsYi6irduZxGiEMepT1A5cpNsejd0Lzc/Tc= 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=leGhrNwQjCCzqGeI2ZDBzgZWRZgReL7LPBOFA0+RSpxwxdFquH4PrPcOlQ+6WXHYZO 4o8knC3bknKYYNhV328ZBGq448fOc6un5x4P3DI54+ITYuWdzHoDwhY0tGAnK4ZYx561 2SE6G+J2KV4PMPiZEGaoPsZIHy1LHyIRSXOno= Received: by 10.214.243.18 with SMTP id q18mr9943470qah.362.1229458176339; Tue, 16 Dec 2008 12:09:36 -0800 (PST) Received: by 10.215.14.1 with HTTP; Tue, 16 Dec 2008 12:09:36 -0800 (PST) Message-ID: Date: Tue, 16 Dec 2008 12:09:36 -0800 From: "fan zhao" To: "Tero Kivinen" In-Reply-To: <18759.45090.953053.62293@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <18749.21666.801967.227066@fireball.kivinen.iki.fi> <18752.63094.766199.617640@fireball.kivinen.iki.fi> <18754.29639.787080.201046@fireball.kivinen.iki.fi> <18758.25213.782363.148253@fireball.kivinen.iki.fi> <18759.45090.953053.62293@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Vijay Devarapalli Subject: Re: [IPsec] Redirect during IKE_AUTH stage (was Re: Revised IKEv2 Re-direct draft) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, Please see below. On Tue, Dec 16, 2008 at 5:41 AM, Tero Kivinen wrote: > fan zhao writes: >> Ok, though I am wondering if the client saves the requests before finish= ing >> processing the IKE_AUTH, does it open a window for the >> Denial-of-service attack? > > Not really. The window size is usually still at one 1 at that point > (provided there is even other implementations than ours that support > bigger windows), so the responder needs to only keep one incoming > message for optimized behavior. If the initiator has already announced > bigger window size, it might keep as many request as it announced for > its window size. > > I myself would only implemet at max of one packet holdout buffer there > if I would need to really cope environments where reordering is such > big problem that I really need to optimize for it, as that one packet > buffer would be enough for the normal optimized case. Yes, that is what I meant by saying "control how many requests can be store= d". > >> Because the eavesdroppers can flood the client with a lot of bogus reque= sts, >> which consumes a lot of memory at the client since the client does not >> know whether they are from attackers or the server. Though the client >> can control how many requests can be stored, it seems to me that this >> introduces something additional to the implementation. > > As complient implementation of the other end cannot send more than > window size of requests to other end, then it is best to simply limit > the buffer to that many packets. You need that kind of buffer anyways > for IKEv2, as the current specification says that you MUST keep old > packets forever for all packets that are still in the window, so this > will NOT add any new memory resources to be used. I think we have discussed this: what is explicitly specified in the RFC is for sebsequent requests. > >> N(Redirect) during IKE_AUTH >> Pros: >> 1) less overhead, including payloads sent over the wired/wireless link a= nd >> cpu cycles/memory for additional packet processing > > And we are talking about 2 * 100 bytes (1600 =B5s at 1 MBit/s wireless > link) of overhead here including about 2 * 40 bytes of symmetric > encrypt/decrypt (2 * 1.1 =B5s (encrypt) + 2 * 1.6 =B5s (decrypt) for > aes-128) and 2 * 90 bytes of MACed content (2 * 8 =B5s for hmac-sha1-96) > so the total overhead is 21.4 =B5s for crypto and 1600 =B5s for 1Mbit/s > wireless link. To be safe we can say the overhead is less than 2 ms... The time needed for crypt operations also depends on hardware. > >> 2) faster: no need to wait for another one way latency, i.e. transferrin= g the >> N(Redirect) from the server to the client (this delay can be smaller >> e.g. if sending the N(Redirect) immediately after the IKE_AUTH) > > There is no extra delay except for actual transmission time of that > 100 byte long packet. There is no need to wait any one way latency or > round trip times. Yes, the delay is the actual transmission time of that 100 bytes long packe= t. I am saying it is a delay because if N(REDIRECT) is included in the IKE_AUTH message, there is no additional transmission time needed. > >> 3) reduce the probability of packet loss and reordering > >> Cons: >> Increase complexity of implementaion, for example, more tests >> Fan: it is an implementation issue and can be addressed. I >> do not see such complexity can justify the sacrifice in performance. > > As I do not really see any pros, and there is very large cons > (complexity), I myself are clearly on the side of less complexity i.e > lets not add yet another mode to the IKE with no real benefits. Can you please quantify the complexity so that we can do a head-to-head comparison? As you said before, such complexity could be due to additional checking for bugs? It will be good if you can estimate time comsumption for executing testing code under the same benchmark. If these bugs are hard to predict/find, please let me know why they cannot be found and how adding N(REDIRECT) to the IKE_AUTH message causes that? Sincerely, fan > -- > kivinen@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 16 12:58: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 41C893A698D; Tue, 16 Dec 2008 12:58:18 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F5C43A6868 for ; Tue, 16 Dec 2008 12:58:17 -0800 (PST) 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 c5lTGT6otmTY for ; Tue, 16 Dec 2008 12:58:12 -0800 (PST) Received: from WA4EHSOBE001.bigfish.com (outbound-wa4.frontbridge.com [216.32.181.16]) by core3.amsl.com (Postfix) with ESMTP id 05E5E3A6856 for ; Tue, 16 Dec 2008 12:58:11 -0800 (PST) Received: from mail114-wa4-R.bigfish.com (10.8.14.251) by WA4EHSOBE001.bigfish.com (10.8.40.21) with Microsoft SMTP Server id 8.1.291.1; Tue, 16 Dec 2008 20:58:03 +0000 Received: from mail114-wa4 (localhost.localdomain [127.0.0.1]) by mail114-wa4-R.bigfish.com (Postfix) with ESMTP id 5F50E46833A for ; Tue, 16 Dec 2008 20:58:03 +0000 (UTC) X-BigFish: VS-14(zz146fK4015Me2eR19c2k8c8aizzzzz2dh6bh61h) X-Spam-TCS-SCL: 0:0 X-FB-SS: 5,5, Received: by mail114-wa4 (MessageSwitch) id 122946108136364_5613; Tue, 16 Dec 2008 20:58:01 +0000 (UCT) Received: from sjcxch07b.hifn.com (h-68-165-169-146.snvacaid.covad.net [68.165.169.146]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail114-wa4.bigfish.com (Postfix) with ESMTP id C581CE90064 for ; Tue, 16 Dec 2008 20:58:00 +0000 (UTC) Received: from SJCXCH07.hifn.com (172.27.1.110) by sjcxch07b.hifn.com (100.10.1.218) with Microsoft SMTP Server (TLS) id 8.1.311.2; Tue, 16 Dec 2008 12:58:00 -0800 Received: from SJCXCH07.hifn.com ([172.27.1.110]) by SJCXCH07.hifn.com ([172.27.1.110]) with mapi; Tue, 16 Dec 2008 12:58:00 -0800 From: Jimmy Zhang To: IPsecme WG Date: Tue, 16 Dec 2008 12:57:55 -0800 Thread-Topic: regarding USE_TRANSPORT_MODE and IPCOMP_SUPPORTED notifications Thread-Index: AclYaS9SN7JH4XMtSd+uqtsXc4vFJAHUBfow Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017B@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017B@il-ex01.ad.checkpoint.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: [IPsec] regarding USE_TRANSPORT_MODE and IPCOMP_SUPPORTED notifications 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="===============0626684666==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0626684666== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_E1BEC7FFF6C889489E8C09F722F185CD17D19866ACSJCXCH07hifnc_" --_000_E1BEC7FFF6C889489E8C09F722F185CD17D19866ACSJCXCH07hifnc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, All, When USE_TRANSPORT_MODE notification is received along with the SA payload,= current spec reads, If the responder declines the request, the Child SA will be established in tunnel mode. If this is unacceptable to the initiator, the initiator MUST delete the SA." IPCOMP_SUPPORTED notification is similar to USE_TRANSPORT_MODE, they both a= re actually part of the proposal but are sent in notification payload. Howe= ver, the RFC and IKEv2bis don't cover what if the responder doesn't accept = any of the proposed compression algorithms. The current spec reads, --The response MAY indicate acceptance of a single compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. --A message accepting an SA may contain at most one (compression algorithm). --Implementations of this specification MUST NOT accept an IPComp algorithm that was not proposed, MUST NOT accept more than one, and MUST NOT compress using an algorithm other than one proposed and accepted in the setup of the Child SA". But what if absolutely no algorithm is acceptable? The first response is ma= ybe to add something similar to USE_TRANSPORT_MODE for consistency reason, If the responder declines all the requested compression algorithms, the Child SA will be established without compression. If this is unacceptable to the initiator, the initiator MUST delete the SA. This will cause another and maybe bigger problem, what if the initiator pro= poses algorithm A, but the responder only supports and requires algorithm B= in its policy? In this case, what the responder really wants is a NO_PROPO= SAL_CHOSEN response, not something against its own policy (its own policy r= equires algorithm B, not NONE). Thus I think we do need some clarification on whether it is legible to send= back NO_PROPOSAL_CHOSEN just because of the content in Notification payloa= d (instead of Proposal payload)? I think it legible. Responder has its own = decision to reply with NO_PROPOSAL_CHOSEN to unwanted USE_TRANSPORT_MODE or= IPCOMP_SUPPORTED notifications. We don't prevent responder to do that in = current spec anyway, but a clarification will surely help, especially to th= e above mentioned IPCOMP_SUPPORTED response when no algorithm is acceptable= . Thanks, Jimmy Zhang ________________________________ This email message is for the sole use of the intended recipient(s) and may= contain confidential and privileged information which is protected from di= sclosure. Any unauthorized review, use, disclosure or distribution by any m= eans is prohibited. If you are not the intended recipient, please contact t= he sender by reply email or at (408) 399-3500 and destroy all copies of the= original message. --_000_E1BEC7FFF6C889489E8C09F722F185CD17D19866ACSJCXCH07hifnc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, All,

 

When USE_TRANSPORT_MODE notification is received along with the SA payload= , current spec reads,

   If the responde= r declines the request, the Child SA will be

   established in = tunnel mode.  If this is unacceptable to the

   initiator, the = initiator MUST delete the SA.”

 

IPCOMP_SUPPORTED notification is s= imilar to USE_TRANSPORT_MODE, they both are actually part of the proposal b= ut are sent in notification payload. However, the RFC and IKEv2bis don̵= 7;t cover what if the responder doesn’t accept any of the proposed compression algorithms. The current spec reads, <= /o:p>

   --The response = MAY indicate acceptance of a single compression

   algorithm with = a Notify payload of type IPCOMP_SUPPORTED.

   --A message acc= epting an SA may contain at most one (compression

   algorithm).&nbs= p;

   --Implementatio= ns of this specification MUST NOT accept an

   IPComp algorith= m that was not proposed, MUST NOT accept more

   than one, and M= UST NOT compress using an algorithm other than

   one proposed an= d  accepted in the setup of the Child SA”.  

 

But what if absolutely no algorithm is acceptable? T= he first response is maybe to add something similar to USE_TRANSPORT_MODE f= or consistency reason,

   If the responde= r declines all the requested compression

   algorithms, the= Child SA will be established without

   compression. If= this is unacceptable to the initiator,

   the initiator M= UST delete the SA.

 

This will cause another and maybe bigger problem, wh= at if the initiator proposes algorithm A, but the responder only supports a= nd requires algorithm B in its policy? In this case, what the responder rea= lly wants is a NO_PROPOSAL_CHOSEN response, not something against its own policy (its own policy requires al= gorithm B, not NONE).

 

Thus I think we do need some clarification on whethe= r it is legible to send back NO_PROPOSAL_CHOSEN just because of the content= in Notification payload (instead of Proposal payload)? I think it legible.= Responder has its own decision to reply with NO_PROPOSAL_CHOSEN to unwanted USE_TRANSPORT_MODE or IPCOMP_SUP= PORTED notifications.  We don’t prevent responder to do that in = current spec anyway, but a clarification will surely help, especially to th= e above mentioned IPCOMP_SUPPORTED response when no algorithm is acceptable.

 

Thanks,

Jimmy Zhang


This email message is for = the sole use of the intended recipient(s) and may contain confidential and = privileged information which is protected from disclosure. Any unauthorized= review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please = contact the sender by reply email or at (408) 399-3500 and destroy all copi= es of the original message.
 --_000_E1BEC7FFF6C889489E8C09F722F185CD17D19866ACSJCXCH07hifnc_-- --===============0626684666== 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 --===============0626684666==-- From larry.dellacorte@affiniagroup.com Tue Dec 16 14:49:31 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F56628C13E for ; Tue, 16 Dec 2008 14:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -54.831 X-Spam-Level: X-Spam-Status: No, score=-54.831 tagged_above=-999 required=5 tests=[BAYES_60=1, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_BLACK=20, URIBL_JP_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTyu5xrAc8wd for ; Tue, 16 Dec 2008 14:49:25 -0800 (PST) Received: from aglending.com (unknown [189.81.158.214]) by core3.amsl.com (Postfix) with SMTP id AD73328C116 for ; Tue, 16 Dec 2008 14:49:22 -0800 (PST) To: Subject: Delivery Status Notification (Failure) From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081216224923.AD73328C116@core3.amsl.com> Date: Tue, 16 Dec 2008 14:49:22 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Tue Dec 16 14:54:10 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 419B528C156; Tue, 16 Dec 2008 14:54:10 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70E603A6992 for ; Tue, 16 Dec 2008 14:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.011, 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 I8UiSecITNiQ for ; Tue, 16 Dec 2008 14:54:08 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1DBD73A68E0 for ; Tue, 16 Dec 2008 14:54:07 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id D85D029C003; Wed, 17 Dec 2008 00:53:59 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6A8B429C001; Wed, 17 Dec 2008 00:52:18 +0200 (IST) X-CheckPoint: {49482FEC-10000-88241DC2-7B6} Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id mBGMqIfF013131; Wed, 17 Dec 2008 00:52:18 +0200 (IST) Message-Id: <40C9D2D1-592D-4681-9017-F8B81B3C7C91@checkpoint.com> From: Yoav Nir To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D948F@il-ex01.ad.checkpoint.com> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 00:52:12 +0200 References: <64a9a4a70812112316p1ee69589k297b77721f4a488b@mail.gmail.com> <64a9a4a70812112331m25dd60b7w201f8beef4cc7952@mail.gmail.com> <64a9a4a70812112339i765d9812t194db001b6ec310b@mail.gmail.com> <7B78230D-4C3B-4846-859E-27ACC1E1B89B@checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D948F@il-ex01.ad.checkpoint.com> X-Mailer: Apple Mail (2.930.3) Cc: "ipsec@ietf.org" , Patricia Subject: Re: [IPsec] IKEv2 CP with CREATE-CHILD-SA exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org OK. #79 On Dec 16, 2008, at 6:54 PM, Yaron Sheffer wrote: > Hi Yoav, > > Please open an issue to cover this case. > > Thanks, > Yaron > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On >> Behalf Of >> Yoav Nir >> Sent: Tuesday, December 16, 2008 10:22 >> To: Patricia >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] IKEv2 CP with CREATE-CHILD-SA exchange >> >> On Dec 12, 2008, at 9:39 AM, Patricia wrote: >> >>> Hi, >>> When I was reading RFC4306 & 4718, I had one puzzle on IKEv2 CP. >>> According to RFC4306 2.19, >>> "A request for such a temporary address can be included in any >>> request to create a CHILD_SA (including the implicit request in >>> message 3) by including a CP payload." >>> But I'm a little confused about how it is used with CREATE-CHILD-SA >>> exchange and what it is used for. Does it mean that the IRAS is >>> going to assign a different IP for each of CREATE-CHILD-SA exchange? >>> If so, since there is no EAP at this stage, the IP can be got only >>> from local pool but not from external server. Is it such case? >>> >>> Thanks, >>> Patricia >> >> Hi Patricia. >> >> I'm a little confused myself. The text you quoted is also present in >> the IKEv2bis document ( http://www.ietf.org/internet-drafts/draft-ietf- >> ipsecme-ikev2bis-01.txt >> ) >> >> It is somewhat misleading, as it implies just what you are saying, >> that the IRAS might assign a different IP for each IPsec SA. Even if >> this is permitted by the standard (more on in a few lines) this is >> not >> the way CP works. >> >> The usual way of doing things is to only assign one IP address during >> the IKE_AUTH exchange. That address persists at least until the >> deletion of the IKE SA (although if the SA is rekeyed or >> reauthenticated, the new IKE SA gets the old address) >> >> No implementation that I know of assigns an address at any other >> time. It actually makes no sense to assign several IP addresses like >> that, as IKEv2 does not have real address management features - there >> is no way to release the IP address other than tearing down the IKE >> SA. >> >> If you go to section 3.15 of RFC 4306, you'll see that the >> configuration payload can pass an attribute called >> INTERNAL_ADDRESS_EXPIRY. The theory was that you would pass that >> number to the client (probably the lifetime you got from the DHCP >> server) and the client would in a timely manner, ask the gateway to >> renew the address, and extend the DHCP lease. This may be the reason >> why CP payloads would be needed in CCSA and Informational exchanges. >> That option was deprecated in the bis document, so may be that CP-in- >> CCSA should be deprecated as well. >> >> If you are implementing IKEv2 client-side, you should probably not >> request an additional IP address in a CCSA exchange, only the >> IKE_AUTH >> exchange. If you are writing a server-side, you can probably safely >> ignore a CP payload in CCSA. >> >> Hope this helps >> >> Yoav >> >> >> >> Email secured by Check Point >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. > > > Scanned by Check Point Total Security Gateway. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 16 16:20: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 34FCC3A6866; Tue, 16 Dec 2008 16:20:00 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA3E53A6866 for ; Tue, 16 Dec 2008 16:19:58 -0800 (PST) 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 kQx4DRhmTGu1 for ; Tue, 16 Dec 2008 16:19:58 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.174]) by core3.amsl.com (Postfix) with ESMTP id 147063A6818 for ; Tue, 16 Dec 2008 16:19:57 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so3437831wfd.31 for ; Tue, 16 Dec 2008 16:19:49 -0800 (PST) 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=Wo1RlKvCNAoC0GorDdoPh2hTXXeqah9tJmRI1h5GHp0=; b=Duj8E18oxG8nEmJcYFnhljFIfXAsgnV/n2Z6EF4FPtp49wkqaMUHlisR97cZmhcqwy WlEPKbjnwsQazO3sMjCv+Fe0Azbyy2MS9akRFTCvpkrjMmHFJJdDB5pDaZAeNQUrHEYz 1EsPYBLs/jIyihB2gobnzUN2OEAmF/ko/qaoc= 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=eA6mAirvoxUbv0tfXTSSSNJwtGN/N2Wg5e4UADsAfJgyCtHe/a0XQMXp2YAvpN84SB D5SOUEsnXMPLnMUCWLkCklasrTKdl0V84ItnDP5QNJKk6Z0x1n7uDRUlpHiq97GnOhFv y5SAWmvBYAbt0zI9+8/H+TieENwE55oNXT53I= Received: by 10.142.166.1 with SMTP id o1mr13663wfe.337.1229473189615; Tue, 16 Dec 2008 16:19:49 -0800 (PST) Received: by 10.142.234.19 with HTTP; Tue, 16 Dec 2008 16:19:49 -0800 (PST) Message-ID: Date: Tue, 16 Dec 2008 16:19:49 -0800 From: "Vijay Devarapalli" To: "Tero Kivinen" MIME-Version: 1.0 Content-Disposition: inline Cc: ipsec@ietf.org Subject: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, Changing the object since I want to discuss the proposal you had. On Wed, Dec 3, 2008 at 4:51 AM, Tero Kivinen wrote: > Note, > that server can reject the IPsec SA creation by returning suitable > error message (for example NO_ADDITIONAL_SAS) in the IKE_AUTH, and > then the full exchange would be: > > > Initiator Responder > ------------------------------------------------------------------- > HDR, SAi1, KEi, Ni, > N(REDIRECT_SUPPORTED) --> > > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > > HDR, SK {IDi, [CERT,] [CERTREQ,] > [IDr,] AUTH, SAi2, > TSi, TSr} --> > > > <-- HDR, SK {IDr, [CERT,] AUTH, > N(NO_ADDITIONAL_SAS)} > <-- HDR, SK {N(REDIRECT)} > > > HDR, SK {N(REDIRECT_ACK)} --> > HDR, SAi1, KEi, Ni, > N(REDIRECT_FROM) --> > > I.e. the server would reply N(NO_ADDITIONAL_SAS) and immediately after > that send N(REDIRECT) notify as separate INFORMATINAL exchange. The > initiator would first get the IKE_AUTH reply, process that, and > immediately after that get INFORMATINAL exhange asking to N(REDIRECT). RFC 4306 seems to say that the NO_ADDITIONAL_SAS payload is used to reject an CREATE_CHILD_SA request. Its not clear to me if it can be used to reject an IKE_AUTH request. NO_ADDITIONAL_SAS 35 This error indicates that a CREATE_CHILD_SA request is unacceptable because the responder is unwilling to accept any more CHILD_SAs on this IKE_SA. Some minimal implementations may only accept a single CHILD_SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more. Yaron and I had a discussion on this offline. We can either explicitly allow the use of NO_ADDITIONAL_SAS to reject an IKE_AUTH request in IKEv2bis or use NO_PROPOSAL_CHOSEN payload to reject the IKE_AUTH request. Neither is ideal of course. Another option is to just allow the IKE_AUTH exchange to complete as normal and then re-direct the client. Vijay _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 16 23:42:55 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 534303A6AF4; Tue, 16 Dec 2008 23:42:55 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B2A83A6AF4 for ; Tue, 16 Dec 2008 23:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8J7mBUE4tq4B for ; Tue, 16 Dec 2008 23:42:53 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 12F9E3A68AC for ; Tue, 16 Dec 2008 23:42:52 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EA71E29C002; Wed, 17 Dec 2008 09:42:44 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 1C80C29C001; Wed, 17 Dec 2008 09:42:13 +0200 (IST) X-CheckPoint: {4948AC1B-10000-88241DC2-7B6} Received: from [91.90.139.202] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBH7gCfE029869; Wed, 17 Dec 2008 09:42:12 +0200 (IST) Message-Id: <351F8D50-8DE0-41A7-81CD-ECB0E0E5E8FB@checkpoint.com> From: Yoav Nir To: Vijay Devarapalli In-Reply-To: Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 17 Dec 2008 09:42:11 +0200 References: X-Mailer: Apple Mail (2.930.3) Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Dec 17, 2008, at 2:19 AM, Vijay Devarapalli wrote: > Hi Tero, > > Changing the object since I want to discuss the proposal you had. > > RFC 4306 seems to say that the NO_ADDITIONAL_SAS payload is used to > reject an CREATE_CHILD_SA request. Its not clear to me if it can be > used to reject an IKE_AUTH request. > > NO_ADDITIONAL_SAS 35 > > This error indicates that a CREATE_CHILD_SA request is > unacceptable because the responder is unwilling to accept any > more CHILD_SAs on this IKE_SA. Some minimal implementations > may > only accept a single CHILD_SA setup in the context of an > initial > IKE exchange and reject any subsequent attempts to add more. > > Yaron and I had a discussion on this offline. We can either explicitly > allow the use of NO_ADDITIONAL_SAS to reject an IKE_AUTH request in > IKEv2bis or use NO_PROPOSAL_CHOSEN payload to reject the IKE_AUTH > request. Neither is ideal of course. Another option is to just allow > the IKE_AUTH exchange to complete as normal and then re-direct the > client. > > Vijay or we could use TS_UNACCEPTABLE, because every TS is unacceptable if you need to redirect (although any sane client would delete the IKE SA if it proposed a universal selector and the gateway refused. or we could define a new error type REDIRECT_COMING to fail the child SA :-) or we could just allow the REDIRECT in IKE_AUTH I don't like the idea of letting the exchange complete, because that will lead the client to send IPsec traffic, which we (for some reason) are not willing to process. But if we're set on not allowing REDIRECT in IKE_AUTH, I would go with NO_ADDITIONAL_SAS. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 17 06:50: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 98AFD3A67C1; Wed, 17 Dec 2008 06:50:46 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3879A3A6856 for ; Wed, 17 Dec 2008 06:50:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZFMzn9VnGojn for ; Wed, 17 Dec 2008 06:50:44 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B4EDB3A67A5 for ; Wed, 17 Dec 2008 06:50:43 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBHCP0cK008591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 14:25:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBHCOxBk003631; Wed, 17 Dec 2008 14:24:59 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18760.61339.321730.809284@fireball.kivinen.iki.fi> Date: Wed, 17 Dec 2008 14:24:59 +0200 From: Tero Kivinen To: Jimmy Zhang In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017B@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 18 min Cc: IPsecme WG Subject: [IPsec] regarding USE_TRANSPORT_MODE and IPCOMP_SUPPORTED notifications 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 Jimmy Zhang writes: > IPCOMP_SUPPORTED notification is similar to USE_TRANSPORT_MODE, they > both are actually part of the proposal but are sent in notification > payload. However, the RFC and IKEv2bis don't cover what if the > responder doesn't accept any of the proposed compression algorithms. > The current spec reads, I think it is clear that if responder finds that none of the proposals is acceptable it will send NO_PROPOSAL_CHOSEN error. This does not care where the policy was wrong, it can be encryption algorithms, it can be tunnel vs transport mode (i.e. if initiator didn't offer transport mode and responder REQUIRED transport mode it will send NO_PROPOSAL_CHOSEN back) or whether it was IPcomp algorithms which do not match. The text about the transport mode is when the initiator does not allow the choise responder did, i.e. it does not allow tunnel mode to be selectede by responder because it REQUIRES transport mode. As it cannot send any error messages back at that point anymore, only thing it can do is to delete the IPsec SA. It can do exactly same thing with IPcomp, as this does not require any special signaling there. I.e. if initiator required IPcomp and responder didn't allow IPcomp and didn't respond with IPCOMP_SUPPORTED notify at all (i.e. to indicate it does not support IPcomp), then initiator has now two options 1) Use the IPsec SA without IPcomp 2) Delete the IPsec SA and fail the whole negotiation If the SA without IPcomp is against his policy he will select option 2, and then fail the connection to the responder. > But what if absolutely no algorithm is acceptable? The first > response is maybe to add something similar to USE_TRANSPORT_MODE for > consistency reason, > > If the responder declines all the requested compression > algorithms, the Child SA will be established without > compression. If this is unacceptable to the initiator, > the initiator MUST delete the SA. This is ok to add there, but as initiator is allowed to do that in all cases anyways, I do not really need any reason to add that kind of text. Actually adding such text might make implementations to implement policies which might not be that useful, i.e "MUST do IPcomp". That kind of policy is not really useful, as if the responder supports IPcomp and configured to allow it, the responder will enable IPcomp. If responder does not support IPcomp or is not configured to allow it, then that will just cause the case where two peers cannot communicate. It might make it easier to detect configuration errors as parameters MUST match exactly in both ends, but again makes IPsec configuration more difficult as parameters must match exactly. It would be better to use policies which only set minimum level of requirements and allow negotiation of parameters, than to use policies which set parameters exactly and require them to be exactly same in both ends. > This will cause another and maybe bigger problem, what if the > initiator proposes algorithm A, but the responder only supports and > requires algorithm B in its policy? In this case, what the responder > really wants is a NO_PROPOSAL_CHOSEN response, not something against > its own policy (its own policy requires algorithm B, not NONE). Responder is always allowed to send NO_PROPOSAL_CHOSEN and if it really requires algorithm B it will send NO_PROPOSAL_CHOSEN and no IPsec SA can be created between the peers, until either ends configuration has been changed. > Thus I think we do need some clarification on whether it is legible > to send back NO_PROPOSAL_CHOSEN just because of the content in > Notification payload (instead of Proposal payload)? I think it > legible. As matching offered policy against your own local policy is mostly implementation details, you can send NO_PROPOSAL_CHOSEN whenever the offered proposal does not match your policy. We at least do send that in case the transport mode is required by responder, but initiator didn't offer it. We do not have option to require IPcomp (they are always optional) so IPcomp mismatches do not cause us to send NO_PROPOSAL_CHOSEN. > Responder has its own decision to reply with > NO_PROPOSAL_CHOSEN to unwanted USE_TRANSPORT_MODE or > IPCOMP_SUPPORTED notifications. We don't prevent responder to do > that in current spec anyway, but a clarification will surely help, > especially to the above mentioned IPCOMP_SUPPORTED response when no > algorithm is acceptable. We could add some more text about that, but as it mostly clarifies something that responder can already do anyways, I am not sure if it is really needed (but I am not against adding such text). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 17 06:50: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 0F60A3A68F7; Wed, 17 Dec 2008 06:50:47 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28ADC3A67A5 for ; Wed, 17 Dec 2008 06:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 AXWqYrT-He2c for ; Wed, 17 Dec 2008 06:50:45 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E19B03A67C1 for ; Wed, 17 Dec 2008 06:50:44 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBHCcIVp003759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Dec 2008 14:38:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBHCcITi013816; Wed, 17 Dec 2008 14:38:18 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18760.62138.517458.691565@fireball.kivinen.iki.fi> Date: Wed, 17 Dec 2008 14:38:18 +0200 From: Tero Kivinen To: "Vijay Devarapalli" In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: ipsec@ietf.org Subject: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH 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 Vijay Devarapalli writes: > RFC 4306 seems to say that the NO_ADDITIONAL_SAS payload is used to > reject an CREATE_CHILD_SA request. Its not clear to me if it can be > used to reject an IKE_AUTH request. > > NO_ADDITIONAL_SAS 35 > > This error indicates that a CREATE_CHILD_SA request is > unacceptable because the responder is unwilling to accept any > more CHILD_SAs on this IKE_SA. Some minimal implementations may > only accept a single CHILD_SA setup in the context of an initial > IKE exchange and reject any subsequent attempts to add more. > > Yaron and I had a discussion on this offline. We can either explicitly > allow the use of NO_ADDITIONAL_SAS to reject an IKE_AUTH request in > IKEv2bis or use NO_PROPOSAL_CHOSEN payload to reject the IKE_AUTH > request. Neither is ideal of course. Another option is to just allow > the IKE_AUTH exchange to complete as normal and then re-direct the > client. I have always interpreted that the "CREATE_CHILD_SA request" in the text also includes the imbedded CHILD_SA creation happening during the IKE_AUTH. I for example do assume that you can send SINGLE_PAIR_REQUIRED error message to even to the first child SA created during IKE_AUTH, even when its description says exactly same "This error indicateds that a CREATE_CHILD_SA request is ...". As that SINGLE_PAIR_REQUIRED error is most likely coming back to the autostart type of rules which are created when IKE SA is created, I think the most common case for that error message is actually in the IKE_AUTH... We could fix this by simply removing the "CREATE_CHILD_SA" text from SINGLE_PAIR_REQUIRED and NO_ADDITIONAL_SAS errors. That same text is also in the REKEY_SA, but as there cannot be any rekeyed SAs during IKE_AUTH, that is correct there. NO_PROPOSAL_CHOSEN error is also quite ok, altough NO_ADDITIONAL_SAS would give better feedback to the other end what is going on (and it would also indicate that there is no point of retrying of creating the IPsec SA, as it will fail also). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nitiroogep@amebacctv.com Wed Dec 17 07:48:01 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A941E3A6A9E for ; Wed, 17 Dec 2008 07:48:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -23.329 X-Spam-Level: X-Spam-Status: No, score=-23.329 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxmwgLrRRxWx for ; Wed, 17 Dec 2008 07:47:55 -0800 (PST) Received: from alumni.virginia.edu (unknown [193.37.128.162]) by core3.amsl.com (Postfix) with SMTP id 528503A693A for ; Wed, 17 Dec 2008 07:47:51 -0800 (PST) To: Subject: Delivery Status Notification From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081217154752.528503A693A@core3.amsl.com> Date: Wed, 17 Dec 2008 07:47:51 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Wed Dec 17 11:52:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21B243A6B3A; Wed, 17 Dec 2008 11:52:23 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213233A68AA for ; Wed, 17 Dec 2008 11:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, 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 PmZR2XpLjmQz for ; Wed, 17 Dec 2008 11:52:17 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id AF76E3A6B39 for ; Wed, 17 Dec 2008 11:52:16 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7039329C002; Wed, 17 Dec 2008 21:52:08 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3B37329C001 for ; Wed, 17 Dec 2008 21:52:07 +0200 (IST) X-CheckPoint: {49495729-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBHJq6fE015740 for ; Wed, 17 Dec 2008 21:52:06 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 17 Dec 2008 21:52:06 +0200 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Wed, 17 Dec 2008 21:52:04 +0200 Thread-Topic: ESP-null - the heuristic approach Thread-Index: AclgZtuS4zmIPoW9TJGxiuBHG8GcmA== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D962D@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: [IPsec] ESP-null - the heuristic approach 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="===============1017723611==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1017723611== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0122_01C96091.B2B34FB0" ------=_NextPart_000_0122_01C96091.B2B34FB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0123_01C96091.B2B34FB0" ------=_NextPart_001_0123_01C96091.B2B34FB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, We would like to reach closure on detecting ESP-null packets. There are three options on the table right now: - An explicit wrapper, with a new protocol number (http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-traffic-visibility/) - A more implicit one, using a reserved SPI (http://tools.ietf.org/id/draft-bhatia-ipsecme-esp-null-00.txt) - And using heuristics. But we don't have any documentation of the heuristic approach, other than a few emails. So before we rule out the heuristics option and concentrate on the other two, we'd like to challenge people who believe this is the preferred solution to publish an I-D with enough details to make a fair comparison. If any of you is interested, please reply, either on the list or privately to Paul and myself, and please specify an ETA. Thanks, Yaron ------=_NextPart_001_0123_01C96091.B2B34FB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We would like to reach closure on detecting ESP-null packets. There are three options on the table right = now:

 

-          An = explicit wrapper, with a new protocol number (http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-traffic-visib= ility/)

-          A more = implicit one, using a reserved SPI (ht= tp://tools.ietf.org/id/draft-bhatia-ipsecme-esp-null-00.txt)

-          And = using heuristics.

 

But we don’t have any documentation of the = heuristic approach, other than a few emails.

 

So before we rule out the heuristics option and = concentrate on the other two, we’d like to challenge people who believe this = is the preferred solution to publish an I-D with enough details to make a fair comparison. If any of you is interested, please reply, either on the = list or privately to Paul and myself, and please specify an = ETA.

 

Thanks,

         =    Yaron

------=_NextPart_001_0123_01C96091.B2B34FB0-- ------=_NextPart_000_0122_01C96091.B2B34FB0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIxNzE5NTIwNFowIwYJKoZIhvcNAQkEMRYEFAQlhhjR6gar AGBkn04k2FedfMx5MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA umYQNsaCfPTJHInAcBHeiqkZciZ5cYUqAVHMYwvXBhQxtSTl6MORP0Jb2yjYGHovdCHZLzVvw6ol w07D6KcliCjEFmH/Lt9VuYQacSrutg6F7NmyGUMRhxwctfxTXPizifX7sfc9TH60xNp5DgQOobIV 3CkRcJJDBPliSxKnY66qg1D/O0xcqeIqCuAqBt6/ERWaDqjz3U1BORMfvZ0NOKq1ZTortxzZofOV WJ47E8b+JEU2rV2LtkFtMRWiYZXykx2e4yMTuQ4szcMmDMWegsxcUTX5x33kB8v9gXOylgscgKJL xbRZZamUGi2/OUwYXoqbMv1XO/3oTln+PjRDGQAAAAAAAA== ------=_NextPart_000_0122_01C96091.B2B34FB0-- --===============1017723611== 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 --===============1017723611==-- From ipsec-bounces@ietf.org Wed Dec 17 15:07: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 26AF93A68AB; Wed, 17 Dec 2008 15:07:54 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6EB328C133 for ; Wed, 17 Dec 2008 15:07:52 -0800 (PST) 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=[AWL=0.001, 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 dpLjqP2vBWnY for ; Wed, 17 Dec 2008 15:07:51 -0800 (PST) Received: from WA4EHSOBE005.bigfish.com (outbound-wa4.frontbridge.com [216.32.181.16]) by core3.amsl.com (Postfix) with ESMTP id DD9E73A6768 for ; Wed, 17 Dec 2008 15:07:51 -0800 (PST) Received: from mail35-wa4-R.bigfish.com (10.8.14.238) by WA4EHSOBE005.bigfish.com (10.8.40.25) with Microsoft SMTP Server id 8.1.291.1; Wed, 17 Dec 2008 23:07:44 +0000 Received: from mail35-wa4 (localhost.localdomain [127.0.0.1]) by mail35-wa4-R.bigfish.com (Postfix) with ESMTP id 4809321831E; Wed, 17 Dec 2008 23:07:44 +0000 (UTC) X-BigFish: VS-53(zz146fK542N1432R4015M1805M936fO9371Pe2eR8c8aizzzzz2dh6bh61h) X-Spam-TCS-SCL: 0:0 Received: by mail35-wa4 (MessageSwitch) id 1229555261694212_26537; Wed, 17 Dec 2008 23:07:41 +0000 (UCT) Received: from sjcxch07b.hifn.com (h-68-165-169-146.snvacaid.covad.net [68.165.169.146]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail35-wa4.bigfish.com (Postfix) with ESMTP id 90BD6570053; Wed, 17 Dec 2008 23:07:41 +0000 (UTC) Received: from SJCXCH07.hifn.com (172.27.1.110) by sjcxch07b.hifn.com (100.10.1.218) with Microsoft SMTP Server (TLS) id 8.1.311.2; Wed, 17 Dec 2008 15:07:40 -0800 Received: from SJCXCH07.hifn.com ([172.27.1.110]) by SJCXCH07.hifn.com ([172.27.1.110]) with mapi; Wed, 17 Dec 2008 15:07:41 -0800 From: Jimmy Zhang To: Tero Kivinen Date: Wed, 17 Dec 2008 15:07:36 -0800 Thread-Topic: [IPsec] regarding USE_TRANSPORT_MODE and IPCOMP_SUPPORTED notifications Thread-Index: AclgQoC0vTQfzlzAQjqjdzp5xwFySAAUjZnQ Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017B@il-ex01.ad.checkpoint.com> <18760.61339.321730.809284@fireball.kivinen.iki.fi> In-Reply-To: <18760.61339.321730.809284@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] regarding USE_TRANSPORT_MODE and IPCOMP_SUPPORTED notifications 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 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Wednesday, December 17, 2008 7:25 AM > To: Jimmy Zhang > Cc: IPsecme WG > Subject: [IPsec] regarding USE_TRANSPORT_MODE and IPCOMP_SUPPORTED > notifications > > We at least do send that in case the transport mode is required by > responder, but initiator didn't offer it. We do not have option to > require IPcomp (they are always optional) so IPcomp mismatches do not > cause us to send NO_PROPOSAL_CHOSEN. > This is exactly the area I suggested some clarification. Transport mode and IPcomp negotiation are performed through notification payload in IKEv2, not in SA and Proposal payload. Some implementations (like yours) may treat them as optional parameters because it is a notification anyway, some may still treat them as important as other cryptographic parameters in the Proposal payload, for the latter, they will and they should reply with NO_PROPOSAL_CHOSEN if the mode or IPcomp algorithm doesn't match. IMO, to reply NO_PROPOSEN_CHOSEN against a status notification does need some explicit clarification in order to make it a more formal instead of far-fetched. Current spec only talks about NO_PROPOSAL_CHOSEN in Proposal Payload processing in section 2.7 Thanks, Jimmy This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information which is protected from disclosure. Any unauthorized review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please contact the sender by reply email or at (408) 399-3500 and destroy all copies of the original message. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 18 02:02:55 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9D73A6AB7; Thu, 18 Dec 2008 02:02:55 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0943A6A01 for ; Thu, 18 Dec 2008 02:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8w-pxfYTKXN for ; Thu, 18 Dec 2008 02:02:54 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9704E3A68E4 for ; Thu, 18 Dec 2008 02:02:53 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBIA2Uej012423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 12:02:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBIA2QxE009058; Thu, 18 Dec 2008 12:02:27 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18762.8114.978736.330710@fireball.kivinen.iki.fi> Date: Thu, 18 Dec 2008 12:02:26 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D962D@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D962D@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" Subject: [IPsec] ESP-null - the heuristic approach 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 writes: > - And using heuristics. > > But we don't have any documentation of the heuristic approach, other than a > few emails. > > So before we rule out the heuristics option and concentrate on the other > two, we'd like to challenge people who believe this is the preferred > solution to publish an I-D with enough details to make a fair comparison. If > any of you is interested, please reply, either on the list or privately to > Paul and myself, and please specify an ETA. I have still that item in my todo list, but I have been so busy that I haven't been able to continue the work I did several months ago since. I will try to get something done for this during the first week of January, but if someone else can write it even better... -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 18 02:19: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 78DB13A689F; Thu, 18 Dec 2008 02:19:38 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 578E43A6835 for ; Thu, 18 Dec 2008 02:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 m6TYmNimz9bz for ; Thu, 18 Dec 2008 02:19:36 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2735B3A6767 for ; Thu, 18 Dec 2008 02:19:35 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBIAJNmt015023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Dec 2008 12:19:23 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBIAJNTO007038; Thu, 18 Dec 2008 12:19:23 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18762.9131.220691.272267@fireball.kivinen.iki.fi> Date: Thu, 18 Dec 2008 12:19:23 +0200 From: Tero Kivinen To: Jimmy Zhang In-Reply-To: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017B@il-ex01.ad.checkpoint.com> <18760.61339.321730.809284@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min Cc: IPsecme WG Subject: Re: [IPsec] regarding USE_TRANSPORT_MODE and IPCOMP_SUPPORTED notifications 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 Jimmy Zhang writes: > > We at least do send that in case the transport mode is required by > > responder, but initiator didn't offer it. We do not have option to > > require IPcomp (they are always optional) so IPcomp mismatches do not > > cause us to send NO_PROPOSAL_CHOSEN. > > > > This is exactly the area I suggested some clarification. Transport > mode and IPcomp negotiation are performed through notification > payload in IKEv2, not in SA and Proposal payload. Some > implementations (like yours) may treat them as optional parameters > because it is a notification anyway, some may still treat them as > important as other cryptographic parameters in the Proposal payload, > for the latter, they will and they should reply with > NO_PROPOSAL_CHOSEN if the mode or IPcomp algorithm doesn't match. > IMO, to reply NO_PROPOSEN_CHOSEN against a status notification does > need some explicit clarification in order to make it a more formal > instead of far-fetched. Current spec only talks about > NO_PROPOSAL_CHOSEN in Proposal Payload processing in section 2.7 Current RFC talks about NO_PROPOSAL_CHOSEN in the 3.10.1 Notify message types and only says it is returned when "None of the proposed crypto suites was acceptable.". Now the question is the IPcomp and Tunnel/Transport mode part of your crypto suites. The section 1 defines terms "suite" or "cryptographic suite" as "complete set of algorithms used to protect an SA.", and I think tunnel/transport mode and even IPcomp are part of the set of algorithms used to protect an SA. So using RFC4306 I think it is quiet clear that you MAY send NO_PROPOSAL_CHOSEN even in those cases. The ikev2bis draft moved the NO_PROPOSAL_CHOSEN to the section 2.7 which I think didn't clarify the issue, but made it unclear whether NO_PROPOSAL_CHOSEN can be used for tunnel/transport mode mismatch and/or IPcomp algorithm mismatch. On the other hand it only says that you use NO_PROPOSAL_CHOSEN if you cannot select suitable proposal, it does NOT say you cannot use NO_PROPOSAL_CHOSEN in other cases. For example section 2.8.1. already uses NO_PROPOSAL_CHOSEN in case simultaneous child SA exchange to signal "generic" non-fatal error for create child sa creation. I think the ikev2bis needs to clarify this, as it was clearer in the RFC4306, but new version is not so clear anymore. I would put some more text back to the 3.10.1 NO_PROPOSAL_CHOSEN and say: ---------------------------------------------------------------------- NO_PROPOSAL_CHOSEN 14 None of the proposed crypto suites was acceptable. This can be sent in any case where the offered proposal (including but not limited to SA payload values, USE_TRANSPORT_MODE notify, IPCOMP_SUPPORTED notify) are not acceptable for the responder. This can also be as "generic" Child SA error when Child SA cannot be created for some other reason. See also Section 2.7. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 18 07:13: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 DC68B28C0EE; Thu, 18 Dec 2008 07:13:01 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4F128C0EE for ; Thu, 18 Dec 2008 07:13:00 -0800 (PST) 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=[AWL=0.000, 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 9xsSl-ex8Kqu for ; Thu, 18 Dec 2008 07:12:59 -0800 (PST) Received: from WA4EHSOBE004.bigfish.com (outbound-wa4.frontbridge.com [216.32.181.16]) by core3.amsl.com (Postfix) with ESMTP id 98C4528C0ED for ; Thu, 18 Dec 2008 07:12:59 -0800 (PST) Received: from mail187-wa4-R.bigfish.com (10.8.14.252) by WA4EHSOBE004.bigfish.com (10.8.40.24) with Microsoft SMTP Server id 8.1.291.1; Thu, 18 Dec 2008 15:12:51 +0000 Received: from mail187-wa4 (localhost.localdomain [127.0.0.1]) by mail187-wa4-R.bigfish.com (Postfix) with ESMTP id 87A6F19B813F; Thu, 18 Dec 2008 15:12:50 +0000 (UTC) X-BigFish: VS-54(zz146fK542N1432R936eQ1805M936fO9371Pe2eR19c2k8c8aizzzzz2dh6bh61h) X-Spam-TCS-SCL: 0:0 Received: by mail187-wa4 (MessageSwitch) id 1229613164913281_23360; Thu, 18 Dec 2008 15:12:44 +0000 (UCT) Received: from sjcxch07b.hifn.com (h-68-165-169-146.snvacaid.covad.net [68.165.169.146]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail187-wa4.bigfish.com (Postfix) with ESMTP id 34F8D10880CF; Thu, 18 Dec 2008 15:12:38 +0000 (UTC) Received: from SJCXCH07.hifn.com (172.27.1.110) by sjcxch07b.hifn.com (100.10.1.218) with Microsoft SMTP Server (TLS) id 8.1.311.2; Thu, 18 Dec 2008 07:12:37 -0800 Received: from SJCXCH07.hifn.com ([172.27.1.110]) by SJCXCH07.hifn.com ([172.27.1.110]) with mapi; Thu, 18 Dec 2008 07:12:37 -0800 From: Jimmy Zhang To: Tero Kivinen Date: Thu, 18 Dec 2008 07:12:32 -0800 Thread-Topic: [IPsec] regarding USE_TRANSPORT_MODE and IPCOMP_SUPPORTED notifications Thread-Index: Aclg+h3O2Ewow4dBQ2uH8fULFVkLLgAKBZqQ Message-ID: References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB95017B@il-ex01.ad.checkpoint.com> <18760.61339.321730.809284@fireball.kivinen.iki.fi> <18762.9131.220691.272267@fireball.kivinen.iki.fi> In-Reply-To: <18762.9131.220691.272267@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] regarding USE_TRANSPORT_MODE and IPCOMP_SUPPORTED notifications 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 and I like your words to IKEv2bis. Jimmy > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Thursday, December 18, 2008 5:19 AM > To: Jimmy Zhang > Cc: IPsecme WG > Subject: RE: [IPsec] regarding USE_TRANSPORT_MODE and IPCOMP_SUPPORTED > notifications > > Jimmy Zhang writes: > > > We at least do send that in case the transport mode is required by > > > responder, but initiator didn't offer it. We do not have option to > > > require IPcomp (they are always optional) so IPcomp mismatches do > not > > > cause us to send NO_PROPOSAL_CHOSEN. > > > > > > > This is exactly the area I suggested some clarification. Transport > > mode and IPcomp negotiation are performed through notification > > payload in IKEv2, not in SA and Proposal payload. Some > > implementations (like yours) may treat them as optional parameters > > because it is a notification anyway, some may still treat them as > > important as other cryptographic parameters in the Proposal payload, > > for the latter, they will and they should reply with > > NO_PROPOSAL_CHOSEN if the mode or IPcomp algorithm doesn't match. > > IMO, to reply NO_PROPOSEN_CHOSEN against a status notification does > > need some explicit clarification in order to make it a more formal > > instead of far-fetched. Current spec only talks about > > NO_PROPOSAL_CHOSEN in Proposal Payload processing in section 2.7 > > Current RFC talks about NO_PROPOSAL_CHOSEN in the 3.10.1 Notify > message types and only says it is returned when "None of the proposed > crypto suites was acceptable.". > > Now the question is the IPcomp and Tunnel/Transport mode part of your > crypto suites. The section 1 defines terms "suite" or "cryptographic > suite" as "complete set of algorithms used to protect an SA.", and I > think tunnel/transport mode and even IPcomp are part of the set of > algorithms used to protect an SA. > > So using RFC4306 I think it is quiet clear that you MAY send > NO_PROPOSAL_CHOSEN even in those cases. > > The ikev2bis draft moved the NO_PROPOSAL_CHOSEN to the section 2.7 > which I think didn't clarify the issue, but made it unclear whether > NO_PROPOSAL_CHOSEN can be used for tunnel/transport mode mismatch > and/or IPcomp algorithm mismatch. On the other hand it only says that > you use NO_PROPOSAL_CHOSEN if you cannot select suitable proposal, it > does NOT say you cannot use NO_PROPOSAL_CHOSEN in other cases. > > For example section 2.8.1. already uses NO_PROPOSAL_CHOSEN in case > simultaneous child SA exchange to signal "generic" non-fatal error for > create child sa creation. > > I think the ikev2bis needs to clarify this, as it was clearer in the > RFC4306, but new version is not so clear anymore. > > I would put some more text back to the 3.10.1 NO_PROPOSAL_CHOSEN and > say: > > ---------------------------------------------------------------------- > NO_PROPOSAL_CHOSEN 14 > > None of the proposed crypto suites was acceptable. This can be > sent in any case where the offered proposal (including but not > limited to SA payload values, USE_TRANSPORT_MODE notify, > IPCOMP_SUPPORTED notify) are not acceptable for the responder. > This can also be as "generic" Child SA error when Child SA > cannot be created for some other reason. > See also Section 2.7. > -- > kivinen@iki.fi This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information which is protected from disclosure. Any unauthorized review, use, disclosure or distribution by any means is prohibited. If you are not the intended recipient, please contact the sender by reply email or at (408) 399-3500 and destroy all copies of the original message. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 18 07:53: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 8DE233A68C0; Thu, 18 Dec 2008 07:53:52 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAD033A692C for ; Thu, 18 Dec 2008 07:53:51 -0800 (PST) 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 powv4tO1288g for ; Thu, 18 Dec 2008 07:53:51 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id BD7333A6768 for ; Thu, 18 Dec 2008 07:53:50 -0800 (PST) Received: from [165.227.249.204] (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 mBIFreaV080150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 Dec 2008 08:53:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <18762.8114.978736.330710@fireball.kivinen.iki.fi> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D962D@il-ex01.ad.checkpoint.com> <18762.8114.978736.330710@fireball.kivinen.iki.fi> Date: Thu, 18 Dec 2008 07:53:40 -0800 To: ipsec@ietf.org From: Paul Hoffman Subject: Re: [IPsec] ESP-null - the heuristic approach X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 12:02 PM +0200 12/18/08, Tero Kivinen wrote: >I will try to get something done for this during the first week of >January, but if someone else can write it even better... Anyone who believes that the heuristic approach is the best one should volunteer to Tero to help. Heuristics is different than a protocol; it would probably be good to have many contributors/writers on such a document. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 18 17:01: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 B9C883A68A2; Thu, 18 Dec 2008 17:01:45 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 810423A68A2 for ; Thu, 18 Dec 2008 17:01:44 -0800 (PST) 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 pxeMw-F-q+57 for ; Thu, 18 Dec 2008 17:01:43 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id A041F3A6829 for ; Thu, 18 Dec 2008 17:01:43 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 27so810159wfd.31 for ; Thu, 18 Dec 2008 17:01:35 -0800 (PST) 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=ESZ+WRKLTPphaKAT7xPnppWLKytRgGlwi41/y1e5jwQ=; b=XxFy51XuS7AA1skECdKdeMNsov2sanOBUhOEKLNRWpjyG+d1XovEGyXS+9AthsS2XR rnmsJ0Wc1jVP4k9/+UNaDVArHHL67bL3QbBD0mEg5YUHC/u3PPL4sfmHqbxAG1ui0fkW 7P/BOuxNWwuK45b8p/0/wUx7hKLciA/qaBI7g= 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=SXNoOtPatejnXTZ2PCoaIv+OlAaI3KDyEtdAwwQx1WVC3jzO5aIISUj4t7Sfet0QcE YkQsUcYWcE+CVxyfUeN14Z+LcYMDMiRCGTHlrthMtC+Te+N8SNQmuyPfJIIlIXFY8LOV 2tMcIw1zxMZJx2FMf5JbqISViKB+bXbmL9Ny4= Received: by 10.142.139.18 with SMTP id m18mr1057944wfd.239.1229648495521; Thu, 18 Dec 2008 17:01:35 -0800 (PST) Received: by 10.142.234.19 with HTTP; Thu, 18 Dec 2008 17:01:35 -0800 (PST) Message-ID: Date: Thu, 18 Dec 2008 17:01:35 -0800 From: "Vijay Devarapalli" To: "Tero Kivinen" , ynir@checkpoint.com In-Reply-To: <18760.62138.517458.691565@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero, Yoav, I don't have a problem using NO_ADDITIONAL_SAS in the IKE_AUTH response followed by the re-direct message. However, I think we need a clarification in IKEv2bis draft. It would be very easy for someone to interpret that the NO_ADDITIONAL_SAS payload can only be used to reject a CREATE_CHILD_SA request and not the IKE_AUTH request (because thats what the text in RFC 4306 says.) and implement accordingly. Vijay On Wed, Dec 17, 2008 at 4:38 AM, Tero Kivinen wrote: > Vijay Devarapalli writes: >> RFC 4306 seems to say that the NO_ADDITIONAL_SAS payload is used to >> reject an CREATE_CHILD_SA request. Its not clear to me if it can be >> used to reject an IKE_AUTH request. >> >> NO_ADDITIONAL_SAS 35 >> >> This error indicates that a CREATE_CHILD_SA request is >> unacceptable because the responder is unwilling to accept any >> more CHILD_SAs on this IKE_SA. Some minimal implementations may >> only accept a single CHILD_SA setup in the context of an initial >> IKE exchange and reject any subsequent attempts to add more. >> >> Yaron and I had a discussion on this offline. We can either explicitly >> allow the use of NO_ADDITIONAL_SAS to reject an IKE_AUTH request in >> IKEv2bis or use NO_PROPOSAL_CHOSEN payload to reject the IKE_AUTH >> request. Neither is ideal of course. Another option is to just allow >> the IKE_AUTH exchange to complete as normal and then re-direct the >> client. > > I have always interpreted that the "CREATE_CHILD_SA request" in the > text also includes the imbedded CHILD_SA creation happening during the > IKE_AUTH. > > I for example do assume that you can send SINGLE_PAIR_REQUIRED error > message to even to the first child SA created during IKE_AUTH, even > when its description says exactly same "This error indicateds that a > CREATE_CHILD_SA request is ...". > > As that SINGLE_PAIR_REQUIRED error is most likely coming back to the > autostart type of rules which are created when IKE SA is created, I > think the most common case for that error message is actually in the > IKE_AUTH... > > We could fix this by simply removing the "CREATE_CHILD_SA" text from > SINGLE_PAIR_REQUIRED and NO_ADDITIONAL_SAS errors. > > That same text is also in the REKEY_SA, but as there cannot be any > rekeyed SAs during IKE_AUTH, that is correct there. > > NO_PROPOSAL_CHOSEN error is also quite ok, altough NO_ADDITIONAL_SAS > would give better feedback to the other end what is going on (and it > would also indicate that there is no point of retrying of creating the > IPsec SA, as it will fail also). > -- > kivinen@iki.fi > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 18 18:30: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 9B26A3A684D; Thu, 18 Dec 2008 18:30:08 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9A43A684D for ; Thu, 18 Dec 2008 18:30:07 -0800 (PST) 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 r24SW2+3rqET for ; Thu, 18 Dec 2008 18:30:06 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 20E253A67D9 for ; Thu, 18 Dec 2008 18:30:06 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 3so188797qwe.31 for ; Thu, 18 Dec 2008 18:29:57 -0800 (PST) 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=T3Y8ACg8SW+CHQ/ibmX6Fe30SprxfW89Oy3DSfRDOE8=; b=NvnkqcL/CsyepT182LROkeIeohT0v2jTvAVegD62WHDlji+pJ3IseH2SKke+7Hi1U5 XGXMf7v9XLQsbASIYxrExt+6KvJD8TAtiZ7i101m6isJs5HKJVvpdKi7Z193sQSTRkdr zykUTK5iSC38okuiKBGDdqcFNkICxyDFN6bTk= 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=Gq9GgmHMJhcqDmj6trkV9V95iRm8LPhayNyYTEuExy/nF2EKvL0l2dZ1VxRlzRan/L k1Yv1V3SFHYylCCPfRxMyr9EIAbTJ1vzIae5+VbAsx6D9KunGjU+RZTUMYXa0Rj6id/D ETj1p3QQDqhRcJv9wxZJGuv8d6NIELXaasSlg= Received: by 10.214.182.9 with SMTP id e9mr3487127qaf.98.1229653797342; Thu, 18 Dec 2008 18:29:57 -0800 (PST) Received: by 10.215.14.1 with HTTP; Thu, 18 Dec 2008 18:29:57 -0800 (PST) Message-ID: Date: Thu, 18 Dec 2008 18:29:57 -0800 From: "fan zhao" To: "Vijay Devarapalli" In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, ynir@checkpoint.com, Tero Kivinen Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all, Whether to send N(Redirect) during the IKE_AUTH or after the IKE_AUTH, essentially we want to achieve two things: 1) an indication from the server to the client that the normal IKE procedure cannot continue (i.e. not allow the client to do what it intended to accomplish before.) 2) an indication from the server to the client that redirection needs to be performed If including N(Redirect) during the IKE_AUTH, it indicates both 1) and 2) in one message. This seems to me it is a clearer solution, because we do not have to update RFC 4306 or change some exisitng implementations if they interpret the NO_ADDITIONAL_SAS as rejection of a CREATE_CHILD_SA request only. Furthermore, based on my understanding, the NO_ADDITIONAL_SAS does not allow additional Child_SA to be created, but it is not a rejection of IKE_AUTH. Therefore, as soon as the client processes the IKE_AUTH reply with the NO_ADDITIONAL_SAS, it considers the IKE_AUTH procedure is completed, even though it cannot create a child SA, it can send any informational message under this IKE SA until it receives the N(Redirect). When the server receives such informational messages from the client, it is not clear to me whether the server will have to respond to such requests from the client even though it knows that the N(Redirect) is already sent (the chances are that N(Redirect) may be lost or delayed). When the client receives the N(Redirect) while it has some pending requests, it is not clearer to me whether the client will have to wait for the responses from the server or immediately start the redirect procedure. Any clarification would be appreciated. Sincerely, fan On Thu, Dec 18, 2008 at 5:01 PM, Vijay Devarapalli wrote: > Tero, Yoav, > > I don't have a problem using NO_ADDITIONAL_SAS in the IKE_AUTH > response followed by the re-direct message. > > However, I think we need a clarification in IKEv2bis draft. It would > be very easy for someone to interpret that the NO_ADDITIONAL_SAS > payload can only be used to reject a CREATE_CHILD_SA request and not > the IKE_AUTH request (because thats what the text in RFC 4306 says.) > and implement accordingly. > > Vijay > > On Wed, Dec 17, 2008 at 4:38 AM, Tero Kivinen wrote: >> Vijay Devarapalli writes: >>> RFC 4306 seems to say that the NO_ADDITIONAL_SAS payload is used to >>> reject an CREATE_CHILD_SA request. Its not clear to me if it can be >>> used to reject an IKE_AUTH request. >>> >>> NO_ADDITIONAL_SAS 35 >>> >>> This error indicates that a CREATE_CHILD_SA request is >>> unacceptable because the responder is unwilling to accept any >>> more CHILD_SAs on this IKE_SA. Some minimal implementations may >>> only accept a single CHILD_SA setup in the context of an initial >>> IKE exchange and reject any subsequent attempts to add more. >>> >>> Yaron and I had a discussion on this offline. We can either explicitly >>> allow the use of NO_ADDITIONAL_SAS to reject an IKE_AUTH request in >>> IKEv2bis or use NO_PROPOSAL_CHOSEN payload to reject the IKE_AUTH >>> request. Neither is ideal of course. Another option is to just allow >>> the IKE_AUTH exchange to complete as normal and then re-direct the >>> client. >> >> I have always interpreted that the "CREATE_CHILD_SA request" in the >> text also includes the imbedded CHILD_SA creation happening during the >> IKE_AUTH. >> >> I for example do assume that you can send SINGLE_PAIR_REQUIRED error >> message to even to the first child SA created during IKE_AUTH, even >> when its description says exactly same "This error indicateds that a >> CREATE_CHILD_SA request is ...". >> >> As that SINGLE_PAIR_REQUIRED error is most likely coming back to the >> autostart type of rules which are created when IKE SA is created, I >> think the most common case for that error message is actually in the >> IKE_AUTH... >> >> We could fix this by simply removing the "CREATE_CHILD_SA" text from >> SINGLE_PAIR_REQUIRED and NO_ADDITIONAL_SAS errors. >> >> That same text is also in the REKEY_SA, but as there cannot be any >> rekeyed SAs during IKE_AUTH, that is correct there. >> >> NO_PROPOSAL_CHOSEN error is also quite ok, altough NO_ADDITIONAL_SAS >> would give better feedback to the other end what is going on (and it >> would also indicate that there is no point of retrying of creating the >> IPsec SA, as it will fail also). >> -- >> kivinen@iki.fi >> > _______________________________________________ > 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 Dec 18 21:56: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 ED1113A68D8; Thu, 18 Dec 2008 21:56:52 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 985133A68D8 for ; Thu, 18 Dec 2008 21:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cygWQZal8x-C for ; Thu, 18 Dec 2008 21:56:50 -0800 (PST) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 075683A67F3 for ; Thu, 18 Dec 2008 21:56:49 -0800 (PST) Received: by yw-out-2324.google.com with SMTP id 3so291886ywj.49 for ; Thu, 18 Dec 2008 21:56:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=eh0NuG7iJrFMVyK5+10uGtStw9wgAR1Zp/GNNz2kdh0=; b=UhFMExnTKBhsRdoKxaT+HHW36169R/K9wyN7FjeB1xPZmWBDaF2xwOP5GoDSxJZT6F PFu69+asLn80WvglZ7AeP5TVLfPAK1Z1AhoX4RdVeWNytDdDpOcECeWyeFZq6z+ET++M UmkcPI9ME6js4z4IDBIY19UDdyJy3yBuoGsKM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=CXcsvAcp3M18u++mWy7V52FMwzuuU9v/4b6etom0A36xhJCNBUhV1lON+s8RmslYwN BQdBwEt7U9tnXiTPAgBYE47zpTMTV/DbUGYjylyEG2IEeaWNSIl7M8/SDHc5CFAq/6oL SPO7RcCUEZQQcSWhfIQCyLJnUT8q+JpVEb62o= Received: by 10.151.147.16 with SMTP id z16mr2753152ybn.240.1229666200839; Thu, 18 Dec 2008 21:56:40 -0800 (PST) Received: by 10.150.146.12 with HTTP; Thu, 18 Dec 2008 21:56:40 -0800 (PST) Message-ID: <64a9a4a70812182156x26e0b287xc8a6b787fa3239d8@mail.gmail.com> Date: Fri, 19 Dec 2008 13:56:40 +0800 From: Patricia To: "Yoav Nir" In-Reply-To: <40C9D2D1-592D-4681-9017-F8B81B3C7C91@checkpoint.com> MIME-Version: 1.0 References: <64a9a4a70812112316p1ee69589k297b77721f4a488b@mail.gmail.com> <64a9a4a70812112331m25dd60b7w201f8beef4cc7952@mail.gmail.com> <64a9a4a70812112339i765d9812t194db001b6ec310b@mail.gmail.com> <7B78230D-4C3B-4846-859E-27ACC1E1B89B@checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D948F@il-ex01.ad.checkpoint.com> <40C9D2D1-592D-4681-9017-F8B81B3C7C91@checkpoint.com> Cc: "ipsec@ietf.org" Subject: Re: [IPsec] IKEv2 CP with CREATE-CHILD-SA exchange 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="===============0206424878==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0206424878== Content-Type: multipart/alternative; boundary="----=_Part_28867_9943527.1229666200842" ------=_Part_28867_9943527.1229666200842 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Thanks all and I agree with you totally. Patricia 2008/12/17 Yoav Nir > OK. #79 > > > On Dec 16, 2008, at 6:54 PM, Yaron Sheffer wrote: > > Hi Yoav, >> >> Please open an issue to cover this case. >> >> Thanks, >> Yaron >> >> -----Original Message----- >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >>> Of >>> Yoav Nir >>> Sent: Tuesday, December 16, 2008 10:22 >>> To: Patricia >>> Cc: ipsec@ietf.org >>> Subject: Re: [IPsec] IKEv2 CP with CREATE-CHILD-SA exchange >>> >>> On Dec 12, 2008, at 9:39 AM, Patricia wrote: >>> >>> Hi, >>>> When I was reading RFC4306 & 4718, I had one puzzle on IKEv2 CP. >>>> According to RFC4306 2.19, >>>> "A request for such a temporary address can be included in any >>>> request to create a CHILD_SA (including the implicit request in >>>> message 3) by including a CP payload." >>>> But I'm a little confused about how it is used with CREATE-CHILD-SA >>>> exchange and what it is used for. Does it mean that the IRAS is >>>> going to assign a different IP for each of CREATE-CHILD-SA exchange? >>>> If so, since there is no EAP at this stage, the IP can be got only >>>> from local pool but not from external server. Is it such case? >>>> >>>> Thanks, >>>> Patricia >>>> >>> >>> Hi Patricia. >>> >>> I'm a little confused myself. The text you quoted is also present in >>> the IKEv2bis document ( http://www.ietf.org/internet-drafts/draft-ietf- >>> ipsecme-ikev2bis-01.txt >>> ) >>> >>> It is somewhat misleading, as it implies just what you are saying, >>> that the IRAS might assign a different IP for each IPsec SA. Even if >>> this is permitted by the standard (more on in a few lines) this is not >>> the way CP works. >>> >>> The usual way of doing things is to only assign one IP address during >>> the IKE_AUTH exchange. That address persists at least until the >>> deletion of the IKE SA (although if the SA is rekeyed or >>> reauthenticated, the new IKE SA gets the old address) >>> >>> No implementation that I know of assigns an address at any other >>> time. It actually makes no sense to assign several IP addresses like >>> that, as IKEv2 does not have real address management features - there >>> is no way to release the IP address other than tearing down the IKE SA. >>> >>> If you go to section 3.15 of RFC 4306, you'll see that the >>> configuration payload can pass an attribute called >>> INTERNAL_ADDRESS_EXPIRY. The theory was that you would pass that >>> number to the client (probably the lifetime you got from the DHCP >>> server) and the client would in a timely manner, ask the gateway to >>> renew the address, and extend the DHCP lease. This may be the reason >>> why CP payloads would be needed in CCSA and Informational exchanges. >>> That option was deprecated in the bis document, so may be that CP-in- >>> CCSA should be deprecated as well. >>> >>> If you are implementing IKEv2 client-side, you should probably not >>> request an additional IP address in a CCSA exchange, only the IKE_AUTH >>> exchange. If you are writing a server-side, you can probably safely >>> ignore a CP payload in CCSA. >>> >>> Hope this helps >>> >>> Yoav >>> >>> >>> >>> Email secured by Check Point >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> Scanned by Check Point Total Security Gateway. >>> >> >> >> Scanned by Check Point Total Security Gateway. >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > > > Email secured by Check Point > ------=_Part_28867_9943527.1229666200842 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Thanks all and I agree with you totally.
 
Patricia

2008/12/17 Yoav Nir <ynir@checkpoint.com>
OK. #79


On Dec 16, 2008, at 6:54 PM, Yaron Sheffer wrote:

Hi Yoav,

Please open an issue to cover this case.

Thanks,
       Yaron

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of
Yoav Nir
Sent: Tuesday, December 16, 2008 10:22
To: Patricia
Cc: ipsec@ietf.org
Subject: Re: [IPsec] IKEv2 CP with CREATE-CHILD-SA exchange

On Dec 12, 2008, at 9:39 AM, Patricia wrote:

Hi,
When I was reading RFC4306 & 4718, I had one puzzle on IKEv2 CP.
According to RFC4306 2.19,
"A request for such a temporary address can be included in any
request to create a CHILD_SA (including the implicit request in
message 3) by including a CP payload."
But I'm a little confused about how it is used with CREATE-CHILD-SA
exchange and what it is used for. Does it mean that the IRAS is
going to assign a different IP for each of CREATE-CHILD-SA exchange?
If so, since there is no EAP at this stage, the IP can be got only
from local pool but not from external server. Is it such case?

Thanks,
Patricia

Hi Patricia.

I'm a little confused myself. The text you quoted is also present in
the IKEv2bis document ( http://www.ietf.org/internet-drafts/draft-ietf-
ipsecme-ikev2bis-01.txt
 )

It is somewhat misleading, as it implies just what you are saying,
that the IRAS might assign a different IP for each IPsec SA.  Even if
this is permitted by the standard (more on in a few lines) this is not
the way CP works.

The usual way of doing things is to only assign one IP address during
the IKE_AUTH exchange. That address persists at least until the
deletion of the IKE SA (although if the SA is rekeyed or
reauthenticated, the new IKE SA gets the old address)

No implementation that I know of assigns an address at any other
time.  It actually makes no sense to assign several IP addresses like
that, as IKEv2 does not have real address management features - there
is no way to release the IP address other than tearing down the IKE SA.

If you go to section 3.15 of RFC 4306, you'll see that the
configuration payload can pass an attribute called
INTERNAL_ADDRESS_EXPIRY. The theory was that you would pass that
number to the client (probably the lifetime you got from the DHCP
server) and the client would in a timely manner, ask the gateway to
renew the address, and extend the DHCP lease. This may be the reason
why CP payloads would be needed in CCSA and Informational exchanges.
That option was deprecated in the bis document, so may be that CP-in-
CCSA should be deprecated as well.

If you are implementing IKEv2 client-side, you should probably not
request an additional IP address in a CCSA exchange, only the IKE_AUTH
exchange.  If you are writing a server-side, you can probably safely
ignore a CP payload in CCSA.

Hope this helps

Yoav



Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.


Scanned by Check Point Total Security Gateway.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



Email secured by Check Point

------=_Part_28867_9943527.1229666200842-- --===============0206424878== 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 --===============0206424878==-- From ipsec-bounces@ietf.org Fri Dec 19 02:04: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 062AF3A6986; Fri, 19 Dec 2008 02:04:01 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6804C3A6986 for ; Fri, 19 Dec 2008 02:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYWERMOaTQIG for ; Fri, 19 Dec 2008 02:03:59 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 25C023A6882 for ; Fri, 19 Dec 2008 02:03:58 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBJA3SpW008346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2008 12:03:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBJA3QYJ008238; Fri, 19 Dec 2008 12:03:26 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18763.29038.834794.70125@fireball.kivinen.iki.fi> Date: Fri, 19 Dec 2008 12:03:26 +0200 From: Tero Kivinen To: "fan zhao" In-Reply-To: References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 15 min Cc: ipsec@ietf.org, ynir@checkpoint.com, Vijay Devarapalli Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH 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 writes: > If including N(Redirect) during the IKE_AUTH, it indicates both 1) and 2) > in one message. This seems to me it is a clearer solution, because > we do not have to update RFC 4306 or change some exisitng implementations > if they interpret the NO_ADDITIONAL_SAS as rejection of a CREATE_CHILD_SA > request only. Not really true, we still need to define what we do for the Child SA creation payloads in the IKE_AUTH reply. Obvious solutions are just leave them out and assume N(REDIRECT) is interpreted as non fatal error (just like NO_ADDITIONAL_SAS or NO_PROPOSAL_CHOSEN) which will create the IKE SA but not create Child SA, or we can also add the NO_ADDITIONAL_SAS or NO_PROPOSAL_CHOSEN error messages to indicate that we are not going to create Child SA. All this really depends whether REDIRECT is allocated from error types or from status types notify messages. Note, that in all cases I do assume we need to delete the IKE_SA created by IKE_SA_INIT and IKE_AUTH with deparate explicit INFORMATIONAL message having empty delete payload inside. This should be done by the client when it is see the redirect and the message request containg delete payload will be acknowledged by the server with empty reply. > Furthermore, based on my understanding, the NO_ADDITIONAL_SAS does not > allow additional Child_SA to be created, but it is not a rejection of IKE_AUTH. > Therefore, as soon as the client processes the IKE_AUTH reply with the > NO_ADDITIONAL_SAS, > it considers the IKE_AUTH procedure is completed, even though it cannot > create a child SA, it can send any informational message under this IKE SA > until it receives the N(Redirect). I do not think this will be changing regardless what we do. The IKE_AUTH will create the IKE_SA, thus IKE_SA will be up and running after the IKE_AUTH regardless whether the IKE_AUTH contained NO_ADDITIONAL_SAS or REDIRECT notify. Client can still send messages to it if it wants, but in most cases there is nothing that would be useful for him to send except delete notification when it decideds to delete the IKE SA as it is redirecting itself to some new server. > When the server receives such informational > messages from the client, it is not clear to me whether the server will have to > respond to such requests from the client even though it knows that the > N(Redirect) > is already sent (the chances are that N(Redirect) may be lost or > delayed). Yes, server must respond to them in both cases. The IKE_SA stays valid until the delete has been sent to it, thus the normal IKEv2 SA rules must be followed for the SA all the time. > When the client receives the N(Redirect) while it has some pending > requests, it is not clearer to me whether the client will have to > wait for the responses from the server or immediately start the > redirect procedure. It can immediately start the redirect procedure, as that is separate IKE SA, and it is not tied to the original IKE SA created with the other server. This means those two IKE SA will be run in parallel way. I.e. it can immediately start creating new IKE SA with new server, then reply ACK to the REDIRECT, and then after small timeout send delete notifications for the old IKE SA to delete it. Hmmm... actually this opens the question why do we send REDIRECT_ACK back at all, as empty reply would be sufficient, or is the intention that if client does NOT send REDIRECT_ACK but sends empty reply then server must assume that client rejected moving to new server, and is staying on the old server. I will take this as separate email, and explain it better... -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 19 02:24: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 3FA5D3A69E0; Fri, 19 Dec 2008 02:24:02 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7A8B3A69F2 for ; Fri, 19 Dec 2008 02:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 Sm252lyUtuEw for ; Fri, 19 Dec 2008 02:23:59 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 516D13A67B2 for ; Fri, 19 Dec 2008 02:23:59 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBJANkl3002205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Dec 2008 12:23:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBJANj1v012963; Fri, 19 Dec 2008 12:23:45 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18763.30257.787031.679868@fireball.kivinen.iki.fi> Date: Fri, 19 Dec 2008 12:23:45 +0200 From: Tero Kivinen To: "Vijay Devarapalli" In-Reply-To: References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 20 min Cc: ipsec@ietf.org, ynir@checkpoint.com Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH 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 Vijay Devarapalli writes: > I don't have a problem using NO_ADDITIONAL_SAS in the IKE_AUTH > response followed by the re-direct message. Good. > However, I think we need a clarification in IKEv2bis draft. It would > be very easy for someone to interpret that the NO_ADDITIONAL_SAS > payload can only be used to reject a CREATE_CHILD_SA request and not > the IKE_AUTH request (because thats what the text in RFC 4306 says.) > and implement accordingly. Yes, we need to fix the SINGLE_PAIR_REQUIRED and NO_ADDITIONAL_SAS text in the draft to indicate those can be also sent during imbedded Child SA creation hapening in the IKE_AUTH. This would mean that we dofollowing changes: ---------------------------------------------------------------------- In section "1.2. The Initial Exchanges" change {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange fails for some reason, the IKE SA is still created as usual. The list of responses in the IKE_AUTH exchange that do not prevent an IKE SA from being set up include at least the following: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. to (i.e add NO_ADDITIONAL_SAS to the example list) {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange fails for some reason, the IKE SA is still created as usual. The list of responses in the IKE_AUTH exchange that do not prevent an IKE SA from being set up include at least the following: NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED, and NO_ADDITIONAL_SAS. ---------------------------------------------------------------------- In section "1.3. The CREATE_CHILD_SA Exchange" change {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification to indicate that a CREATE_CHILD_SA request is unacceptable because the responder is unwilling to accept any more Child SAs on this IKE SA. Some minimal implementations may only accept a single Child SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more. to (explained the situation for minimal clients here already described in section 4, added text about the NO_ADDITIONAL_SAS during IKE_AUTH and explained what it means): {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification to indicate that a child SA creation request is unacceptable because the responder is unwilling to accept any more Child SAs on this IKE SA (either because implementation limitations or because of policy reasons). Some minimal implementations may only accept a single Child SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more. If this error message is received it means it is not useful to try to create more Child SAs with this IKE SA, because all of them will fail with this error. If this error is received during CREATE_CHILD_SA exchange then recipient needs to delete the IKE SA and create new IKE SA with new Child SA if it wants to get the new Child SA created. If this error is received during initial Child SA creation in IKE_AUTH that means the Child SA creation was rejected either because of policy reasons or resource constraint reasons, and there is no point of retrying Child SA creation immediately. Instead the recipient should wait for suitable timeout (several minutes) to see if server either deletes the IKE SA or indicates that situation has changed (for example creates Child SA himself). After the timeout expires the client should delete the IKE SA and try again. ---------------------------------------------------------------------- In section "2.9. Traffic Selector Negotiation" change {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA request is unacceptable because its sender is only willing to accept traffic selectors specifying a single pair of addresses. The requestor is expected to respond by requesting an SA for only the specific traffic it is trying to forward. to (replace CREATE_CHILD_SA with "Child SA creation" {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a Child SA creation request is unacceptable because its sender is only willing to accept traffic selectors specifying a single pair of addresses. The requestor is expected to respond by requesting an SA for only the specific traffic it is trying to forward. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 19 02:49: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 DF02428C105; Fri, 19 Dec 2008 02:49:54 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9CD28C105 for ; Fri, 19 Dec 2008 02:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUy-ScLCCZOl for ; Fri, 19 Dec 2008 02:49:53 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D4CEE28C0F5 for ; Fri, 19 Dec 2008 02:49:52 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBJAnhbM020450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 19 Dec 2008 12:49:43 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBJAngrb005903; Fri, 19 Dec 2008 12:49:42 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18763.31814.743812.266472@fireball.kivinen.iki.fi> Date: Fri, 19 Dec 2008 12:49:42 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 25 min X-Total-Time: 25 min Subject: [IPsec] Redirect draft and REDIRECT_ACK notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org What is the meaning of the REDIRECT_ACK notify? In IKEv2, we normally just send empty reply back to indicate we have received the message, unless there is some information we need to send back. As we have separate REDIRECT_ACK in redirect draft that would indicate for me that following exchange is valid: ---------------------------------------------------------------------- Initiator (VPN client) Responder (VPN GW) ---------------------- ------------------ <-- HDR, SK {N[REDIRECT, IP_R/FQDN_R]} HDR, SK {} --> I.e. the client simply replies with empty reply which means it rejected the redirect now, then when it is ready to do redirect it will send: HDR, SK {N[REDIRECT_ACK]} --> and server will send normal empty reply to that: <-- HDR, SK {} And then client will delete the SA as specified in the spec: HDR, SK {D} --> And server will ack that delete request with empty reply as normally: <-- HDR, SK {} And then the IKE SA has been deleted. ---------------------------------------------------------------------- I do not think we want to support such behavior, in which case it would be better to get rid of the REDIRECT_ACK completely, i.e. do the following exchange instead: ---------------------------------------------------------------------- Initiator (VPN client) Responder (VPN GW) ---------------------- ------------------ <-- HDR, SK {N[REDIRECT, IP_R/FQDN_R]} HDR, SK {} --> After this the server knows client has received the redirect request, and as client does not have option to reject it, the reply to the request means that client is ready. Then client will delete the SA as normally when it is ready: HDR, SK {D} --> And server will ack that delete request with empty reply as normally: <-- HDR, SK {} And then the IKE SA has been deleted. ---------------------------------------------------------------------- The draft is not very clear about who deletes the IKE SA, it just says that client "SHOULD delete the existing security associations with the old gateway.", but it also says that "The gateway MAY also decide to delete the security associations without any signaling from the client.". As in IKEv2 all deletation of SAs will be done explicitly with delete notifications that means that client SHOULD send them out, but server MAY also delete the IKE SA if client does not delete it on time. It would be better to explictly mention those delete payloads sent by the client. So my suggestion is to remove the whole REDIRECT_ACK as it is not needed, and just adds one more complication to the protocol (i.e. allows client to delay the redirection for long time by not replying with the REDIRECT_ACK directly but only after some time (the draft says it MUST send INFORMATIONAL message with REDIRECT_ACK but it does not say when). Also the description of re-transmisions is bit odd as that is normal IKEv2 behavior for request and reply. And I also suggest adding explicit text saying client sends delete payloads when it is ready to delete the IKE SA. I.e. change section 5 to: ---------------------------------------------------------------------- 5. Gateway Initiated Redirect The re-direct mechanism may also be used by a VPN gateway to re- direct the client to another VPN gateway in middle of a session. To re-direct a client, the gateway should send an INFORMATIONAL message with the REDIRECT Notify payload. The REDIRECT payload MUST carry information about the new VPN gateway. When the client receives this message, it acknowledge it with empty reply (as by normal IKEv2 rules). After the client has acknowledged the message it should delete the old IKE SA (send delete payload as separate INFORMATIONAL exchange and server replies to that with empty reply) when it is no longer needed. The following illustrates the INFORMATIONAL message exchange for gateway- initiated redirect. Initiator (VPN client) Responder (VPN GW) ---------------------- ------------------ <-- HDR, SK {N[REDIRECT, IP_R/FQDN_R]} HDR, SK {} --> Client redirects, and when it does not need old IKE SA any more it will delete it: HDR, SK {D} --> <-- HDR, SK {} The INFORMATIONAL message exchange described above is protected by the existing IKEv2 SA between the client and the gateway. The gateway MAY also decide to delete the IKE SA (by sending normal delete payload as INFORMATIONAL exchange) without any signaling from the client. However, it should allow sufficient time for the client to setup the required security associations with the new security gateway. This time period should be configurable on the gateway. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From martinam@adinet.com.uy Fri Dec 19 06:13:20 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AFB63A69A4 for ; Fri, 19 Dec 2008 06:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.68 X-Spam-Level: X-Spam-Status: No, score=-27.68 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBJruwS2jAfv for ; Fri, 19 Dec 2008 06:13:19 -0800 (PST) Received: from h94-75-56-8.ufamts.ru (h94-75-56-8.ufamts.ru [94.75.56.8]) by core3.amsl.com (Postfix) with SMTP id 152EF3A6A32 for ; Fri, 19 Dec 2008 06:13:17 -0800 (PST) To: Subject: Give her concrete firmness From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081219141318.152EF3A6A32@core3.amsl.com> Date: Fri, 19 Dec 2008 06:13:17 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Fri Dec 19 06:35: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 77ED33A6908; Fri, 19 Dec 2008 06:35:25 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1201D3A6908 for ; Fri, 19 Dec 2008 06:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxcEjPl1qW8g for ; Fri, 19 Dec 2008 06:35:21 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id AC7973A68BF for ; Fri, 19 Dec 2008 06:35:20 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 26BC729C002; Fri, 19 Dec 2008 16:35:08 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id BB09729C001; Fri, 19 Dec 2008 16:34:42 +0200 (IST) X-CheckPoint: {494BAFB4-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBJEYffE016200; Fri, 19 Dec 2008 16:34:42 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Fri, 19 Dec 2008 16:34:41 +0200 From: Yaron Sheffer To: Tero Kivinen , "ipsec@ietf.org" Date: Fri, 19 Dec 2008 16:34:41 +0200 Thread-Topic: [IPsec] Redirect draft and REDIRECT_ACK notify Thread-Index: Aclhx4Ysj9GSyeovTu2Lks/Rk7un1QAHgY/w Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D97D3@il-ex01.ad.checkpoint.com> References: <18763.31814.743812.266472@fireball.kivinen.iki.fi> In-Reply-To: <18763.31814.743812.266472@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [IPsec] Redirect draft and REDIRECT_ACK notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0120015744==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0120015744== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02C0_01C961F7.B113C8D0" ------=_NextPart_000_02C0_01C961F7.B113C8D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tero, Vijay, If we remove the explicit REDIRECT_ACK, I suggest that we mandate REDIRECT_SUPPORTED to be sent by both peers in IKE_SA_INIT, unless the response already has another REDIRECT-related notification (the current draft has only the client sending REDIRECT_SUPPORTED). Otherwise the recipient of an empty acknowledgement may not know whether the other side understood the notify. I realize the draft is asymmetric, and this may not be necessary for the exchanges we have in the current version. But we may end up using it in gateway-to-gateway situations. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Tero Kivinen > Sent: Friday, December 19, 2008 12:50 > To: ipsec@ietf.org > Subject: [IPsec] Redirect draft and REDIRECT_ACK notify > > What is the meaning of the REDIRECT_ACK notify? > > In IKEv2, we normally just send empty reply back to indicate we have > received the message, unless there is some information we need to send > back. As we have separate REDIRECT_ACK in redirect draft that would > indicate for me that following exchange is valid: > > ---------------------------------------------------------------------- > Initiator (VPN client) Responder (VPN GW) > ---------------------- ------------------ > > <-- HDR, SK {N[REDIRECT, IP_R/FQDN_R]} > > HDR, SK {} --> > > I.e. the client simply replies with empty reply which > means it rejected the redirect now, then when it is > ready to do redirect it will send: > > HDR, SK {N[REDIRECT_ACK]} --> > > and server will send normal empty reply to that: > > <-- HDR, SK {} > > And then client will delete the SA as specified in the > spec: > > HDR, SK {D} --> > > And server will ack that delete request with empty > reply as normally: > > <-- HDR, SK {} > > And then the IKE SA has been deleted. > ---------------------------------------------------------------------- > > I do not think we want to support such behavior, in which case it > would be better to get rid of the REDIRECT_ACK completely, i.e. do the > following exchange instead: > > ---------------------------------------------------------------------- > Initiator (VPN client) Responder (VPN GW) > ---------------------- ------------------ > > <-- HDR, SK {N[REDIRECT, IP_R/FQDN_R]} > > HDR, SK {} --> > > After this the server knows client has received the > redirect request, and as client does not have option > to reject it, the reply to the request means that > client is ready. Then client will delete the SA as > normally when it is ready: > > HDR, SK {D} --> > > And server will ack that delete request with empty > reply as normally: > > <-- HDR, SK {} > > And then the IKE SA has been deleted. > ---------------------------------------------------------------------- > > The draft is not very clear about who deletes the IKE SA, it just says > that client "SHOULD delete the existing security associations with the > old gateway.", but it also says that "The gateway MAY also decide to > delete the security associations without any signaling from the > client.". > > As in IKEv2 all deletation of SAs will be done explicitly with delete > notifications that means that client SHOULD send them out, but server > MAY also delete the IKE SA if client does not delete it on time. It > would be better to explictly mention those delete payloads sent by the > client. > > So my suggestion is to remove the whole REDIRECT_ACK as it is not > needed, and just adds one more complication to the protocol (i.e. > allows client to delay the redirection for long time by not replying > with the REDIRECT_ACK directly but only after some time (the draft > says it MUST send INFORMATIONAL message with REDIRECT_ACK but it does > not say when). > > Also the description of re-transmisions is bit odd as that is normal > IKEv2 behavior for request and reply. > > And I also suggest adding explicit text saying client sends delete > payloads when it is ready to delete the IKE SA. > > I.e. change section 5 to: > ---------------------------------------------------------------------- > 5. Gateway Initiated Redirect > > The re-direct mechanism may also be used by a VPN gateway to re- > direct the client to another VPN gateway in middle of a session. To > re-direct a client, the gateway should send an INFORMATIONAL > message with the REDIRECT Notify payload. The REDIRECT payload MUST > carry information about the new VPN gateway. When the client > receives this message, it acknowledge it with empty reply (as by > normal IKEv2 rules). After the client has acknowledged the message > it should delete the old IKE SA (send delete payload as separate > INFORMATIONAL exchange and server replies to that with empty reply) > when it is no longer needed. > > The following illustrates the INFORMATIONAL message exchange for > gateway- initiated redirect. > > Initiator (VPN client) Responder (VPN GW) > ---------------------- ------------------ > > <-- HDR, SK {N[REDIRECT, IP_R/FQDN_R]} > > HDR, SK {} --> > > Client redirects, and when it does not need old IKE SA > any more it will delete it: > > HDR, SK {D} --> > > <-- HDR, SK {} > > > The INFORMATIONAL message exchange described above is protected by > the existing IKEv2 SA between the client and the gateway. > > The gateway MAY also decide to delete the IKE SA (by sending normal > delete payload as INFORMATIONAL exchange) without any signaling > from the client. However, it should allow sufficient time for the > client to setup the required security associations with the new > security gateway. This time period should be configurable on the > gateway. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_02C0_01C961F7.B113C8D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIxOTE0MzQ0MVowIwYJKoZIhvcNAQkEMRYEFM/tmmAJH1aP YUs3GpEa/Kh3mBoiMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA LiniH2fPVrNI6v0YBWthhMGk9Ne2HM0GMtycxnkKBcfm4zQgUyumiwU7hEEtSu8xozly8wsXg+A8 LQXYHFFezyEEPOFMUeSuggeLKtQH6yNd95AOk8Z//l+IfAiceBZzFvb2BSik2reR153viBvHFLQF ErGwC3+KG24pscUrtA9nTdHVUMfK5w2gmYVv5lNUJJuigYJA/xT7HOZzqoOvvV8Fzg91EASgKsqy bbs2Qk0djHlcBGLE7EzUQeksurI9CHuUlhJPyu7FSwqFMqORiZYZHV/TZANCuHMDPfgqg/MjyyhR 3GPQb6D8ruYfz//IcNTrf5ZfyPzpE1zCjkP5kgAAAAAAAA== ------=_NextPart_000_02C0_01C961F7.B113C8D0-- --===============0120015744== 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 --===============0120015744==-- From ipsec-bounces@ietf.org Fri Dec 19 13:51:21 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 074B628C0E8; Fri, 19 Dec 2008 13:51:21 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6443A63EC for ; Fri, 19 Dec 2008 13:51:19 -0800 (PST) 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 k8GxKosho2X0 for ; Fri, 19 Dec 2008 13:51:19 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.245]) by core3.amsl.com (Postfix) with ESMTP id CA2893A67E2 for ; Fri, 19 Dec 2008 13:51:18 -0800 (PST) Received: by an-out-0708.google.com with SMTP id c5so406538anc.4 for ; Fri, 19 Dec 2008 13:51:10 -0800 (PST) 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=Ny0hvif3JJc/KCxq7DWOtsNUi1jwSEqzFu5/DPQSAX8=; b=vPzE+pMjuVFvu0L6vC90JvZttANPnabXt8748OQo/TbGzhFEL108thk862eSM5Z4e8 EDR0j8pRsA6Tg2DvCrn9iQOohb9in2FitOS2rp0LrO1NIxvh+PSiBlCcpuNNQ/NCXQEX Vg4e7ZGteR2BVGBO9LL2RJNBR+XPxSYJtiKg4= 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=ZLual8tfEsWContfxZrOWgud8z6XekC+jgER0+9UD6mgYmt1UHPekKrpKTxZ0vgsl/ Vgna6rPYB3clQCtiFS//VBEqUUOoVxUmXKFNfEK/u48lM++wyd6ZJH9+R/ixk+sPc3Fa 1+XrRBoz4kvLRFcVIHorCljMGWYA0cm9OU4f0= Received: by 10.142.105.13 with SMTP id d13mr1493711wfc.196.1229723469948; Fri, 19 Dec 2008 13:51:09 -0800 (PST) Received: by 10.142.234.19 with HTTP; Fri, 19 Dec 2008 13:51:09 -0800 (PST) Message-ID: Date: Fri, 19 Dec 2008 13:51:09 -0800 From: "Vijay Devarapalli" To: "Tero Kivinen" In-Reply-To: <18763.31814.743812.266472@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <18763.31814.743812.266472@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect draft and REDIRECT_ACK notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, On Fri, Dec 19, 2008 at 2:49 AM, Tero Kivinen wrote: > What is the meaning of the REDIRECT_ACK notify? > > In IKEv2, we normally just send empty reply back to indicate we have > received the message, unless there is some information we need to send > back. As we have separate REDIRECT_ACK in redirect draft that would > indicate for me that following exchange is valid: It was never possible for the client to reject the REDIRECT message from the gateway. The REDIRECT_ACK was just to confirm to the gateway that the client did process the REDIRECT payload and understands that it can no longer use the current gateway. I think I was missing the fact that you can ack a message with just an empty response. Thats why I was using the REDIRECT_ACK payload to explicitly indicate that the REDIRECT payload was processed and understood. > ---------------------------------------------------------------------- > Initiator (VPN client) Responder (VPN GW) > ---------------------- ------------------ > > <-- HDR, SK {N[REDIRECT, IP_R/FQDN_R]} > > HDR, SK {} --> > > I.e. the client simply replies with empty reply which > means it rejected the redirect now, then when it is > ready to do redirect it will send: > > HDR, SK {N[REDIRECT_ACK]} --> > > and server will send normal empty reply to that: > > <-- HDR, SK {} > > And then client will delete the SA as specified in the > spec: > > HDR, SK {D} --> > > And server will ack that delete request with empty > reply as normally: > > <-- HDR, SK {} > > And then the IKE SA has been deleted. > ---------------------------------------------------------------------- > > I do not think we want to support such behavior, in which case it > would be better to get rid of the REDIRECT_ACK completely, i.e. do the > following exchange instead: > > ---------------------------------------------------------------------- > Initiator (VPN client) Responder (VPN GW) > ---------------------- ------------------ > > <-- HDR, SK {N[REDIRECT, IP_R/FQDN_R]} > > HDR, SK {} --> > > After this the server knows client has received the > redirect request, and as client does not have option > to reject it, the reply to the request means that > client is ready. Then client will delete the SA as > normally when it is ready: If an empty message is sufficient, then obviously specifying an additional payload, REDIRECT_ACK in this case, does not make sense. This is fine with me. > And I also suggest adding explicit text saying client sends delete > payloads when it is ready to delete the IKE SA. Yaron had brought this up offline. In my working version of the draft, I have already clarified this. The current text reads Once the client responds to the gateway with the REDIRECT_ACK payload, it SHOULD delete the existing security associations with the old gateway by sending an Informational message with a DELETE payload. The gateway MAY also decide to delete the security associations without any signaling from the client. However, it should allow sufficient time for the client to setup the required security associations with the new security gateway. This time period should be configurable on the gateway. > The gateway MAY also decide to delete the IKE SA (by sending normal > delete payload as INFORMATIONAL exchange) without any signaling > from the client. In this case, I want the gateway to be able to delete the IKE SA without sending an INFORMATIONAL message to the client. The re-direct could be happening due to an overload. At this point I don't want the gateway to send additional messages to the client. It already did send the REDIRECT message to the client. So it will just implicitly delete it. Vijay _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kempd@amax.com Fri Dec 19 15:32:48 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651FF3A6839 for ; Fri, 19 Dec 2008 15:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.056 X-Spam-Level: X-Spam-Status: No, score=-0.056 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eY0NNNNzICeu for ; Fri, 19 Dec 2008 15:32:48 -0800 (PST) Received: from 213-156-54-241.ip.fastwebnet.it (213-156-54-241.ip.fastwebnet.it [213.156.54.241]) by core3.amsl.com (Postfix) with SMTP id 2B0193A67E5 for ; Fri, 19 Dec 2008 15:32:46 -0800 (PST) To: Subject: We have you been, honey? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081219233247.2B0193A67E5@core3.amsl.com> Date: Fri, 19 Dec 2008 15:32:46 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Fri Dec 19 16:18: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 7CC163A69FF; Fri, 19 Dec 2008 16:18:33 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 068CA3A6A34 for ; Thu, 18 Dec 2008 13:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y30wIYryZiWG for ; Thu, 18 Dec 2008 13:56:40 -0800 (PST) Received: from arnor.apana.org.au (rhun.apana.org.au [64.62.148.172]) by core3.amsl.com (Postfix) with ESMTP id 371243A6971 for ; Thu, 18 Dec 2008 13:56:38 -0800 (PST) Received: from gondolin.me.apana.org.au ([192.168.0.6]) by arnor.apana.org.au with esmtp (Exim 4.63 #1 (Debian)) id 1LDQr6-0001Yt-AT for ; Fri, 19 Dec 2008 08:56:28 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.69) (envelope-from ) id 1LDQr3-0000JN-UK for ipsec@ietf.org; Fri, 19 Dec 2008 08:56:25 +1100 Date: Fri, 19 Dec 2008 08:56:25 +1100 From: Herbert Xu To: ipsec@ietf.org Message-ID: <20081218215625.GA1070@gondor.apana.org.au> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Mailman-Approved-At: Fri, 19 Dec 2008 16:18:32 -0800 Subject: [IPsec] To UDP encapsulate or not X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi: The current draft has added the statement: o Implementations MUST process received UDP-encapsulated ESP packets even when no NAT was detected. This has created implementation ambiguity which did not exist before. Back in IKEv1, NAT-T was a mess but we did have a way to negotiate whether UDP encapsulation should be used on ESP packets or not. In IKEv2, this was done away with and it is implied that we should decide on whether to use UDP encapsulation depending on whether NAT is detected. That is pretty vague but at least you could tell someone off for performing UDP encapsulation without detecting NAT. With the newly added statement, implementations now face a dilemma. As it is now acceptable for the peer to send UDP encapsulated packets in all cases, what should we do when sending data back? If we choose to stick with unencapsulated ESP, then due to the presence of firewalls (which unlike NAT devices cannot be easily detected), this may never make it back to the peer. So it would seem that the only safe option would in fact be to send UDP encapsulated traffic. But that's exactly what people were trying to avoid due to the associated protocol overheads. In other words, by adding that statement, we're in fact pushing all implementors to use UDP encapsulation whether NAT is detected or not. Therefore I propose that the above statement be removed. If a peer really wanted to use UDP encapsulation, it could easily spoof the NAT detection payloads. If you don't like that, then we could also add explicit negotiation of UDP encapsulation just as the original NAT-T scheme did. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Dec 20 07:15: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 F179828C0E6; Sat, 20 Dec 2008 07:15:18 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C99D28C0E6 for ; Sat, 20 Dec 2008 07:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.416, 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 ZYHJXYoyCwj2 for ; Sat, 20 Dec 2008 07:15:16 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D9E7C28B23E for ; Sat, 20 Dec 2008 07:15:15 -0800 (PST) Received: (qmail invoked by alias); 20 Dec 2008 15:15:06 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp012) with SMTP; 20 Dec 2008 16:15:06 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19beAdNoTdb6Hj5yE29qOShmgEyBxj59ifFyn/6Nf 4p9WYmp33H01MC From: "Hannes Tschofenig" To: "'Herbert Xu'" , References: <20081218215625.GA1070@gondor.apana.org.au> Date: Sat, 20 Dec 2008 17:15:22 +0200 Message-ID: <019f01c962b5$c89cc650$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20081218215625.GA1070@gondor.apana.org.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AcliOHsduYjsmRXiSd2OshegDQeZeQAfM5Ww X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Subject: Re: [IPsec] To UDP encapsulate or not 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 Herbert, I believe that this is a very useful statement given that there are many NATs and firewalls out there and you never know whether you run into one. Having the server to implement UDP encapsulation and to be able to deal with UDP encapsulated packets (regardless whether a NAT/firewall was previously detected or not) is pretty useful. Are you worried about the increased packet size? Ciao Hannes >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >On Behalf Of Herbert Xu >Sent: 18 December, 2008 23:56 >To: ipsec@ietf.org >Subject: [IPsec] To UDP encapsulate or not > >Hi: > >The current draft has added the statement: > > o Implementations MUST process received UDP-encapsulated ESP > packets even when no NAT was detected. > >This has created implementation ambiguity which did not exist >before. Back in IKEv1, NAT-T was a mess but we did have a way >to negotiate whether UDP encapsulation should be used on ESP >packets or not. > >In IKEv2, this was done away with and it is implied that we >should decide on whether to use UDP encapsulation depending on >whether NAT is detected. > >That is pretty vague but at least you could tell someone off >for performing UDP encapsulation without detecting NAT. > >With the newly added statement, implementations now face a dilemma. >As it is now acceptable for the peer to send UDP encapsulated >packets in all cases, what should we do when sending data back? > >If we choose to stick with unencapsulated ESP, then due to the >presence of firewalls (which unlike NAT devices cannot be >easily detected), this may never make it back to the peer. > >So it would seem that the only safe option would in fact be to >send UDP encapsulated traffic. But that's exactly what people >were trying to avoid due to the associated protocol overheads. > >In other words, by adding that statement, we're in fact >pushing all implementors to use UDP encapsulation whether NAT >is detected or not. > >Therefore I propose that the above statement be removed. > >If a peer really wanted to use UDP encapsulation, it could >easily spoof the NAT detection payloads. If you don't like >that, then we could also add explicit negotiation of UDP >encapsulation just as the original NAT-T scheme did. > >Cheers, >-- >Visit Openswan at http://www.openswan.org/ >Email: Herbert Xu ~{PmV>HI~} >Home Page: http://gondor.apana.org.au/~herbert/ >PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt >_______________________________________________ >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 Dec 20 15:51: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 184553A6805; Sat, 20 Dec 2008 15:51:31 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE50D3A6805 for ; Sat, 20 Dec 2008 15:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.514 X-Spam-Level: X-Spam-Status: No, score=-1.514 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFfPS-XwcVPW for ; Sat, 20 Dec 2008 15:51:29 -0800 (PST) Received: from arnor.apana.org.au (rhun.apana.org.au [64.62.148.172]) by core3.amsl.com (Postfix) with ESMTP id EC7743A6407 for ; Sat, 20 Dec 2008 15:51:28 -0800 (PST) Received: from gondolin.me.apana.org.au ([192.168.0.6]) by arnor.apana.org.au with esmtp (Exim 4.63 #1 (Debian)) id 1LEBbJ-000105-Iz; Sun, 21 Dec 2008 10:51:17 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.69) (envelope-from ) id 1LEBbF-0005qU-OY; Sun, 21 Dec 2008 10:51:13 +1100 Date: Sun, 21 Dec 2008 10:51:13 +1100 From: Herbert Xu To: Hannes Tschofenig Message-ID: <20081220235113.GA20449@gondor.apana.org.au> References: <20081218215625.GA1070@gondor.apana.org.au> <019f01c962b5$c89cc650$0201a8c0@nsnintra.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <019f01c962b5$c89cc650$0201a8c0@nsnintra.net> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ipsec@ietf.org Subject: Re: [IPsec] To UDP encapsulate or not 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 Hannes: On Sat, Dec 20, 2008 at 05:15:22PM +0200, Hannes Tschofenig wrote: > > I believe that this is a very useful statement given that there are many > NATs and firewalls out there and you never know whether you run into one. > > Having the server to implement UDP encapsulation and to be able to deal with > UDP encapsulated packets (regardless whether a NAT/firewall was previously > detected or not) is pretty useful. > > Are you worried about the increased packet size? No I'm not so worried about the packet size myself (thoughs others may). I'm worried about the potential to create blackholes should some implementations choose to use UDP encapsulation and others choose not to. Even if both sides are prepared to accept both packets with and without encapsulation, the presence of stateful firewalls in the middle can kill the connection if their choices do not match. So if we deem that UDP encapsulation's usefulness outweighs its overheads, and we're not prepared to let it be negotiated, then we should require it instead of leaving it up to the implementation (in the case where NAT is not detected). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Dec 21 03:58: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 8677C3A68DE; Sun, 21 Dec 2008 03:58:53 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 792843A68DE for ; Sun, 21 Dec 2008 03:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 xpsIN16C0ifg for ; Sun, 21 Dec 2008 03:58:51 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 823B23A67C0 for ; Sun, 21 Dec 2008 03:58:50 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id EBC8729C003; Sun, 21 Dec 2008 13:58:40 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A0F5129C002; Sun, 21 Dec 2008 13:58:39 +0200 (IST) X-CheckPoint: {494E2E10-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBLBwcfE023315; Sun, 21 Dec 2008 13:58:39 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 21 Dec 2008 13:58:38 +0200 From: Yaron Sheffer To: Tero Kivinen , Vijay Devarapalli Date: Sun, 21 Dec 2008 13:58:35 +0200 Thread-Topic: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH Thread-Index: Aclhw+nuDld+vBcHQFmAAKi7md9LSgBnH8iA Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D98CC@il-ex01.ad.checkpoint.com> References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> <18763.30257.787031.679868@fireball.kivinen.iki.fi> In-Reply-To: <18763.30257.787031.679868@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH 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="===============1263721775==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1263721775== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0335_01C96374.3795F360" ------=_NextPart_000_0335_01C96374.3795F360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Vijay, Tero, First a minor technical point that's alluded to in Tero's discussion: the IANA considerations should say explicitly that the Notification type is taken from the Status space. You don't want to deduce it from the number range. Now the real issue: I suggest that we reconsider the solution we're proposing here. When a client receives a NO_ADDITIONAL_SAS notify, it is left with an IKE SA which is basically useless. So the client will naturally fail the entire connection attempt. With the current proposal we are asking the client to *guess* that the gateway wants to redirect it somewhere else, and to wait (for an indefinite time) for that redirect notification to arrive. If the Redirect never arrives, we just have a useless timeout. In other words, I propose to go back to Fan's proposal of an explicit Redirect notify in IKE_AUTH, so that the client knows for sure what type of failure it is seeing. Thanks, and Happy Holidays! Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Tero Kivinen > Sent: Friday, December 19, 2008 12:24 > To: Vijay Devarapalli > Cc: ipsec@ietf.org; Yoav Nir > Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH > > Vijay Devarapalli writes: > > I don't have a problem using NO_ADDITIONAL_SAS in the IKE_AUTH > > response followed by the re-direct message. > > Good. > > > However, I think we need a clarification in IKEv2bis draft. It would > > be very easy for someone to interpret that the NO_ADDITIONAL_SAS > > payload can only be used to reject a CREATE_CHILD_SA request and not > > the IKE_AUTH request (because thats what the text in RFC 4306 says.) > > and implement accordingly. > > Yes, we need to fix the SINGLE_PAIR_REQUIRED and NO_ADDITIONAL_SAS > text in the draft to indicate those can be also sent during imbedded > Child SA creation hapening in the IKE_AUTH. > > This would mean that we dofollowing changes: > ---------------------------------------------------------------------- > In section "1.2. The Initial Exchanges" change > > {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange > fails for some reason, the IKE SA is still created as usual. The > list of responses in the IKE_AUTH exchange that do not prevent an IKE > SA from being set up include at least the following: > NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, > INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. > > to (i.e add NO_ADDITIONAL_SAS to the example list) > > {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange > fails for some reason, the IKE SA is still created as usual. The > list of responses in the IKE_AUTH exchange that do not prevent an IKE > SA from being set up include at least the following: > NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, > INTERNAL_ADDRESS_FAILURE, FAILED_CP_REQUIRED, and NO_ADDITIONAL_SAS. > ---------------------------------------------------------------------- > In section "1.3. The CREATE_CHILD_SA Exchange" change > > {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification > to indicate that a CREATE_CHILD_SA request is unacceptable because > the responder is unwilling to accept any more Child SAs on this IKE > SA. Some minimal implementations may only accept a single Child SA > setup in the context of an initial IKE exchange and reject any > subsequent attempts to add more. > > to (explained the situation for minimal clients here already described > in section 4, added text about the NO_ADDITIONAL_SAS during IKE_AUTH > and explained what it means): > > {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS > notification to indicate that a child SA creation request is > unacceptable because the responder is unwilling to accept any more > Child SAs on this IKE SA (either because implementation limitations > or because of policy reasons). Some minimal implementations may > only accept a single Child SA setup in the context of an initial > IKE exchange and reject any subsequent attempts to add more. If > this error message is received it means it is not useful to try to > create more Child SAs with this IKE SA, because all of them will > fail with this error. If this error is received during > CREATE_CHILD_SA exchange then recipient needs to delete the IKE SA > and create new IKE SA with new Child SA if it wants to get the new > Child SA created. If this error is received during initial Child SA > creation in IKE_AUTH that means the Child SA creation was rejected > either because of policy reasons or resource constraint reasons, > and there is no point of retrying Child SA creation immediately. > Instead the recipient should wait for suitable timeout (several > minutes) to see if server either deletes the IKE SA or indicates > that situation has changed (for example creates Child SA himself). > After the timeout expires the client should delete the IKE SA and > try again. > ---------------------------------------------------------------------- > In section "2.9. Traffic Selector Negotiation" change > > {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a > CREATE_CHILD_SA request is unacceptable because its sender is only > willing to accept traffic selectors specifying a single pair of > addresses. The requestor is expected to respond by requesting an SA > for only the specific traffic it is trying to forward. > > to (replace CREATE_CHILD_SA with "Child SA creation" > > {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a > Child SA creation request is unacceptable because its sender is > only willing to accept traffic selectors specifying a single pair > of addresses. The requestor is expected to respond by requesting an > SA for only the specific traffic it is trying to forward. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0335_01C96374.3795F360 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIyMTExNTgzNVowIwYJKoZIhvcNAQkEMRYEFAnHs9VrIuWi oLUQgAI0BxYVU6HAMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA pXChyjREg0sfkM1r9i1wVL256yryyPwz+Mft5Qldpzka/t+tRH3L19Apa5YUloF2eDyOQdckKHiq 17OmZv+BpYWgsHNuaCab5D2mCDhkCKb+CpiitPVy7GT2Rqyu90fAk9VRA9ZjCM37GSHqj/btIIKW mPthHfjRaZGPw8pR23dj0P8FlhOG1UzooXW1pF5BzldUHUrurmtkkzaUgNhnYRPF0hkdurbBFJ8D 8Fh/93mrk84/fqo/nyY4zO1Lv+Eq+rRcajxgb+XlnxhMuXRkk+E3ww1L1dvY14wDx2UhM6kUf1Bz Yh4y2Mj8rEHQqYYuhLjiSZuG3j7xrE1VqN+hVgAAAAAAAA== ------=_NextPart_000_0335_01C96374.3795F360-- --===============1263721775== 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 --===============1263721775==-- From ipsec-bounces@ietf.org Sun Dec 21 04:31: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 AD0A43A68A5; Sun, 21 Dec 2008 04:31:08 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58A9C3A68A5 for ; Sun, 21 Dec 2008 04:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 6NiEvwB4jyTs for ; Sun, 21 Dec 2008 04:31:06 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 26CCC3A67C0 for ; Sun, 21 Dec 2008 04:31:05 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBLCUkVb006558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Dec 2008 14:30:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBLCUkVt003129; Sun, 21 Dec 2008 14:30:46 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18766.14070.413252.726605@fireball.kivinen.iki.fi> Date: Sun, 21 Dec 2008 14:30:46 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D97D3@il-ex01.ad.checkpoint.com> References: <18763.31814.743812.266472@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D97D3@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Redirect draft and REDIRECT_ACK notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yaron Sheffer writes: > If we remove the explicit REDIRECT_ACK, I suggest that we mandate > REDIRECT_SUPPORTED to be sent by both peers in IKE_SA_INIT, unless the > response already has another REDIRECT-related notification (the current > draft has only the client sending REDIRECT_SUPPORTED). Otherwise the > recipient of an empty acknowledgement may not know whether the other side > understood the notify. I do not think we need it. The client has already announced the support for the redirect protocol by sending N(REDIRECT_SUPPORTED) in the IKE_SA_INIT. The server has not indicated support for it yet, but on the other hand it is the one who is starting the redirect by sending the N(REDIRECT) to the client, and it is only allowed to send that if the client has announced that it supports redirect protocol in the IKE_SA_INIT. > I realize the draft is asymmetric, and this may not be necessary for the > exchanges we have in the current version. But we may end up using it in > gateway-to-gateway situations. That would only be needed there in case the original initiator wants to redirect the other end to some other server, but as he was the original initiator, it might be easier for him to just to tell the other node where he wants the responder to connect to start connection to the original responder, and close his own SA. Opening cases where both ends can redirect other ends, will cause other complications, so those do require more thinking. This was the reason why mobike mostly left that kind of situations out of scope (or mostly left out the rendezvous servers needed in that kind of situations). Bidirectional N(REDIRECT_SUPPORTED) is not needed unless you want change the roles of the initiator/responder and want to original responder to become initiator that connects to some other server. If that kind of scenario is needed, we need to add more text to draft and describe it, I do not think we want to allow it by just saying N(REDIRECT_SUPPORTED) is sent in both directions, and both ends can send N(REDIRECT) notifies. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Dec 21 04:45: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 514B03A689F; Sun, 21 Dec 2008 04:45:04 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4B63A6897 for ; Sun, 21 Dec 2008 04:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpmsuVek5a+v for ; Sun, 21 Dec 2008 04:45:01 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 285543A689F for ; Sun, 21 Dec 2008 04:45:00 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBLCimar022158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 21 Dec 2008 14:44:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBLCimEB008602; Sun, 21 Dec 2008 14:44:48 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18766.14912.531900.533398@fireball.kivinen.iki.fi> Date: Sun, 21 Dec 2008 14:44:48 +0200 From: Tero Kivinen To: "Vijay Devarapalli" In-Reply-To: References: <18763.31814.743812.266472@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 14 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Redirect draft and REDIRECT_ACK notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Vijay Devarapalli writes: > It was never possible for the client to reject the REDIRECT message > from the gateway. The REDIRECT_ACK was just to confirm to the gateway > that the client did process the REDIRECT payload and understands that > it can no longer use the current gateway. Good. > I think I was missing the fact that you can ack a message with just an > empty response. Thats why I was using the REDIRECT_ACK payload to > explicitly indicate that the REDIRECT payload was processed and > understood. Yes, after I sent the email I realized that the protocol you described would be what you would use for IKEv1, but as in IKEv2 we do have always request - response pairs and empty response do acknowledge that the other end received the request, that is what we should be using here. > Yaron had brought this up offline. In my working version of the draft, > I have already clarified this. The current text reads > > Once the client responds to the gateway with the REDIRECT_ACK > payload, it SHOULD delete the existing security associations with the > old gateway by sending an Informational message with a DELETE > payload. The gateway MAY also decide to delete the security > associations without any signaling from the client. However, it > should allow sufficient time for the client to setup the required > security associations with the new security gateway. This time > period should be configurable on the gateway. That text is ok for me, altought I would also add similar text about delete payloads to the gateway deleting SAs case. Also including those delete payload as INFORMATIONAL exchange to the message examples would be good. > > The gateway MAY also decide to delete the IKE SA (by sending normal > > delete payload as INFORMATIONAL exchange) without any signaling > > from the client. > > In this case, I want the gateway to be able to delete the IKE SA > without sending an INFORMATIONAL message to the client. The re-direct > could be happening due to an overload. At this point I don't want the > gateway to send additional messages to the client. It already did send > the REDIRECT message to the client. So it will just implicitly delete > it. That is not really acceptable as IKEv2 protocol extension. The IKEv2 is reliable protocol, all exchanges are request - reply pairs, and IKE SA is normally only deleted by delete payload. IKE SA will also be deleted because of error situations, i.e. in case the other end does not send reply to the request you sent (after multiple retries etc). If the gateway is really that badly out of resources then it will most likely run out of resources when trying to send the delete notification and that out of memory type of situation is fatal, and will cause the server to delete the IKE SA. As client does not get any message about that it can still try to use the IKE SA until the dead peer detection will delete the IKE SA because server does not reply to the liveness requests. This is not normal situation, and we do not want to standardize that any implementation may be using such method. If the server is really that badly out of resources, it can include the N(REDIRECT) and D() payloads in the same INFORMATIONAL exchange, and ask client to redirect to new server and delete the IKE SA at that same request. If it allowed client for some time to clean up state and reconnect to new server, then it should allow client time to delete the IKE SA also. Client do not have any reason NOT to delete the IKE SA, so why would the client not delete the old IKE SA. Only reason I can see which could cause the client not to delete the IKE SA quickly is that the server where N(REDIRECT) asked client to connect, is not reachable, thus client will still keep old IKE and IPsec SAs up until it gets new SAs up, but if the server is down, then it cannot do that. If the server then suddenly silently delete the IKE SA that will silently create the black hole for the client, causing all the packets sent by client to be disappearing to black hole without any indication to the user what happened. On the other hand if server do send IKE SA after suitable timeout (say 30-60 seconds) then client will get indication that the old SAs disappeared, and new are not yet up, and it can indicate that properly to the user. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Dec 21 05:10: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 3DDD23A6844; Sun, 21 Dec 2008 05:10:18 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8047228C0D7 for ; Sun, 21 Dec 2008 05:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 EQJyjFWmFxgd for ; Sun, 21 Dec 2008 05:10:15 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 6B71A3A67C0 for ; Sun, 21 Dec 2008 05:10:14 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C912429C003; Sun, 21 Dec 2008 15:10:03 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id A605429C002; Sun, 21 Dec 2008 15:10:02 +0200 (IST) X-CheckPoint: {494E3ECB-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBLDA1fE008421; Sun, 21 Dec 2008 15:10:02 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 21 Dec 2008 15:10:01 +0200 From: Yaron Sheffer To: Tero Kivinen Date: Sun, 21 Dec 2008 15:10:05 +0200 Thread-Topic: [IPsec] Redirect draft and REDIRECT_ACK notify Thread-Index: AcljZ/nzHjkpvZENTp6jNxBdjOV2BwABKVxg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D98F1@il-ex01.ad.checkpoint.com> References: <18763.31814.743812.266472@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D97D3@il-ex01.ad.checkpoint.com> <18766.14070.413252.726605@fireball.kivinen.iki.fi> In-Reply-To: <18766.14070.413252.726605@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Redirect draft and REDIRECT_ACK notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1000257586==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1000257586== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_033A_01C9637E.343AD5F0" ------=_NextPart_000_033A_01C9637E.343AD5F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The scenario I have in mind is planned maintenance, where one cluster member redirects all traffic to the other member. I think this situation is in general not as complicated as in MOBIKE, but I may be missing something. Thanks, Yaron > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Sunday, December 21, 2008 14:31 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Redirect draft and REDIRECT_ACK notify > > Yaron Sheffer writes: > > If we remove the explicit REDIRECT_ACK, I suggest that we mandate > > REDIRECT_SUPPORTED to be sent by both peers in IKE_SA_INIT, unless the > > response already has another REDIRECT-related notification (the current > > draft has only the client sending REDIRECT_SUPPORTED). Otherwise the > > recipient of an empty acknowledgement may not know whether the other > side > > understood the notify. > > I do not think we need it. The client has already announced the > support for the redirect protocol by sending N(REDIRECT_SUPPORTED) in > the IKE_SA_INIT. The server has not indicated support for it yet, but > on the other hand it is the one who is starting the redirect by > sending the N(REDIRECT) to the client, and it is only allowed to send > that if the client has announced that it supports redirect protocol in > the IKE_SA_INIT. > > > I realize the draft is asymmetric, and this may not be necessary for the > > exchanges we have in the current version. But we may end up using it in > > gateway-to-gateway situations. > > That would only be needed there in case the original initiator wants > to redirect the other end to some other server, but as he was the > original initiator, it might be easier for him to just to tell the > other node where he wants the responder to connect to start connection > to the original responder, and close his own SA. > > Opening cases where both ends can redirect other ends, will cause > other complications, so those do require more thinking. This was the > reason why mobike mostly left that kind of situations out of scope (or > mostly left out the rendezvous servers needed in that kind of > situations). > > Bidirectional N(REDIRECT_SUPPORTED) is not needed unless you want > change the roles of the initiator/responder and want to original > responder to become initiator that connects to some other server. > > If that kind of scenario is needed, we need to add more text to draft > and describe it, I do not think we want to allow it by just saying > N(REDIRECT_SUPPORTED) is sent in both directions, and both ends can > send N(REDIRECT) notifies. > -- > kivinen@iki.fi > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_033A_01C9637E.343AD5F0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA4MTIyMTEzMTAwNVowIwYJKoZIhvcNAQkEMRYEFAt44bRvYT5g VO5RQrR3W9wuNLiXMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA W0Mm3qVOMLzcN9Yb80xl+4JhE3D/OZctUETzoK/xgCt9d2Xb8f3ssFBENBcuI75x1LqIetvUzrX4 ShJa0ma/ETzjUxcYh+7d4vzrJ12xMNGh9rOE2pZpIU+a3R2lDKo7Dqx8mZ0XpjKm0FrhriylKgml NUxFcmnzKjxXRow3Qf1wUy15DWLJ62V94mSK6qyahCmnpxx6fexpaik6lyDKNhiilZhenbMFDY/v 1gPDB9ixLpmjinHrIf5KcOPaLPWpCLsfEtPpH+OeBwAgIWhMaS639Ewsyz7DIwiPoT42i4hcUVGV bShE/4/0FIvD+kVKrCY0iOTjPeWTbtBpoA0xvgAAAAAAAA== ------=_NextPart_000_033A_01C9637E.343AD5F0-- --===============1000257586== 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 --===============1000257586==-- From ipsec-bounces@ietf.org Sun Dec 21 09:09: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 81B073A67A8; Sun, 21 Dec 2008 09:09:51 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4D33A67A8 for ; Sun, 21 Dec 2008 09:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.398, 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 pf-tVCXywVdg for ; Sun, 21 Dec 2008 09:09:49 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id D76913A6784 for ; Sun, 21 Dec 2008 09:09:48 -0800 (PST) Received: (qmail invoked by alias); 21 Dec 2008 17:09:39 -0000 Received: from a91-154-105-43.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.105.43] by mail.gmx.net (mp065) with SMTP; 21 Dec 2008 18:09:39 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19jzE8kji5jXODgn3DP70Ai6gOnqnH057EfsCb+0T NNmGcRQX0I0BoU From: "Hannes Tschofenig" To: "'Herbert Xu'" References: <20081218215625.GA1070@gondor.apana.org.au> <019f01c962b5$c89cc650$0201a8c0@nsnintra.net> <20081220235113.GA20449@gondor.apana.org.au> Date: Sun, 21 Dec 2008 19:09:55 +0200 Message-ID: <01c201c9638e$f422ff90$0201a8c0@nsnintra.net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20081220235113.GA20449@gondor.apana.org.au> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acli/dvCo5ZdhYTgR2aBx9dpBIX1yQAj9kOA X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: ipsec@ietf.org Subject: Re: [IPsec] To UDP encapsulate or not 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 Herbert, I guess we agree on a couple of aspects, namely * middleboxes can do all sorts of funny things and there is very little one can do about it. In http://tools.ietf.org/html/draft-rosenberg-internet-waist-hourglass-00 Jonathan argues that the new waist of the Internet hourglass is based on running everything over TCP and UDP. Some folks even claim that the new waist is essentially HTTP/HTTPS. Hence, many applications today run over HTTP and some Ipsec implementations even allow tunneling over HTTP in the worst case if everything else fails. * capability negotation is required to avoid using UDP encapsualtion whereas the other side does not support it. * detection is difficult to accomplish (and at least expensive). In the original version of STUN folks tried to build-in a detection functionality regarding the NAT type. This was later removed. While it is possible to detect some types of NATs quite reliablely it is still costly to perform the test exchanges -- more so in an mobile environment. For firewalls the detection is more complex as the middlebox does not modify the packet itself and hence the presence of dropped packet is the only indication the two ends have. It could, however, be packet loss for all sorts of reasons, including congestion. Ciao Hannes >HI Hannes: > >On Sat, Dec 20, 2008 at 05:15:22PM +0200, Hannes Tschofenig wrote: >> >> I believe that this is a very useful statement given that there are >> many NATs and firewalls out there and you never know whether >you run into one. >> >> Having the server to implement UDP encapsulation and to be able to >> deal with UDP encapsulated packets (regardless whether a >NAT/firewall >> was previously detected or not) is pretty useful. >> >> Are you worried about the increased packet size? > >No I'm not so worried about the packet size myself (thoughs >others may). I'm worried about the potential to create >blackholes should some implementations choose to use UDP >encapsulation and others choose not to. Even if both sides >are prepared to accept both packets with and without >encapsulation, the presence of stateful firewalls in the >middle can kill the connection if their choices do not match. > >So if we deem that UDP encapsulation's usefulness outweighs >its overheads, and we're not prepared to let it be negotiated, >then we should require it instead of leaving it up to the >implementation (in the case where NAT is not detected). > >Cheers, >-- >Visit Openswan at http://www.openswan.org/ >Email: Herbert Xu ~{PmV>HI~} >Home Page: http://gondor.apana.org.au/~herbert/ >PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 22 00:11: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 5F51D3A67F4; Mon, 22 Dec 2008 00:11:23 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FF083A67F4 for ; Mon, 22 Dec 2008 00:11:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 ojOLOu19Iiwh for ; Mon, 22 Dec 2008 00:11:22 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by core3.amsl.com (Postfix) with ESMTP id BECF93A6774 for ; Mon, 22 Dec 2008 00:11:21 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id mBM8BBgZ014405 for ; Mon, 22 Dec 2008 17:11:11 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id mBM8BB6x005977 for ipsec@ietf.org; Mon, 22 Dec 2008 17:11:11 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id TAA05973; Mon, 22 Dec 2008 17:11:11 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id mBM8BAR6026130 for ; Mon, 22 Dec 2008 17:11:10 +0900 (JST) Received: by toshiba.co.jp id mBM8B708003120; Mon, 22 Dec 2008 17:11:07 +0900 (JST) To: ipsec@ietf.org In-reply-to: <18763.30257.787031.679868@fireball.kivinen.iki.fi> References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> <18763.30257.787031.679868@fireball.kivinen.iki.fi> Comments: In-reply-to Tero Kivinen message dated "Fri, 19 Dec 2008 12:23:45 +0200." Date: Mon, 22 Dec 2008 17:11:07 +0900 Message-Id: <200812220811.mBM8B708003120@toshiba.co.jp> From: atsushi.fukumoto@toshiba.co.jp Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH 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 Tero Kivinen wrote: > {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange > fails for some reason, the IKE SA is still created as usual. The > list of responses in the IKE_AUTH exchange that do not prevent an IKE > SA from being set up include at least the following: I was wondering what the "at least" here means. Does that mean I can include other values in specific implementation on a whim? FUKUMOTO Atsushi atsushi.fukumoto@toshiba.co.jp _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 22 00:25:58 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 811833A683E; Mon, 22 Dec 2008 00:25:58 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1EF33A683E for ; Mon, 22 Dec 2008 00:25:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2cjeoFG13Xg for ; Mon, 22 Dec 2008 00:25:55 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8F6DE3A6828 for ; Mon, 22 Dec 2008 00:25:55 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id B718729C004; Mon, 22 Dec 2008 10:25:42 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8AA9129C003; Mon, 22 Dec 2008 10:25:41 +0200 (IST) X-CheckPoint: {494F4D9F-10000-88241DC2-7B6} Received: from avi-pc.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBM8PffE025148; Mon, 22 Dec 2008 10:25:41 +0200 (IST) Message-Id: <004B1DB4-FA60-4504-B1FB-8E64ABDD9BF0@checkpoint.com> From: Yoav Nir To: atsushi.fukumoto@toshiba.co.jp In-Reply-To: <200812220811.mBM8B708003120@toshiba.co.jp> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 22 Dec 2008 10:25:40 +0200 References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> <18763.30257.787031.679868@fireball.kivinen.iki.fi> <200812220811.mBM8B708003120@toshiba.co.jp> X-Mailer: Apple Mail (2.930.3) Cc: ipsec@ietf.org Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Dec 22, 2008, at 10:11 AM, atsushi.fukumoto@toshiba.co.jp wrote: > Tero Kivinen wrote: >> {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH >> exchange >> fails for some reason, the IKE SA is still created as usual. The >> list of responses in the IKE_AUTH exchange that do not prevent an >> IKE >> SA from being set up include at least the following: > > I was wondering what the "at least" here means. Does that mean I can > include other values in specific implementation on a whim? > > > FUKUMOTO Atsushi > atsushi.fukumoto@toshiba.co.jp "at least" here is in the sense of "including, but not limited to". If we forgot some error notification (such as NO_ADDITIONAL_SAS) it does not mean that the IKE SA is failed. Any error notification that relates to the child SA or to the configuration payload does not automatically fail the IKE SA. Certainly the initiator may decide that an IKE SA needs to be closed following a NO_ADDITIONAL_SAS or a FAILED_CP_REQUIRED, but in that case, the initiator needs to send a DELETE in a separate INFORMATIONAL, otherwise the IKE SA is still valid. Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 22 04:37: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 EC59B3A6916; Mon, 22 Dec 2008 04:37:08 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7BD3A6916 for ; Mon, 22 Dec 2008 04:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 tftJIfXiqrqe for ; Mon, 22 Dec 2008 04:37:06 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A49AF3A687F for ; Mon, 22 Dec 2008 04:37:04 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBMCafQ8026047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 14:36:41 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBMCadrC001345; Mon, 22 Dec 2008 14:36:39 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18767.35287.598842.163365@fireball.kivinen.iki.fi> Date: Mon, 22 Dec 2008 14:36:39 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D98F1@il-ex01.ad.checkpoint.com> References: <18763.31814.743812.266472@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D97D3@il-ex01.ad.checkpoint.com> <18766.14070.413252.726605@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D98F1@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Redirect draft and REDIRECT_ACK notify X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yaron Sheffer writes: > The scenario I have in mind is planned maintenance, where one cluster member > redirects all traffic to the other member. I think this situation is in > general not as complicated as in MOBIKE, but I may be missing something. True, but doing it so that you just turn the traffic to go to the another member first, and allow it create new IKE/IPsec SAs up first, and when that is done, the old SAs are not used anymore so you can bring them down (or the whole GW). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 22 04:48:55 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEE453A687B; Mon, 22 Dec 2008 04:48:54 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69C073A692E for ; Mon, 22 Dec 2008 04:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RIEP2kJl5Oej for ; Mon, 22 Dec 2008 04:48:52 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 578CD3A687B for ; Mon, 22 Dec 2008 04:48:52 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBMCmgKW001929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 14:48:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBMCmfs1014277; Mon, 22 Dec 2008 14:48:41 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18767.36009.213150.394719@fireball.kivinen.iki.fi> Date: Mon, 22 Dec 2008 14:48:41 +0200 From: Tero Kivinen To: atsushi.fukumoto@toshiba.co.jp In-Reply-To: <200812220811.mBM8B708003120@toshiba.co.jp> References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> <18763.30257.787031.679868@fireball.kivinen.iki.fi> <200812220811.mBM8B708003120@toshiba.co.jp> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 8 min Cc: ipsec@ietf.org Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH 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 atsushi.fukumoto@toshiba.co.jp writes: > Tero Kivinen wrote: > > {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange > > fails for some reason, the IKE SA is still created as usual. The > > list of responses in the IKE_AUTH exchange that do not prevent an IKE > > SA from being set up include at least the following: > > I was wondering what the "at least" here means. Does that mean I can > include other values in specific implementation on a whim? Yes and no... I think the list tries to include error messages defined in the IKEv2 document which could be used to indicate error in Child SA, but other documents might define new errors and some of those might also be such errors which only affect the Child SA creation, and those should not cause the IKE SA creation to fail. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 22 05:03: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 144793A6887; Mon, 22 Dec 2008 05:03:56 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F258B3A6887 for ; Mon, 22 Dec 2008 05:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIzFBx-vpdHz for ; Mon, 22 Dec 2008 05:03:54 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 23BD63A6848 for ; Mon, 22 Dec 2008 05:03:52 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBMD2LiO025340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 15:02:21 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBMD2KNh010690; Mon, 22 Dec 2008 15:02:20 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18767.36828.648842.596858@fireball.kivinen.iki.fi> Date: Mon, 22 Dec 2008 15:02:20 +0200 From: Tero Kivinen To: Herbert Xu In-Reply-To: <20081218215625.GA1070@gondor.apana.org.au> References: <20081218215625.GA1070@gondor.apana.org.au> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 12 min Cc: ipsec@ietf.org Subject: [IPsec] To UDP encapsulate or not 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 Herbert Xu writes: > Hi: > > The current draft has added the statement: > > o Implementations MUST process received UDP-encapsulated ESP > packets even when no NAT was detected. > > This has created implementation ambiguity which did not exist > before. Back in IKEv1, NAT-T was a mess but we did have a way > to negotiate whether UDP encapsulation should be used on ESP > packets or not. I did like the IKEv1 way to negotiate the UDP encapsulation separately, but that was removed in the IKEv2. > With the newly added statement, implementations now face a dilemma. > As it is now acceptable for the peer to send UDP encapsulated > packets in all cases, what should we do when sending data back? In normal case you never should not get any UDP-encapsulated packet from the complient implementation of IKEv2 (without MOBIKE) unless there is NAT detected. With MOBIKE you MUST always be able to process UDP-encapsulated ESP packets regardless whether there is NAT or not on the path (this is required for the MOBIKE to work, as during transition from NATed address to non-NATed address and back, you might get some packets UDP encapsulated even when there is no longer NAT on the currently selected path, or other way around. > If we choose to stick with unencapsulated ESP, then due to the > presence of firewalls (which unlike NAT devices cannot be easily > detected), this may never make it back to the peer. In MOBIKE you always make your own selection whether to enable UDP encapsulation or not based on whether there is NAT between or not, i.e. even when other end is sending you UDP encapsulated packets you will send him back normal ESP if you do not see NAT there. With MOBIKE after the address update signaling is done and other end also knows there is no more NAT there, he should also drop the UDP encapsulation. With base IKEv2 this situation should not really come up, as both ends enable NAT-T based on the same rules, so both ends always enable it or disable it. > So it would seem that the only safe option would in fact be to > send UDP encapsulated traffic. But that's exactly what people > were trying to avoid due to the associated protocol overheads. That would offer new attack, where attacker can send one UDP encapsulated packet (i.e. take ESP packet UDP encapsulte it, and send it to other end) and it will cause the receiving end to switch to UDP encapsulating packets too, which will then reach other end which will cause it to start send UDP encapsulating packets too. I.e the only workable solution is that you do not copy the encapsulation selected by other end, but select it based on your local policy. > Therefore I propose that the above statement be removed. I think we can also drop it to SHOULD or MAY if needed, but I just do not want to put it MUST NOT as that would create unnecessary difference between IKEv2 with MOBIKE and without MOBIKE. I.e. I at least want to have implementations who can always decapsulate UDP encapsulated packets and process the IPsec packets inside regardless whether there is NAT detected or MOBIKE support enabled. I also agree that creating black hole for return packets because they do not use same encapsulation is bad, but I also do not think we can copy the encapsulation as it offers too easy way to attack then. > If a peer really wanted to use UDP encapsulation, it could easily > spoof the NAT detection payloads. If you don't like that, then > we could also add explicit negotiation of UDP encapsulation just > as the original NAT-T scheme did. That I agree also, i.e. if one end wants to enable UDP encapsulation even without NATs present on the path, he can always spoof the NAT detection payloads. On the other hand the NAT-T in IKEv2 also has the problems with the transport mode and the traffic selectors used there, and especially in case both ends are behind NAT. We need to fix those things too... -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 22 05:23:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11CF13A683A; Mon, 22 Dec 2008 05:23:17 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E340D3A683A for ; Mon, 22 Dec 2008 05:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 JsUWMX1TAuR2 for ; Mon, 22 Dec 2008 05:23:15 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 68AD53A6829 for ; Mon, 22 Dec 2008 05:23:14 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBMDMqtV006018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Dec 2008 15:22:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBMDMpGd005621; Mon, 22 Dec 2008 15:22:51 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18767.38059.838277.351165@fireball.kivinen.iki.fi> Date: Mon, 22 Dec 2008 15:22:51 +0200 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D98CC@il-ex01.ad.checkpoint.com> References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> <18763.30257.787031.679868@fireball.kivinen.iki.fi> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D8BB9D98CC@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 20 min X-Total-Time: 19 min Cc: "ipsec@ietf.org" , Vijay Devarapalli Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH 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 writes: > Now the real issue: I suggest that we reconsider the solution we're > proposing here. When a client receives a NO_ADDITIONAL_SAS notify, it is > left with an IKE SA which is basically useless. So the client will naturally > fail the entire connection attempt. With the current proposal we are asking > the client to *guess* that the gateway wants to redirect it somewhere else, > and to wait (for an indefinite time) for that redirect notification to > arrive. If the Redirect never arrives, we just have a useless timeout. My proposal does not want client to guess what gateway wanted, it wants client to wait for gateway to tell him what to do. Lets take another example which is not at all related to the redirect draft but where NO_ADDITIONAL_SAS could be useful. We have SGW which has limited number of hardware Child SA contexts, but the actual IKE SA processing is done on the software so it can still allow IKE SA exchanges even when it is out of the Child SA contexts. Now when the SGW runs out of Child SA contexts there are few things it can do to new clients trying to connect: 1) It can drop all new IKE_SA_INIT requests, which for client looks like the server has crashed/dropped out from the net. The client will try for few minutes retrying the IKE_SA_INIT messages, and then fail the exchange, and then most likely the next triggering packet will restart the process, i.e. client starts to create new IKE_SA and starts sending IKE_SA_INIT requests again. This means client is constantly sending requests to server, and server will drop them. Client also most likely will do new Diffie-Hellman for every single connection retry, unless it is smart enough to reuse the Diffie-Hellman from the previous try. 2) Server will reply to the IKE_SA_INIT, but will return AUTHENTICATION_FAILURE or other similar fatal IKE_SA error to the client. Client will delete the IKE SA when getting that fatal error, and then next trigering packet will again start the process again. In this case both client and server will do Diffie-Hellman for each retry, and client will also do the authentication calculations (signature etc). 3) Server will reply to the IKE_SA_INIT and IKE_AUTH, but instead of creating child sa (which it cannot as it is out of hardware contexts), it returns some other non-fatal error than NO_ADDITIONAL_SAS. The client will fail the Child SA creation, but again most likely the next triggering packet will cause client to retrigger the creation of Child SA, so it will try it again, and it will again be failed. This might also result the user seeing misleading error messages like NO_PROPOSAL_CHOSEN or TS_UNACCEPTABLE even when there is nothing wrong with the client's policy. If the client is really smart it can mark the SPD entry which triggered the negotiation as broken, and will not trigger again for that for some time, but other SPD entries will still cause more triggers. 4) Server will reply to the IKE_SA_INIT, and IKE_AUTH, but return NO_ADDITIONAL_SAS to the client for the Child SA creation. Now the client will know that there is nothing wrong with his policy, and there is no point of retrying any Child SA creations, as the server does not allow new Child SAs to be created now. Client will wait until server indicates the situation has been corrected. Server can indicate this situation in two ways, either it can delete the IKE SA, which will cause the client to retry the IKE SA creation again when next triggering packet comes, or it can simply remember what kind of IPsec SA client was trying to create and do create child SA himself when he has enough resources for it (this option would save the extra Diffie-Hellman calculations and authentication calculates related to the IKE SA creation, but requires more code from the client and server end, thus might not work with all clients). I.e the NO_ADDITIONAL_SAS during IKE_AUTH will cause client to mark the IKE SA to be up and working, but mark it also so that any child SA creation will not get triggered for that specific IKE SA. I.e. it will put the client on hold, waiting for server to tell when to go ahead again. > In other words, I propose to go back to Fan's proposal of an explicit > Redirect notify in IKE_AUTH, so that the client knows for sure what type of > failure it is seeing. I still do not want to add that REDIRECT notify to the most complicated state machine state we have. Also adding REDIRECT there would mean that REDIRECT is both status and error type of notify message. I.e. it is status type sent during INFORMATIONAL exchange, but when sent during IKE_AUTH it is also error type as it causes the Child SA creation to fail. That makes the REDIRECT notify bit confusing. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 22 11:17:21 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011B33A6A84; Mon, 22 Dec 2008 11:17:21 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E01113A6A84 for ; Mon, 22 Dec 2008 11:17:19 -0800 (PST) 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 yxHPy+M9wZSO for ; Mon, 22 Dec 2008 11:17:18 -0800 (PST) Received: from omzesmtp01a.verizonbusiness.com (omzesmtp01a.verizonbusiness.com [199.249.25.195]) by core3.amsl.com (Postfix) with ESMTP id 154A13A696C for ; Mon, 22 Dec 2008 11:17:18 -0800 (PST) Received: from dgismtp06.wcomnet.com ([166.38.58.89]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KCA00I3WLKKTW00@firewall.verizonbusiness.com> for ipsec@ietf.org; Mon, 22 Dec 2008 19:17:08 +0000 (GMT) Received: from dgismtp06.wcomnet.com ([127.0.0.1]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0KCA00EHLLKKYJ@dgismtp06.mcilink.com> for ipsec@ietf.org; Mon, 22 Dec 2008 19:17:08 +0000 (GMT) Received: from ASHSRV142.mcilink.com ([153.39.68.168]) by dgismtp06.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0KCA00E49LKHZQ@dgismtp06.mcilink.com> for ipsec@ietf.org; Mon, 22 Dec 2008 19:17:07 +0000 (GMT) Received: from ASHEVS011.mcilink.com ([153.39.69.138]) by ASHSRV142.mcilink.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Dec 2008 19:16:32 +0000 Date: Mon, 22 Dec 2008 19:16:30 +0000 From: "Snyder, Guy" To: ipsec@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Thread-topic: IKEv2 Bakeoff - March/April 2009 Thread-index: Aclkacu2L7CO4qIWSlO71PxxmqmPLg== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 22 Dec 2008 19:16:32.0103 (UTC) FILETIME=[CC705F70:01C96469] Subject: [IPsec] IKEv2 Bakeoff - March/April 2009 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="===============0409635076==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0409635076== Content-type: multipart/alternative; boundary="----_=_NextPart_001_01C96469.CC221A65" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C96469.CC221A65 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I have been received a couple requests for another bakeoff in the beginning of next year. Once again these events are only feasible if there are ample participants. Tests would be similar to those conducted at the previous bakeoff. These included IPv4, IPv6 and MOBIKE. Your suggestions are always welcome to additions/changes to the suggested tests. Also, the date has not been set for this event, so any suggestions are welcome. =20 The bakeoff will be conducted in the San Jose, CA area. If you are interested in participating please contact me with your level of interest and any suggestions for the agenda/tests. Also, we are always open to vendors in the area that would be willing to host the event. This reduces the cost to all participants. Thank you for your prompt replies. =20 Regards, =20 Guy Snyder VPN Programs Manager ICSA Labs ph: 717.790.8142 fax: 717.790.8170 guy.snyder@icsalabs.com =20 http://www.icsalabs.com =20 =20 ------_=_NextPart_001_01C96469.CC221A65 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I have been received a couple requests for another = bakeoff in the beginning of next year.  Once again these events are only = feasible if there are ample participants.  Tests would be similar to those conducted at the previous bakeoff.  These included IPv4, IPv6 and = MOBIKE.  Your suggestions are always welcome to additions/changes to the = suggested tests. Also, the date has not been set for this event, so any = suggestions are welcome.

 

The bakeoff will be conducted in the San Jose, CA area.  If you are interested in participating please contact me = with your level of interest and any suggestions for the agenda/tests.  Also, = we are always open to vendors in the area that would be willing to host the = event.  This reduces the cost to all participants.  Thank you for = your prompt replies.

 

Regards,

 

Guy Snyder

VPN Programs Manager

ICSA Labs

ph:  717.790.8142

fax: 717.790.8170
guy.snyder@icsalabs.com
http://www.icsalabs.com

 

------_=_NextPart_001_01C96469.CC221A65-- --===============0409635076== 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 --===============0409635076==-- From ipsec-bounces@ietf.org Mon Dec 22 14:35: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 4886B3A6AA0; Mon, 22 Dec 2008 14:35:22 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F433A6AA0 for ; Mon, 22 Dec 2008 14:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.641 X-Spam-Level: X-Spam-Status: No, score=-1.641 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaFUe9vaNZ6K for ; Mon, 22 Dec 2008 14:35:19 -0800 (PST) Received: from arnor.apana.org.au (rhun.apana.org.au [64.62.148.172]) by core3.amsl.com (Postfix) with ESMTP id CFCFB3A6A62 for ; Mon, 22 Dec 2008 14:35:18 -0800 (PST) Received: from gondolin.me.apana.org.au ([192.168.0.6]) by arnor.apana.org.au with esmtp (Exim 4.63 #1 (Debian)) id 1LEtMh-0005KJ-8S; Tue, 23 Dec 2008 09:35:07 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.69) (envelope-from ) id 1LEtMg-0001vM-FU; Tue, 23 Dec 2008 09:35:06 +1100 Date: Tue, 23 Dec 2008 09:35:06 +1100 From: Herbert Xu To: Tero Kivinen Message-ID: <20081222223506.GA7267@gondor.apana.org.au> References: <20081218215625.GA1070@gondor.apana.org.au> <18767.36828.648842.596858@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <18767.36828.648842.596858@fireball.kivinen.iki.fi> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ipsec@ietf.org Subject: Re: [IPsec] To UDP encapsulate or not 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, Dec 22, 2008 at 03:02:20PM +0200, Tero Kivinen wrote: > > With MOBIKE you MUST always be able to process UDP-encapsulated ESP > packets regardless whether there is NAT or not on the path (this is > required for the MOBIKE to work, as during transition from NATed > address to non-NATed address and back, you might get some packets UDP > encapsulated even when there is no longer NAT on the currently > selected path, or other way around. Then I'm afraid that MOBIKE is doomed to fail (unless every MOBIKE implementation always chooses to use UDP encapsulation) because you can't get away from firewalls on today's Internet, especially when you're mobile. > I think we can also drop it to SHOULD or MAY if needed, but I just do > not want to put it MUST NOT as that would create unnecessary > difference between IKEv2 with MOBIKE and without MOBIKE. I see your point of view. But I'm loathe to see IKEv2 degenerate into the same kind of interoperability blackhole that MOBIKE will face just because MOBIKE requires it. There's gotta be a better way out of this. > I also agree that creating black hole for return packets because they > do not use same encapsulation is bad, but I also do not think we can > copy the encapsulation as it offers too easy way to attack then. Actually there is an easy way around this attack. All we need to do is only switch if 1) we've chosen to do unencapsulated ESP and we received a UDP-encapsulated packet, and 2) the incoming packet passes the ESP integrity check and replay checks. This should guarantee that only the genuine peer can trigger this change. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 23 02:37: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 E7D6428C14E; Tue, 23 Dec 2008 02:37:50 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA27328C14E for ; Tue, 23 Dec 2008 02:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 vWsoEkbI-naw for ; Tue, 23 Dec 2008 02:37:48 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 708A228C141 for ; Tue, 23 Dec 2008 02:37:47 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBNAbSPi001897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Dec 2008 12:37:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBNAbRrY023727; Tue, 23 Dec 2008 12:37:27 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18768.48999.480981.798652@fireball.kivinen.iki.fi> Date: Tue, 23 Dec 2008 12:37:27 +0200 From: Tero Kivinen To: Herbert Xu In-Reply-To: <20081222223506.GA7267@gondor.apana.org.au> References: <20081218215625.GA1070@gondor.apana.org.au> <18767.36828.648842.596858@fireball.kivinen.iki.fi> <20081222223506.GA7267@gondor.apana.org.au> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 17 min Cc: ipsec@ietf.org Subject: Re: [IPsec] To UDP encapsulate or not 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 Herbert Xu writes: > On Mon, Dec 22, 2008 at 03:02:20PM +0200, Tero Kivinen wrote: > > > > With MOBIKE you MUST always be able to process UDP-encapsulated ESP > > packets regardless whether there is NAT or not on the path (this is > > required for the MOBIKE to work, as during transition from NATed > > address to non-NATed address and back, you might get some packets UDP > > encapsulated even when there is no longer NAT on the currently > > selected path, or other way around. > > Then I'm afraid that MOBIKE is doomed to fail (unless every MOBIKE > implementation always chooses to use UDP encapsulation) because > you can't get away from firewalls on today's Internet, especially > when you're mobile. I do not agree you on that, and I assume you do not agree me either as my emails to you directly do get blacklisted by your mail server... (while talking to rhun.apana.org.au.: >>> DATA <<< 451-sender IP address 83.145.195.1 is locally blacklisted here. If you think <<< 451 this is wrong, please call...) In MOBIKE this is mandatory as when we are switching addresses where one address is behind NAT and another is not, there might be situations during the transition, where the hosts do not agree which address to use, thus other end uses address which do have NAT on the path (and uses UDP encapsulation), and other end uses address pair which do have NAT (and do not use UDP encapsulation). Immediately when they again agree on using same addresses, and both end know whether there is NAT or not, they switch to use same encoding, i.e. UDP encapsulation if NAT was detected, and normal ESP if no NAT was detected. MOBIKE implementations will not use UDP encapsulation unless there is NAT detected on the path they have selected (just like IKEv2). The difference there is during address pair transition the peers might have different address pairs in use. > > I think we can also drop it to SHOULD or MAY if needed, but I just do > > not want to put it MUST NOT as that would create unnecessary > > difference between IKEv2 with MOBIKE and without MOBIKE. > > I see your point of view. But I'm loathe to see IKEv2 degenerate > into the same kind of interoperability blackhole that MOBIKE will > face just because MOBIKE requires it. There's gotta be a better > way out of this. I do not really see how the ability to process INCOMING packets regardless of the encoding generates interoperability blackhole. It can convert two way blackhole to one way blackhole, but if there is firewall between which blocks all ESP packets the (but does not NAT them) that will cause connection to fail between the peers always. If one end decides to use UDP encapsulation to get through firewall, that will not still make the TCP or any other upper level protocol to work over the link. If one end wants to get past that kind of firewall, it needs to fake the NAT on the path to get both ends using UDP encapsulation. > > I also agree that creating black hole for return packets because they > > do not use same encapsulation is bad, but I also do not think we can > > copy the encapsulation as it offers too easy way to attack then. > > Actually there is an easy way around this attack. All we need > to do is only switch if > > 1) we've chosen to do unencapsulated ESP and we received a UDP-encapsulated > packet, and > > 2) the incoming packet passes the ESP integrity check and replay checks. > > This should guarantee that only the genuine peer can trigger this > change. Attacker can still trigger that, as the ESP integrity check and replay checks are not affected by the fact that the packet is UDP encapsulated. I.e. attacker can take the normal ESP packet, wrap it up to UDP encapsulation and send it to the destination, and it will pass the ESP integrity check and if that packet comes in before the original packet it will also pass the replay checks (or if we can cause the original packet to be dropped). I still don't really know what is your proposed solution? In my proposal I do not change sending part at all, i.e. sending will use exactly one encapsulation which is based on whether the NAT was detected on the path or not. Only thing that is changed is that implementations MAY/SHOULD/MUST accept incoming packets regardless whether they have UDP encapsulation or not (i.e. if the packets manageded to reach you and you are able to process them, then process them and don't drop them just because they didn't have same encapsulation which you are using when sending packets out). -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 23 03:05:29 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E3428C157; Tue, 23 Dec 2008 03:05:29 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B9E28C157 for ; Tue, 23 Dec 2008 03:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.705 X-Spam-Level: X-Spam-Status: No, score=-1.705 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhhbyyMDT1eU for ; Tue, 23 Dec 2008 03:05:27 -0800 (PST) Received: from arnor.apana.org.au (rhun.apana.org.au [64.62.148.172]) by core3.amsl.com (Postfix) with ESMTP id 6783C28C156 for ; Tue, 23 Dec 2008 03:05:27 -0800 (PST) Received: from gondolin.me.apana.org.au ([192.168.0.6]) by arnor.apana.org.au with esmtp (Exim 4.63 #1 (Debian)) id 1LF54e-0001UX-AQ; Tue, 23 Dec 2008 22:05:16 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.69) (envelope-from ) id 1LF54b-00039o-7q; Tue, 23 Dec 2008 22:05:13 +1100 Date: Tue, 23 Dec 2008 22:05:12 +1100 From: Herbert Xu To: Tero Kivinen Message-ID: <20081223110512.GA12092@gondor.apana.org.au> References: <20081218215625.GA1070@gondor.apana.org.au> <18767.36828.648842.596858@fireball.kivinen.iki.fi> <20081222223506.GA7267@gondor.apana.org.au> <18768.48999.480981.798652@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <18768.48999.480981.798652@fireball.kivinen.iki.fi> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ipsec@ietf.org Subject: Re: [IPsec] To UDP encapsulate or not 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, Dec 23, 2008 at 12:37:27PM +0200, Tero Kivinen wrote: > > Attacker can still trigger that, as the ESP integrity check and replay > checks are not affected by the fact that the packet is UDP > encapsulated. I.e. attacker can take the normal ESP packet, wrap it up > to UDP encapsulation and send it to the destination, and it will pass > the ESP integrity check and if that packet comes in before the > original packet it will also pass the replay checks (or if we can > cause the original packet to be dropped). You're right the only way to do this sanely is to negotiate it in IKE. > I still don't really know what is your proposed solution? My proposal is to get rid of this ambiguity where the other side is allowed to use either UDP encapsulation or without. We can achieve this by choosing one of these two options: 1) Require either UDP or no UDP based on NAT. 2) Negotiate UDP encapsulation explicitly in IKE. > In my proposal I do not change sending part at all, i.e. sending will > use exactly one encapsulation which is based on whether the NAT was > detected on the path or not. Only thing that is changed is that > implementations MAY/SHOULD/MUST accept incoming packets regardless > whether they have UDP encapsulation or not (i.e. if the packets > manageded to reach you and you are able to process them, then process > them and don't drop them just because they didn't have same > encapsulation which you are using when sending packets out). The problem occurs when a MOBIKE client sits behind a firewall that 1) Allows all outbound connections; 2) Only allows inbound traffic that's part of an existing connection. When that client tries to send out UDP encapsulated traffic and the remote server replies with ESP traffic because there is no NAT, you have a blackhole. This is a pretty standard firewall configuration so the only thing that's keeping MOBIKE working at all is NAT. As soon as you remove the NAT while keeping the firewall, the whole thing falls apart. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kazuyauwakacanisminor@ameba.jp Tue Dec 23 07:54:10 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4D543A69F2 for ; Tue, 23 Dec 2008 07:54:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -25.884 X-Spam-Level: X-Spam-Status: No, score=-25.884 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKNX50rqmsPQ for ; Tue, 23 Dec 2008 07:54:10 -0800 (PST) Received: from 173-20-244-104.client.mchsi.com (173-20-244-104.client.mchsi.com [173.20.244.104]) by core3.amsl.com (Postfix) with SMTP id 0DEEE3A68EF for ; Tue, 23 Dec 2008 07:54:08 -0800 (PST) To: Subject: Your girlfriend seeks for you From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081223155409.0DEEE3A68EF@core3.amsl.com> Date: Tue, 23 Dec 2008 07:54:08 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mez@afip.gov.ar Tue Dec 23 14:08:22 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7284028C180 for ; Tue, 23 Dec 2008 14:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -36.616 X-Spam-Level: X-Spam-Status: No, score=-36.616 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_DIALIN=3.384, HELO_EQ_DIP_DIALIN=1.573, HOST_EQ_DIP_TDIAL=2.144, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3n+G1GL9La2 for ; Tue, 23 Dec 2008 14:08:22 -0800 (PST) Received: from pD95649D3.dip.t-dialin.net (pD95649D3.dip.t-dialin.net [217.86.73.211]) by core3.amsl.com (Postfix) with SMTP id 1414728C183 for ; Tue, 23 Dec 2008 14:08:20 -0800 (PST) To: Subject: Can't you answer the call? From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081223220821.1414728C183@core3.amsl.com> Date: Tue, 23 Dec 2008 14:08:20 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From ipsec-bounces@ietf.org Tue Dec 23 20:27: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 1DEA33A6B19; Tue, 23 Dec 2008 20:27:45 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B033A6AF6 for ; Tue, 23 Dec 2008 20:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, 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 Fk7JyCAI5Kkn for ; Tue, 23 Dec 2008 20:27:43 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by core3.amsl.com (Postfix) with ESMTP id 16AF33A6782 for ; Tue, 23 Dec 2008 20:27:42 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id mBO4RWxi002235 for ; Wed, 24 Dec 2008 13:27:32 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id mBO4RWl2009286 for ipsec@ietf.org; Wed, 24 Dec 2008 13:27:32 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id PAA09285; Wed, 24 Dec 2008 13:27:32 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id mBO4RVHg026508 for ; Wed, 24 Dec 2008 13:27:31 +0900 (JST) Received: by toshiba.co.jp id mBO4RVEA002790; Wed, 24 Dec 2008 13:27:31 +0900 (JST) To: Yoav Nir In-reply-to: <004B1DB4-FA60-4504-B1FB-8E64ABDD9BF0@checkpoint.com> References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> <18763.30257.787031.679868@fireball.kivinen.iki.fi> <200812220811.mBM8B708003120@toshiba.co.jp> <004B1DB4-FA60-4504-B1FB-8E64ABDD9BF0@checkpoint.com> Comments: In-reply-to Yoav Nir message dated "Mon, 22 Dec 2008 10:25:40 +0200." Date: Wed, 24 Dec 2008 13:27:30 +0900 Message-Id: <200812240427.mBO4RVEA002790@toshiba.co.jp> From: atsushi.fukumoto@toshiba.co.jp Cc: ipsec@ietf.org Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH 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 Yoav Nir wrote: > "at least" here is in the sense of "including, but not limited to". If > we forgot some error notification (such as NO_ADDITIONAL_SAS) it does > not mean that the IKE SA is failed. > I was under impression that IKE SA implicitly dies upon receiving error notify payload unless it is about child SA. Do you mean that an initiator conformant to ikev2bis should never assume a specific error notify is about child SA or IKE SA, and SHOULD be capable of handling either way? FUKUMOTO Atsushi atsushi.fukumoto@toshiba.co.jp _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 24 01:14: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 A5FD628C1B0; Wed, 24 Dec 2008 01:14:57 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 488BB28C1B0 for ; Wed, 24 Dec 2008 01:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 QqJz3K1WzPXJ for ; Wed, 24 Dec 2008 01:14:55 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 51F7D28C1A9 for ; Wed, 24 Dec 2008 01:14:55 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 578F729C002; Wed, 24 Dec 2008 11:14:45 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 6D69129C001; Wed, 24 Dec 2008 11:14:44 +0200 (IST) X-CheckPoint: {4951FC0B-10002-88241DC2-7B6} Received: from [91.90.139.236] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id mBO9EifE025052; Wed, 24 Dec 2008 11:14:44 +0200 (IST) Message-Id: <59CFAA86-C5EA-4ADE-9937-D0DC97904FBD@checkpoint.com> From: Yoav Nir To: atsushi.fukumoto@toshiba.co.jp In-Reply-To: <200812240427.mBO4RVS6014610@toshiba.co.jp> Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 24 Dec 2008 11:14:43 +0200 References: <18760.62138.517458.691565@fireball.kivinen.iki.fi> <18763.30257.787031.679868@fireball.kivinen.iki.fi> <200812220811.mBM8B708003120@toshiba.co.jp> <004B1DB4-FA60-4504-B1FB-8E64ABDD9BF0@checkpoint.com> <200812240427.mBO4RVS6014610@toshiba.co.jp> X-Mailer: Apple Mail (2.930.3) Cc: ipsec@ietf.org Subject: Re: [IPsec] NO_ADDITIONAL_SAS and IKE_AUTH X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Dec 24, 2008, at 6:27 AM, atsushi.fukumoto@toshiba.co.jp wrote: > Yoav Nir wrote: >> "at least" here is in the sense of "including, but not limited to". >> If >> we forgot some error notification (such as NO_ADDITIONAL_SAS) it does >> not mean that the IKE SA is failed. >> > > I was under impression that IKE SA implicitly dies upon receiving > error notify payload unless it is about child SA. Do you mean that an > initiator conformant to ikev2bis should never assume a specific error > notify is about child SA or IKE SA, and SHOULD be capable of handling > either way? I don't mean that. Errors that relate to the IKE SA delete the IKE SA. Errors that relate to CP or Child SA do not delete the IKE SA. "at least" only says that the list that follows it may not be comprehensive - indeed we forgot the NO_ADDITIONAL_SAS Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From lesley.beardp@ags.gov.au Wed Dec 24 02:05:20 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB78D28C146 for ; Wed, 24 Dec 2008 02:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.015 X-Spam-Level: X-Spam-Status: No, score=-16.015 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_EQ_JP=1.244, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, 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 5ogqxMom2Hct for ; Wed, 24 Dec 2008 02:05:20 -0800 (PST) Received: from alc.co.jp (unknown [87.19.62.125]) by core3.amsl.com (Postfix) with SMTP id 695603A6B64 for ; Wed, 24 Dec 2008 02:05:17 -0800 (PST) To: Subject: Express your masculinity better! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081224100518.695603A6B64@core3.amsl.com> Date: Wed, 24 Dec 2008 02:05:17 -0800 (PST) Let us give you some more male enhancement tips! From lacandidates@24seventalent.com Thu Dec 25 04:09:52 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9781A3A679F for ; Thu, 25 Dec 2008 04:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -27.351 X-Spam-Level: X-Spam-Status: No, score=-27.351 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_RFC_BOGUSMX=1.482, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_WILL_HELP=2.749, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DE=0.35, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mEM2aXEeZBl for ; Thu, 25 Dec 2008 04:09:51 -0800 (PST) Received: from 91-66-120-188-dynip.superkabel.de (91-66-120-188-dynip.superkabel.de [91.66.120.188]) by core3.amsl.com (Postfix) with SMTP id 9D2FE3A63D2 for ; Thu, 25 Dec 2008 04:09:49 -0800 (PST) To: Subject: Some lengthening will help From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081225120950.9D2FE3A63D2@core3.amsl.com> Date: Thu, 25 Dec 2008 04:09:49 -0800 (PST)

If you are unable to see the message below, click here to view.

You will never have to regret about taking this preparation!

PLEASE DO NOT REPLY - This is being sent from an unattended mailbox.

Copyright © 2008 MaxGentleman, Inc. All rights reserved.
5 Trowbridge Drive, Bethel, CT 568794

You have received this message because you
opted in to receives MaxGentleman pecial offers via email.

You can unsubscribe here

 From mnishiki@a-easy.com Fri Dec 26 02:47:58 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D144C3A694D for ; Fri, 26 Dec 2008 02:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.54 X-Spam-Level: X-Spam-Status: No, score=-14.54 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtEpxnkyeFoV for ; Fri, 26 Dec 2008 02:47:58 -0800 (PST) Received: from 201-65-36-208.poolip.RJO.embratel.net.br (201-65-36-208.poolip.RJO.embratel.net.br [201.65.36.208]) by core3.amsl.com (Postfix) with SMTP id 5000B3A6862 for ; Fri, 26 Dec 2008 02:47:55 -0800 (PST) To: Subject: Quality health care at a fraction of the cost From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081226104756.5000B3A6862@core3.amsl.com> Date: Fri, 26 Dec 2008 02:47:55 -0800 (PST)

If you are unable to see the message below, click here to view.

Don't hesitate to order your personal prescriptions here at the most favorable price!

PLEASE DO NOT REPLY - This is being sent from an unattended mailbox.

Copyright © 2008 MaxGentleman, Inc. All rights reserved.
5 Trowbridge Drive, Bethel, CT 564115

You have received this message because you
opted in to receives MaxGentleman pecial offers via email.

You can unsubscribe here

 From luciana.kuzolitz@alcoa.com.br Fri Dec 26 05:20:33 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1DFC3A6988 for ; Fri, 26 Dec 2008 05:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -42.506 X-Spam-Level: X-Spam-Status: No, score=-42.506 tagged_above=-999 required=5 tests=[BAYES_95=3, FH_HOST_EQ_D_D_D_D=0.765, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_NJABL_PROXY=1.643, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3peiL7JPf7qF for ; Fri, 26 Dec 2008 05:20:33 -0800 (PST) Received: from host147.200-43-39.telecom.net.ar (host147.200-43-39.telecom.net.ar [200.43.39.147]) by core3.amsl.com (Postfix) with SMTP id 865103A681D for ; Fri, 26 Dec 2008 05:20:30 -0800 (PST) To: Subject: Returned mail: User unknown From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081226132031.865103A681D@core3.amsl.com> Date: Fri, 26 Dec 2008 05:20:30 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From jramos@algxmail.com Fri Dec 26 19:10:41 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FCBA3A6A43 for ; Fri, 26 Dec 2008 19:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.836 X-Spam-Level: X-Spam-Status: No, score=-17.836 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_12=2.46, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycqzfDfTp-lZ for ; Fri, 26 Dec 2008 19:10:40 -0800 (PST) Received: from c-76-113-24-90.hsd1.nm.comcast.net (c-76-113-24-90.hsd1.nm.comcast.net [76.113.24.90]) by core3.amsl.com (Postfix) with SMTP id 43D5F3A63D3 for ; Fri, 26 Dec 2008 19:10:38 -0800 (PST) To: Subject: Best products from true wellness specialists From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081227031039.43D5F3A63D3@core3.amsl.com> Date: Fri, 26 Dec 2008 19:10:38 -0800 (PST)

If you are unable to see the message below, click here to view.

Get your prescriptions conveniently filled online!

PLEASE DO NOT REPLY - This is being sent from an unattended mailbox.

Copyright © 2008 MaxGentleman, Inc. All rights reserved.
5 Trowbridge Drive, Bethel, CT 416759

You have received this message because you
opted in to receives MaxGentleman pecial offers via email.

You can unsubscribe here

 From lk-qe@amchk.com Sat Dec 27 06:21:04 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 667AC3A67E1 for ; Sat, 27 Dec 2008 06:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -20.587 X-Spam-Level: X-Spam-Status: No, score=-20.587 tagged_above=-999 required=5 tests=[AWL=13.056, BAYES_95=3, FH_RELAY_NODNS=1.451, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJtWq4TDuA4d for ; Sat, 27 Dec 2008 06:21:03 -0800 (PST) Received: from alicorp.com.pe (unknown [190.188.216.143]) by core3.amsl.com (Postfix) with SMTP id AD0883A67D6 for ; Sat, 27 Dec 2008 06:21:02 -0800 (PST) To: Subject: Returned mail: User unknown From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081227142102.AD0883A67D6@core3.amsl.com> Date: Sat, 27 Dec 2008 06:21:02 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From owlbvap@akg.com Sat Dec 27 09:29:29 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C98D3A691D for ; Sat, 27 Dec 2008 09:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.358 X-Spam-Level: X-Spam-Status: No, score=-16.358 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_HCC=4.295, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_MODEMCABLE=0.768, HELO_EQ_PL=1.135, HOST_EQ_MODEMCABLE=1.368, HOST_EQ_PL=1.95, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, TVD_SPACE_RATIO=2.219, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnxzbySbn6lb for ; Sat, 27 Dec 2008 09:29:28 -0800 (PST) Received: from ip-79-175-205-147.cable.smsnet.pl (ip-79-175-205-147.cable.smsnet.pl [79.175.205.147]) by core3.amsl.com (Postfix) with SMTP id 165EC3A67B6 for ; Sat, 27 Dec 2008 09:29:26 -0800 (PST) To: Subject: Undeliverable: Hi From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081227172927.165EC3A67B6@core3.amsl.com> Date: Sat, 27 Dec 2008 09:29:26 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From mail@airi.de Sun Dec 28 02:35:17 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F48C28C1CA for ; Sun, 28 Dec 2008 02:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -28.138 X-Spam-Level: X-Spam-Status: No, score=-28.138 tagged_above=-999 required=5 tests=[BAYES_95=3, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_HOME_NL=3.463, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_RHS_DOB=1.083, 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 OP5WJMjj9fPO for ; Sun, 28 Dec 2008 02:35:16 -0800 (PST) Received: from cm1017875-a.maast1.lb.home.nl (cm1017875-a.maast1.lb.home.nl [84.30.89.227]) by core3.amsl.com (Postfix) with SMTP id 4B6CD28C1C6 for ; Sun, 28 Dec 2008 02:35:11 -0800 (PST) To: Subject: Returned mail: User unknown From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081228103514.4B6CD28C1C6@core3.amsl.com> Date: Sun, 28 Dec 2008 02:35:11 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From jennifer.lodge@amicore.com Mon Dec 29 00:03:45 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6E3B28C24A for ; Mon, 29 Dec 2008 00:03:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.418 X-Spam-Level: X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IN5RSwUgZfD for ; Mon, 29 Dec 2008 00:03:45 -0800 (PST) Received: from airtransat.com (unknown [202.151.184.1]) by core3.amsl.com (Postfix) with SMTP id C95183A67D7 for ; Mon, 29 Dec 2008 00:03:43 -0800 (PST) To: Subject: Make sure it works From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081229080343.C95183A67D7@core3.amsl.com> Date: Mon, 29 Dec 2008 00:03:43 -0800 (PST)


Please do not reply to this email. To contact Armstrong Shank Advertising, please visit us

This email message was sent to . If you do not wish to receive further communications from Armstrong Shank Advertising, click here to unsubscribe.

If you've experience any difficulty in being removed from a Armstrong Shank Advertising email list, click here for personalized help.

Copyright © 2008 Armstrong Shank Advertising, Inc. All rights reserved.
7450 S Seneca, Haysville, KS 67060

From ipsec-bounces@ietf.org Mon Dec 29 04:49: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 381E13A6874; Mon, 29 Dec 2008 04:49:07 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3883F3A6972 for ; Mon, 29 Dec 2008 04:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxnERcnolmci for ; Mon, 29 Dec 2008 04:49:04 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3133A6874 for ; Mon, 29 Dec 2008 04:49:03 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id mBTCmd3D011850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Dec 2008 14:48:39 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id mBTCmV9g026008; Mon, 29 Dec 2008 14:48:31 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18776.50975.768573.828996@fireball.kivinen.iki.fi> Date: Mon, 29 Dec 2008 14:48:31 +0200 From: Tero Kivinen To: Herbert Xu In-Reply-To: <20081223110512.GA12092@gondor.apana.org.au> References: <20081218215625.GA1070@gondor.apana.org.au> <18767.36828.648842.596858@fireball.kivinen.iki.fi> <20081222223506.GA7267@gondor.apana.org.au> <18768.48999.480981.798652@fireball.kivinen.iki.fi> <20081223110512.GA12092@gondor.apana.org.au> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 92 min X-Total-Time: 111 min Cc: ipsec@ietf.org Subject: Re: [IPsec] To UDP encapsulate or not 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 Herbert Xu writes: > On Tue, Dec 23, 2008 at 12:37:27PM +0200, Tero Kivinen wrote: > > > > Attacker can still trigger that, as the ESP integrity check and replay > > checks are not affected by the fact that the packet is UDP > > encapsulated. I.e. attacker can take the normal ESP packet, wrap it up > > to UDP encapsulation and send it to the destination, and it will pass > > the ESP integrity check and if that packet comes in before the > > original packet it will also pass the replay checks (or if we can > > cause the original packet to be dropped). > > You're right the only way to do this sanely is to negotiate it > in IKE. > > > I still don't really know what is your proposed solution? > > My proposal is to get rid of this ambiguity where the other side > is allowed to use either UDP encapsulation or without. But the question was not about what other end is allowed to send, it was what other end should be able to accept. > We can achieve this by choosing one of these two options: > > 1) Require either UDP or no UDP based on NAT. > 2) Negotiate UDP encapsulation explicitly in IKE. The RFC4306 text says already following: 1) If NAT is detected MUST enable UDP encapsulation (this also implictly means that MUST NOT send without UDP encapsulation if NAT was detected) The ikev2bis added following: 2) Even if NAT is not detected MUST be able to process received UDP-encapsulated ESP packets. The text which is not in the either document is what you are asking, i.e: 3) Is sender allowed to enable UDP-encapsulation even if no NAT is detected. The answers to 2 and 3 can be different, and from 3 we can also derive one more question: 4) If no NAT was detected does receiving UDP encapsulated packets cause any effect on the receiving side. Actually my original question number 5 to thread for issue #40 was wrong, as it was really the question 3 here, not the case 2, so I myself confused those things too... I.e. we have to separate the sender and receiving side processing. For the sender side we might want to be quite strict what is supposed to be sent, and on the receiving side we might want to be more relaxed what is accepted. This kind of specifications allows making extensions in the future, which can still be backwards compatible with the existing implementations and benefit from new features even with old versions. Lets try this once more (all of these next questions are only relevant if NAT-T is supported, if NAT-T is not supported then neither end can use port 4500 or UDP-encapsulation): (Answers are either from RFC, ikev2bis draft or from me (the ones with question mark)). Q1) Using port 4500: INITIATOR/ RESPONDER/ SENDER RECIPIENT Q1a) Can start MAY? start (1) MUST? accept from port 4500 incoming directly? connections (2) (from #40) Q1b) May/should/must MAY/SHOULD NOT? do (3) MUST? process move to port 4500 requests (4) even when no NAT detected? Q1c) May/should/must MUST MUST move to port 4500 (RFC4306) (RFC4306) if NAT detected? Q2) UDP encapsulation when not floated to port 4500 (i.e. still using port 500, and no NAT detected): INITIATOR/ RESPONDER/ SENDER RECIPIENT Q2a) Can UDP ??? (5) MAY/SHOULD? process encapsulation incoming packets (6) be used? Q3) UDP encapsulation when we have floated to port 4500 but no NAT detected (this assumes Q1b says we are allowed to do it): INITIATOR/ RESPONDER/ SENDER RECIPIENT Q3a) Can UDP SHOULD NOT? (7) MAY/SHOULD/MUST? process encapsulation incoming packets (8) be used? Q3b) Should UDP NO? (9) see above encapsulation be always enabled if using port 4500? Q4) UDP encapsulation when we have floated to port 4500 and NAT was detected: INITIATOR/ RESPONDER/ SENDER RECIPIENT Q3a) UDP MUST enable (10) MUST process encapsulation incoming packets (10) usage? Q3b) Is non UDP MUST NOT send (11) MAY/SHOULD/MUST? encapsulated process incoming packets allowed? packets (12) Notes: (1) RFC4306 2.23 does not really say this but IKEv1 NAT-T (rfc3947) says this, see also (2) (2) RFC4306 2.23 does say MUST listen on port 4500, and nothing forbids other end for starting from 4500, and if responder must listen 4500, and respond to request to there, I guess that means it is MUST. (3) Almost same as (1), but different as in Q1a we do not know whether there is NAT or not, thus we do not really have option to move back to 500 when we notice there is no NAT. Here the question whether we are allowed to move to port 4500 even when no NAT was detected. MOBIKE mandates this. (4) See (3), and (2) but I would read "MUST listen" to so that responder must also process those packets. MOBIKE mandates this. (5) I would say MUST NOT or SHOULD NOT, but nothing in documents say anything about this. (6) I would be liberal and allow it here (i.e. at least MAY, but could also be SHOULD). Ikev2bis says MUST. (7) If no NAT is detected there is no reason to use udp encapsulation, so we should discourage it. We could even say MUST NOT. Note that processing such packets is different question. MOBIKE allows this (i.e. if sender knows or suspects there is NAT it can enable it). (8) Even if we say MUST NOT for the sender part, I think the recipient part should process those packets regardless of encapsulation. This does not mean we need to allow senders to send them now, or that we start sending them in same way we receive then. MOBIKE mandates this. Ikev2bis says MUST. (9) I do not think the UDP encapsulation should be always enabled if using 4500, this is actually same question as Q3a, except than if we answer YES here then we cannot send non UDP encapsulated packets even if NAT was not detected but we moved to port 4500. (10) RFC4306 says we MUST enable UDP encapsulation if NAT is detected. (11) As we MUST enable UDP encapsulation if NAT was detected, that means we MUST NOT send non-udp encapsulation packets if NAT was detected. (12) This is again different question than the sender side. This is close to the (6) or (8). I would say MAY/SHOULD/MUST process, but SHOULD/MUST NOT change its other behavior based on the fact it receives using wrong encapsulation (i.e. it SHOULD/MUST NOT enable his sending side based on what it receives). MOBIKE mandates this. I think my previous summary is still valid: Initiator can float to port 4500, regardless whether there is NAT or not, and he can also do that from the beginning. If NAT-T is supported, all devices MUST be able to receive both UDP encapsulated and non-UDP encapsulated packets at any time, and process them both. Encapsulation of incoming packets do not affect the encapsulation of the sent packets, all devices decide sending format independly. If NAT is detected all devices MUST enable sending UDP encapsulated packets. As all devices must be able to receive and process both formats at any time, the sender can change the encapsulation based on local implementation matters (unless there is NAT detected, in which case they MUST send packets UDP encapsulated). (The first MUST could also be SHOULD or even MAY, especially for IPv6, but on the other hand it might be that IPv6 IPsec implementations do not support NAT-T at all so most likely if you run IKE over IPv6 you do not enable NAT-T support). > The problem occurs when a MOBIKE client sits behind a firewall that > > 1) Allows all outbound connections; > 2) Only allows inbound traffic that's part of an existing connection. > > When that client tries to send out UDP encapsulated traffic and the > remote server replies with ESP traffic because there is no NAT, you > have a blackhole. Complient MOBIKE client would never try to send out UDP encapsulated packets, as there is no NAT there, unless it was before using some other IP address pair which did have NAT. In that case it sends the UDP encapsulated packets through the firewall, and those will get to the other end. The client has already noticed here that the previously used IP-address has disappeared or not working (thats why it moved to use the other address which is behind firewall), and it starts address update procedure. That will send IKE packet to the other end using the firewalled connection. During this process it can still send ESP packets out using previous NAT-T information but using new IP-addresses, just to see if they go through (the other option would be to drop them immediately when it notices the old address disappeared). When the server responds to the address update message, both end notices there is no NAT and at that point both ends will disable UDP encapsulation. Client is also allowed to disable UDP encapsulation immediately when it switches to the new IP-address pair if it "either suspects or knows" that there is or is not NAT between them. I.e. it can for example check if the source address of the new address pair is from private address range, then it can immediately enable UDP encapsulation, or it can see that it is globally routable address, so it might disable the UDP encapsulation in that case. Anyways the half black hole only exists as long as the address update procedure is still running, after it is finished both ends agree whether there is NAT or not between, and enable or disable UDP encapsulation based on that. As it might be bit hard to understand from the text above here is the diagram for the packets when using MOBIKE. The IP_I1 is for example WLAN link using NAT, and that is now in use. Client Server ------ ------ (IP_I1:4500 -> IP_R1:4500) UDP, ESP --> <-- (IP_R1:4500 -> IP_I1:4500) UDP, ESP Client is sending UDP encapsulated traffic to server using IP_I1 and server respondes to same address pair using UDP encapsulation. Now the WLAN link goes down and client detects this. It has another IP-address IP_I2 from fixed lan, and as now that is his only address, and IP_I1 does not work anymore, it decides immediately to move IPsec traffic to using that address, and start MOBIKE address update. (IP_I2:4500 -> IP_R1:4500) UDP, ESP --> As it does not know whether IP_I2 is behind NAT or not, it might guess it is behind NAT, or just keep the old NAT-T setting from the IP_I1 if it does not have any better way to make a guess (i.e. lets assume that neither IP_I1 and IP_I2 are private address space addresses). It sends those packets out just in case they reach the other end, and then starts address update: (IP_I2:4500 -> IP_R1:4500) HDR, SK {N(UPDATE_SA_ADDRESS), N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP)} --> Server replies to this: <-- (IP_R1:4500 -> IP_I2:4500) HDR, SK {N(NAT_DETECTION_SOURCE_IP), N(NAT_DETECTION_DESTINATION_IP)} After the update both ends know there is NO NAT between them, thus both ends disable NAT-T and send plain ESP packetS: (IP_I2 -> IP_R1) ESP --> <-- (IP_R1 -> IP_I2) ESP > This is a pretty standard firewall configuration so the only thing > that's keeping MOBIKE working at all is NAT. As soon as you remove > the NAT while keeping the firewall, the whole thing falls apart. Yes, Standard IPsec (or MOBIKE) does not work through any firewall which is configured to drop all ESP packets, and not do NAT. Clients may have option which allows them to be configured to fake NAT in such environments, to allow enabling UDP encapsulation even when there is no NAT. Even that does not help if firewall is configured to drop all port 500 and 4500 UDP traffic. You can always misconfigure firewall to drop any traffic, but if you want to get IPsec through a firewall you either need to: 1) allow UDP ports 500, 4500, and ESP/AH packets. 2) allow UDP ports 500, 4500 and do NAT. The second configuration is very common for IPv4 firewalls. The first configuration might come common for IPv6 firewalls. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From lir7@agora.pl Mon Dec 29 10:28:26 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB5F43A6C57 for ; Mon, 29 Dec 2008 10:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.455 X-Spam-Level: X-Spam-Status: No, score=-15.455 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, 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 sDMvx1onYdak for ; Mon, 29 Dec 2008 10:28:26 -0800 (PST) Received: from aitlbd.net (unknown [87.126.192.217]) by core3.amsl.com (Postfix) with SMTP id 9ADB83A6C58 for ; Mon, 29 Dec 2008 10:28:23 -0800 (PST) To: Subject: Dare to ask for more! From: MIME-Version: 1.0 Importance: High Content-Type: text/html X-Antivirus: avast! (VPS 080329-0, 29.03.2008), Outbound message X-Antivirus-Status: Clean Message-Id: <20081229182823.9ADB83A6C58@core3.amsl.com> Date: Mon, 29 Dec 2008 10:28:23 -0800 (PST)


Please do not reply to this email. To contact Armstrong Shank Advertising, please visit us

This email message was sent to . If you do not wish to receive further communications from Armstrong Shank Advertising, click here to unsubscribe.

If you've experience any difficulty in being removed from a Armstrong Shank Advertising email list, click here for personalized help.

Copyright © 2008 Armstrong Shank Advertising, Inc. All rights reserved.
7450 S Seneca, Haysville, KS 67060

From jarrettlancasterphil@advantageoffice.net Mon Dec 29 11:09:24 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130DA3A6986 for ; Mon, 29 Dec 2008 11:09:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.18 X-Spam-Level: X-Spam-Status: No, score=-8.18 tagged_above=-999 required=5 tests=[BAYES_99=3.5, DNS_FROM_OPENWHOIS=1.13, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_XBL=3.033, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bWZ-Q134OLb for ; Mon, 29 Dec 2008 11:09:23 -0800 (PST) Received: from bachasg.static.otenet.gr (bachasg.static.otenet.gr [83.235.171.252]) by core3.amsl.com (Postfix) with SMTP id 46A0D3A68F6 for ; Mon, 29 Dec 2008 11:09:18 -0800 (PST) To: Subject: Get armed for a new love battle From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081229190920.46A0D3A68F6@core3.amsl.com> Date: Mon, 29 Dec 2008 11:09:18 -0800 (PST)


Please do not reply to this email. To contact Armstrong Shank Advertising, please visit us

This email message was sent to . If you do not wish to receive further communications from Armstrong Shank Advertising, click here to unsubscribe.

If you've experience any difficulty in being removed from a Armstrong Shank Advertising email list, click here for personalized help.

Copyright © 2008 Armstrong Shank Advertising, Inc. All rights reserved.
7450 S Seneca, Haysville, KS 67060

From nu-lines@ad.wakwak.com Mon Dec 29 12:51:12 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C63E28C297 for ; Mon, 29 Dec 2008 12:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HOST_EQ_STATIC=1.172, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdiUVH9gzq1X for ; Mon, 29 Dec 2008 12:51:11 -0800 (PST) Received: from shpd-78-36-164-209.static.vologda.ru (shpd-78-36-164-209.static.vologda.ru [78.36.164.209]) by core3.amsl.com (Postfix) with SMTP id 6747A28C295 for ; Mon, 29 Dec 2008 12:51:09 -0800 (PST) To: Subject: Get hung like no one else From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081229205110.6747A28C295@core3.amsl.com> Date: Mon, 29 Dec 2008 12:51:09 -0800 (PST)


Please do not reply to this email. To contact Armstrong Shank Advertising, please visit us

This email message was sent to . If you do not wish to receive further communications from Armstrong Shank Advertising, click here to unsubscribe.

If you've experience any difficulty in being removed from a Armstrong Shank Advertising email list, click here for personalized help.

Copyright © 2008 Armstrong Shank Advertising, Inc. All rights reserved.
7450 S Seneca, Haysville, KS 67060

From ipsec-bounces@ietf.org Mon Dec 29 19:07:14 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472A43A6A3B; Mon, 29 Dec 2008 19:07:14 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850ED3A6A39 for ; Mon, 29 Dec 2008 19:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.743 X-Spam-Level: X-Spam-Status: No, score=-1.743 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4gTLZiytMJp for ; Mon, 29 Dec 2008 19:07:10 -0800 (PST) Received: from arnor.apana.org.au (rhun.apana.org.au [64.62.148.172]) by core3.amsl.com (Postfix) with ESMTP id 7619C3A67DD for ; Mon, 29 Dec 2008 19:07:10 -0800 (PST) Received: from gondolin.me.apana.org.au ([192.168.0.6]) by arnor.apana.org.au with esmtp (Exim 4.63 #1 (Debian)) id 1LHUwb-0005BQ-75; Tue, 30 Dec 2008 14:06:57 +1100 Received: from herbert by gondolin.me.apana.org.au with local (Exim 4.69) (envelope-from ) id 1LHUwW-00048S-Pu; Tue, 30 Dec 2008 14:06:52 +1100 Date: Tue, 30 Dec 2008 14:06:52 +1100 From: Herbert Xu To: Tero Kivinen Message-ID: <20081230030652.GA15620@gondor.apana.org.au> References: <20081218215625.GA1070@gondor.apana.org.au> <18767.36828.648842.596858@fireball.kivinen.iki.fi> <20081222223506.GA7267@gondor.apana.org.au> <18768.48999.480981.798652@fireball.kivinen.iki.fi> <20081223110512.GA12092@gondor.apana.org.au> <18776.50975.768573.828996@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <18776.50975.768573.828996@fireball.kivinen.iki.fi> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ipsec@ietf.org Subject: Re: [IPsec] To UDP encapsulate or not 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, Dec 29, 2008 at 02:48:31PM +0200, Tero Kivinen wrote: > > (Answers are either from RFC, ikev2bis draft or from me (the ones with > question mark)). Thanks for the summary! No NAT > INITIATOR/ RESPONDER/ > SENDER RECIPIENT > > Q2a) Can UDP ??? (5) MAY/SHOULD? process > encapsulation incoming packets (6) > be used? > > > Q3) UDP encapsulation when we have floated to port 4500 but no NAT > detected (this assumes Q1b says we are allowed to do it): > > INITIATOR/ RESPONDER/ > SENDER RECIPIENT > > Q3a) Can UDP SHOULD NOT? (7) MAY/SHOULD/MUST? process > encapsulation incoming packets (8) > be used? > > Q3b) Should UDP NO? (9) see above > encapsulation > be always > enabled if > using port 4500? NAT > Q3b) Is non UDP MUST NOT send (11) MAY/SHOULD/MUST? > encapsulated process incoming > packets allowed? packets (12) These cases are the bone of contention. In the absence of explicit negotiation of UDP encapsulation, my preference would be MUST NOT to all of the above (5-9 and 11-12). The reason is that we're making a document that impelmentors will rely on to determine the behaviour of their software. They often don't have the time to fully investigate all the rationale of each individual statement in the RFC. Therefore we should strive to avoid statements which have the potential of creating "compliant" implementations that cannot communicate with each other. As I have explained previously, the status quo would allow two implementations that abide by the current draft documentation but simply cannot communicate successfully when firewalls are present. > > The problem occurs when a MOBIKE client sits behind a firewall that > > > > 1) Allows all outbound connections; > > 2) Only allows inbound traffic that's part of an existing connection. > > > > When that client tries to send out UDP encapsulated traffic and the > > remote server replies with ESP traffic because there is no NAT, you > > have a blackhole. > > Complient MOBIKE client would never try to send out UDP encapsulated > packets, as there is no NAT there, unless it was before using some > other IP address pair which did have NAT. In that case it sends the FWIW the thread that led me here was in fact caused by a MOBIKE implementation which sent UDP encapsulated packets when NAT was not detected. While such an implementation may be non-compliant as far MOBIKE is concerned, it is unfortunately complaint with respect to IPsec per the current draft document. > Anyways the half black hole only exists as long as the address update > procedure is still running, after it is finished both ends agree > whether there is NAT or not between, and enable or disable UDP > encapsulation based on that. Thanks for explaining the rationale for MOBIKE wanting to do this. So essentially this mismatch of UDP encapsulation is allowed in order to have the MOBIKE peers continue communication after an address change and before both ends have agreed on the address change. I have to say that the current solution to this problem is rather poor. On the one hand, it now explicitly allows bogus IPsec implementations which weren't explictly allowed before, and on the other hand, it doesn't solve the MOBIKE problem that well. The target audience of MOBIKE clients are much more likely than the average IPsec peer to be sitting behind a firewall of the kind that I described earlier. As such the address update mechanism as currently documented is going to cause a blackhole during the address change anyway. In other words, allowing UDP encapsulation mismatches have made the IPsec specification worse while it's only making MOBIKE slightly better. > > This is a pretty standard firewall configuration so the only thing > > that's keeping MOBIKE working at all is NAT. As soon as you remove > > the NAT while keeping the firewall, the whole thing falls apart. > > Yes, Standard IPsec (or MOBIKE) does not work through any firewall > which is configured to drop all ESP packets, and not do NAT. No I'm not talking about a firewall which drops all ESP packets, I'm talking about a firewall which only allows inbound ESP packets which are associated with an outbound ESP flow. That is, it only allows inbound ESP (src, dst) if it has seen outobund ESP packets (dst, src). Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nievesl@amebacctv.com Tue Dec 30 01:55:16 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 980633A6781 for ; Tue, 30 Dec 2008 01:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.636 X-Spam-Level: X-Spam-Status: No, score=-4.636 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_NONE=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rw0QswLt5PEU for ; Tue, 30 Dec 2008 01:55:15 -0800 (PST) Received: from acmebrick.com (unknown [122.164.36.233]) by core3.amsl.com (Postfix) with SMTP id 4F5FB3A63D2 for ; Tue, 30 Dec 2008 01:55:13 -0800 (PST) To: Subject: Make your buddies envy From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081230095514.4F5FB3A63D2@core3.amsl.com> Date: Tue, 30 Dec 2008 01:55:13 -0800 (PST)


Please do not reply to this email. To contact Armstrong Shank Advertising, please visit us

This email message was sent to . If you do not wish to receive further communications from Armstrong Shank Advertising, click here to unsubscribe.

If you've experience any difficulty in being removed from a Armstrong Shank Advertising email list, click here for personalized help.

Copyright © 2008 Armstrong Shank Advertising, Inc. All rights reserved.
7450 S Seneca, Haysville, KS 67060

From navarrete@advbiol.com Tue Dec 30 16:26:31 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4463B3A69A0 for ; Tue, 30 Dec 2008 16:26:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.675 X-Spam-Level: X-Spam-Status: No, score=-7.675 tagged_above=-999 required=5 tests=[BAYES_80=2, DNS_FROM_RFC_DSN=1.495, HELO_DYNAMIC_DHCP=1.398, HELO_DYNAMIC_HCC=4.295, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_IMAGE_ONLY_04=2.041, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_1=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_HTML_A_BODY=0.742, SARE_HTML_IMG_ONLY=1.666, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7CHxMJSrE2X for ; Tue, 30 Dec 2008 16:26:31 -0800 (PST) Received: from aig.com (unknown [92.8.23.11]) by core3.amsl.com (Postfix) with SMTP id 0E48F3A69B7 for ; Tue, 30 Dec 2008 16:26:29 -0800 (PST) To: Subject: Mail delivery failed: returning message to sender From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081231002630.0E48F3A69B7@core3.amsl.com> Date: Tue, 30 Dec 2008 16:26:29 -0800 (PST) Having trouble viewing this email? Click here to view as a webpage. From jhkim@adc.co.kr Tue Dec 30 22:07:28 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3978B3A6B61 for ; Tue, 30 Dec 2008 22:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.016 X-Spam-Level: X-Spam-Status: No, score=-1.016 tagged_above=-999 required=5 tests=[BAYES_99=3.5, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SBL=20, URIBL_SC_SURBL=10, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkr5UBS4y7-g for ; Tue, 30 Dec 2008 22:07:27 -0800 (PST) Received: from s66-76-26-64.tyrmcmta03.hnsntx.tl.sta.suddenlink.net (s66-76-26-64.tyrmcmta03.hnsntx.tl.sta.suddenlink.net [66.76.26.64]) by core3.amsl.com (Postfix) with SMTP id 953EF3A6BA8 for ; Tue, 30 Dec 2008 22:07:25 -0800 (PST) To: Subject: Celebrate a victory in love From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20081231060726.953EF3A6BA8@core3.amsl.com> Date: Tue, 30 Dec 2008 22:07:25 -0800 (PST)


Please do not reply to this email. To contact Armstrong Shank Advertising, please visit us

This email message was sent to . If you do not wish to receive further communications from Armstrong Shank Advertising, click here to unsubscribe.

If you've experience any difficulty in being removed from a Armstrong Shank Advertising email list, click here for personalized help.

Copyright © 2008 Armstrong Shank Advertising, Inc. All rights reserved.
7450 S Seneca, Haysville, KS 67060

From ipsec-bounces@ietf.org Wed Dec 31 18:57: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 61E883A67E9; Wed, 31 Dec 2008 18:57:50 -0800 (PST) X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3515C3A69FB for ; Wed, 31 Dec 2008 18:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 LdAWQ+op38CV for ; Wed, 31 Dec 2008 18:57:48 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id E4FC83A67D1 for ; Wed, 31 Dec 2008 18:57:47 -0800 (PST) Received: from [10.20.30.158] (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 n012vSEa029204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Dec 2008 19:57:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7B78230D-4C3B-4846-859E-27ACC1E1B89B@checkpoint.com> References: <64a9a4a70812112316p1ee69589k297b77721f4a488b@mail.gmail.com> <64a9a4a70812112331m25dd60b7w201f8beef4cc7952@mail.gmail.com> <64a9a4a70812112339i765d9812t194db001b6ec310b@mail.gmail.com> <7B78230D-4C3B-4846-859E-27ACC1E1B89B@checkpoint.com> Date: Wed, 31 Dec 2008 18:57:26 -0800 To: Yoav Nir , Patricia From: Paul Hoffman Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2 CP with CREATE-CHILD-SA exchange X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 10:21 AM +0200 12/16/08, Yoav Nir wrote: >On Dec 12, 2008, at 9:39 AM, Patricia wrote: > >>Hi, >>When I was reading RFC4306 & 4718, I had one puzzle on IKEv2 CP. According to RFC4306 2.19, >>"A request for such a temporary address can be included in any request to create a CHILD_SA (including the implicit request in message 3) by including a CP payload." >>But I'm a little confused about how it is used with CREATE-CHILD-SA exchange and what it is used for. Does it mean that the IRAS is going to assign a different IP for each of CREATE-CHILD-SA exchange? If so, since there is no EAP at this stage, the IP can be got only from local pool but not from external server. Is it such case? >> >>Thanks, >>Patricia > >Hi Patricia. > >I'm a little confused myself. The text you quoted is also present in the IKEv2bis document ( http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-01.txt ) > >It is somewhat misleading, as it implies just what you are saying, that the IRAS might assign a different IP for each IPsec SA. Even if this is permitted by the standard (more on in a few lines) this is not the way CP works. > >The usual way of doing things is to only assign one IP address during the IKE_AUTH exchange. That address persists at least until the deletion of the IKE SA (although if the SA is rekeyed or reauthenticated, the new IKE SA gets the old address) > >No implementation that I know of assigns an address at any other time. It actually makes no sense to assign several IP addresses like that, as IKEv2 does not have real address management features - there is no way to release the IP address other than tearing down the IKE SA. > >If you go to section 3.15 of RFC 4306, you'll see that the configuration payload can pass an attribute called INTERNAL_ADDRESS_EXPIRY. The theory was that you would pass that number to the client (probably the lifetime you got from the DHCP server) and the client would in a timely manner, ask the gateway to renew the address, and extend the DHCP lease. This may be the reason why CP payloads would be needed in CCSA and Informational exchanges. That option was deprecated in the bis document, so may be that CP-in-CCSA should be deprecated as well. > >If you are implementing IKEv2 client-side, you should probably not request an additional IP address in a CCSA exchange, only the IKE_AUTH exchange. If you are writing a server-side, you can probably safely ignore a CP payload in CCSA. Unfortunately, I don't see how to fix this in the document without breaking interop with implementations that follow 4306. The doc is clear that the responder doesn't have to support this (or CP at all), but I am hesitant to change this at this point without knowing how it will break older systems. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From jodie@3rivers.net Wed Dec 31 19:06:25 2008 Return-Path: X-Original-To: ietfarch-ipsec-archive@core3.amsl.com Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C6D63A69EB for ; Wed, 31 Dec 2008 19:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.909 X-Spam-Level: X-Spam-Status: No, score=-22.909 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HELO_DYNAMIC_DIALIN=3.384, HELO_EQ_DIP_DIALIN=1.573, HOST_EQ_DIP_TDIAL=2.144, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_SBL=20, 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 CqBAZN1-jqNT for ; Wed, 31 Dec 2008 19:06:25 -0800 (PST) Received: from p4FE1CE72.dip.t-dialin.net (p4FE1CC3E.dip.t-dialin.net [79.225.204.62]) by core3.amsl.com (Postfix) with SMTP id A96EC3A67D1 for ; Wed, 31 Dec 2008 19:06:23 -0800 (PST) To: Subject: Happy New Year! From: MIME-Version: 1.0 Importance: High Content-Type: text/html Message-Id: <20090101030623.A96EC3A67D1@core3.amsl.com> Date: Wed, 31 Dec 2008 19:06:23 -0800 (PST)


Please do not reply to this email. To contact Armstrong Shank Advertising, please visit us

This email message was sent to . If you do not wish to receive further communications from Armstrong Shank Advertising, click here to unsubscribe.

If you've experience any difficulty in being removed from a Armstrong Shank Advertising email list, click here for personalized help.

Copyright © 2008 Armstrong Shank Advertising, Inc. All rights reserved.
7450 S Seneca, Haysville, KS 67060

Yaron: 2.19: INTERNAL_ADDRESS_EXPIRY is = gone, but shouldn't we specify what the gateway should do if the address lease expires? On a related note, the section does not specify the lifetime of = the configuration values, i.e. should they be renewed by the next IKE SA = rekey, or reauthentication, or never?

 

Room: [A gateway] SHOULD keep addresses alive =
when possible.  What if not possible (e.g., DHCP refuses to renew =
address, or changes it)?  May need to actually delete the IKE SA in =
order to get the client to notice that it has a problem - this also =
cleans up all the associated state =
(e.g.,
traffic =
selectors may not survive).  Might want to introduce a notification =
that the SA is about to be deleted (may also apply to an EAP =
authentication that has to be renewed every x hours).  =
Clients
already =
have to expect IKE SA to be torn down at any time for any =
reason.
 
Yaron: I =
read all the above as saying that the lifetime of the configuration =
params is identical to the IKE SA’s lifetime. Let’s clarify =
it.