From nobody Tue Apr 1 13:46:25 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433D11A08C2 for ; Tue, 1 Apr 2014 13:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLD4KrwYzYeD for ; Tue, 1 Apr 2014 13:46:22 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id B220E1A08C1 for ; Tue, 1 Apr 2014 13:46:22 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1C01D813B5 for ; Tue, 1 Apr 2014 16:46:18 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1396385178; bh=ers04TDAHb8W839OVipq/nHejR3458KJuC/l05fIR8o=; h=Date:From:To:Subject:In-Reply-To:References; b=Ppd5rrAvTRUmXibDswP3A9KEAQQhSiqQfvXKDMp0KwWY+4Ct3IzNHd9/Dgz+lzViG +PqCEZRRnkXAqk+PxcoWPWmMGKLnqwAkqTZiLo/+yBlDAxALVV59vz7QJFeuMQhaVA Lk0o/75c+5ThMPRyfLEl5eZYzR+oA1rZWt42sxw0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s31KkFVu020384 for ; Tue, 1 Apr 2014 16:46:17 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 1 Apr 2014 16:46:15 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: <20140331224116.32271.49481.idtracker@ietfa.amsl.com> Message-ID: References: <20140331224116.32271.49481.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/soB2QBkIc6GweLp_Ov-Zd2JXGWY Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 20:46:25 -0000 On Mon, 31 Mar 2014, internet-drafts@ietf.org wrote: > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-esp-ah-reqts-03 So one of the changes is: - SHOULD+ AES-GCM [RFC4106] + SHOULD+ AES-GCM with a 16 octet ICV [RFC4106] While I'm happy with that change (I argued for it to not using the truncated ICV versions), the document now makes no statement about those other ICV variants. RFC 4106 states: The ICV consists solely of the AES-GCM Authentication Tag. Implementations MUST support a full-length 16-octet ICV, and MAY support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths. Me personally, and one of the authors of 4106 (John Viega) would like to see those other ICV's moved to SHOULD NOT. Since these are MAY in 4106, and not mentioned in this draft, they would remain MAY. I also wonder about: "It is NOT RECOMMENDED to use ESP with NULL authentication in conjunction with AH" Why do we now say "NOT RECOMMENDED" instead of continuing to talk in RFC4835 terms? eg: ESP with NULL authentication MUST NOT be used in conjunction with AH. If we go through the effort of stating such deployments are insecure, which we do in the next line, we might as well clearly tell implementors not to do this. "not recommended" does not say "don't do this". language nits: As a non-native english speaker, "efficacy" was not clear to me, and almost read as "efficiency". So I would change "undermines the efficacy of encryption". Maybe something like just "undermines the trustworthiness the encryption" (although that sounds a bit Colbert like :) s/perfers/prefers Paul From nobody Tue Apr 1 14:24:04 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31251A09FB for ; Tue, 1 Apr 2014 14:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LURncRKDYND0 for ; Tue, 1 Apr 2014 14:24:01 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6E65E1A09F2 for ; Tue, 1 Apr 2014 14:24:01 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s31LNt64023932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 1 Apr 2014 14:23:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: Date: Tue, 1 Apr 2014 14:23:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140331224116.32271.49481.idtracker@ietfa.amsl.com> To: Paul Wouters X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/1-Evewt11SBeSHyA9O5zJYYwSJQ Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 21:24:03 -0000 On Apr 1, 2014, at 1:46 PM, Paul Wouters wrote: > On Mon, 31 Mar 2014, internet-drafts@ietf.org wrote: >=20 >> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt >=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-esp-ah-reqts-03 >=20 > So one of the changes is: >=20 > - SHOULD+ AES-GCM [RFC4106] > + SHOULD+ AES-GCM with a 16 octet ICV [RFC4106] >=20 > While I'm happy with that change (I argued for it to not using the > truncated ICV versions), the document now makes no statement about = those > other ICV variants. RFC 4106 states: >=20 > The ICV consists solely of the AES-GCM Authentication Tag. > Implementations MUST support a full-length 16-octet ICV, and MAY > support 8 or 12 octet ICVs, and MUST NOT support other ICV = lengths. >=20 > Me personally, and one of the authors of 4106 (John Viega) would like = to > see those other ICV's moved to SHOULD NOT. Since these are MAY in = 4106, > and not mentioned in this draft, they would remain MAY. That was the intention: MAY. "SHOULD NOT" somewhat indicates a belief = that the crypto has degraded, and that is not the case here. > I also wonder about: >=20 > "It is NOT RECOMMENDED to use ESP with NULL authentication > in conjunction with AH" >=20 > Why do we now say "NOT RECOMMENDED" instead of continuing to talk in > RFC4835 terms? eg: >=20 > ESP with NULL authentication MUST NOT be used in conjunction > with AH. >=20 > If we go through the effort of stating such deployments are insecure, > which we do in the next line, we might as well clearly tell = implementors > not to do this. "not recommended" does not say "don't do this". RFC 4835 does not say that ESP with NULL MUST NOT be used with AH. It = waffles. > language nits: >=20 > As a non-native english speaker, "efficacy" was not clear to me, and > almost read as "efficiency". So I would change "undermines the = efficacy > of encryption". Maybe something like just "undermines the = trustworthiness > the encryption" (although that sounds a bit Colbert like :) >=20 > s/perfers/prefers I'll make these changes in -04. It turns out I need to do a rev anyway = because I forgot to list the new DES "MUST NOT" in the changes summary. --Paul Hoffman= From nobody Tue Apr 1 14:42:27 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94ADF1A0A0A for ; Tue, 1 Apr 2014 14:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg7F6d-5bBZy for ; Tue, 1 Apr 2014 14:42:22 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 29D051A0A0C for ; Tue, 1 Apr 2014 14:42:21 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AC94A813B5; Tue, 1 Apr 2014 17:42:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1396388537; bh=IgWPTYGpIqCpzeeNQcbQhJ1zAdlTeLm7WWMxCxXxLNk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SiVeu7COKzQHmBC4sCLiv5EoCEasMKjUBXEwijqwA7xyEX7IDXZIH9RPGfN6KRj4n Y0Ys7CjlIpC8smgY4izOVC92rzik/TxnZrVNVgeljQ9r094po/y1FpJJI54f0Nrtm/ 0OmE7vYPaulmi9Xb6Ez+nplMpZja/q3dG8/91do0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s31LgGdf014421; Tue, 1 Apr 2014 17:42:17 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 1 Apr 2014 17:42:16 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <20140331224116.32271.49481.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/YHOsYJaoL_vkLQVYTg7gGTHoFSM Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 21:42:24 -0000 On Tue, 1 Apr 2014, Paul Hoffman wrote: >> The ICV consists solely of the AES-GCM Authentication Tag. >> Implementations MUST support a full-length 16-octet ICV, and MAY >> support 8 or 12 octet ICVs, and MUST NOT support other ICV lengths. >> >> Me personally, and one of the authors of 4106 (John Viega) would like to >> see those other ICV's moved to SHOULD NOT. Since these are MAY in 4106, >> and not mentioned in this draft, they would remain MAY. > > That was the intention: MAY. "SHOULD NOT" somewhat indicates a belief that the crypto has degraded, and that is not the case here. Ok, too bad :P >> I also wonder about: >> >> "It is NOT RECOMMENDED to use ESP with NULL authentication >> in conjunction with AH" >> >> Why do we now say "NOT RECOMMENDED" instead of continuing to talk in >> RFC4835 terms? eg: >> >> ESP with NULL authentication MUST NOT be used in conjunction >> with AH. >> >> If we go through the effort of stating such deployments are insecure, >> which we do in the next line, we might as well clearly tell implementors >> not to do this. "not recommended" does not say "don't do this". > > RFC 4835 does not say that ESP with NULL MUST NOT be used with AH. It waffles. Isn't the point of this document to fix that waffling? The next sentence is: "some configurations of this combination of services have been shown to be insecure [PD10]" Isn't "is insecure" a good enough reason to MUST NOT? Paul From nobody Wed Apr 2 08:53:27 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF4F1A0293 for ; Wed, 2 Apr 2014 08:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltC3nEVwZSSw for ; Wed, 2 Apr 2014 08:53:18 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id CDD1D1A02EC for ; Wed, 2 Apr 2014 08:53:17 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id dc16so364214qab.3 for ; Wed, 02 Apr 2014 08:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=1JMpFk8U349qkxnVTcMpgQP274aGBcb/UOnPHKioV98=; b=gOEJ1bx80mwi+36bJKmryyMT9uITcUXFyodYj1T6fejUpEUvFsCX1nBrR0unPn0L4p RxsjVQj4gkXA4ZXehVNoJUPxR+nHulvLBeUXxr+U5VdsJHc7eNXscECYKQI1MjdUXG1v FEDG1HBltXf5SCi0f0VuNC7ezQCboOTebbFHl1PEQbuoDy2FzAaL3rfZu8a7x2jKWtx7 MIIULNwmzSzsR4WihJWmO9F9m7oqVU16LGs5NmpW50fxiXwkRndu9DXksgrEfhCxpx3l 8zeSQDILFjpVWZqKV/vH+zMHY9VNm/O3vRRCSkdQPlphS2IJOEnozKTaS0yFDcWmglJJ oP0g== X-Received: by 10.224.166.210 with SMTP id n18mr1673085qay.6.1396453993848; Wed, 02 Apr 2014 08:53:13 -0700 (PDT) Received: from [10.30.20.15] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id b5sm4523833qar.25.2014.04.02.08.53.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 08:53:13 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 2 Apr 2014 11:53:13 -0400 To: IPsec ME WG List Message-Id: <5FB505F6-3CC8-4685-851D-09BB05813542@gmail.com> Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/d5C3BX6Iq51bfQ8jIGd3GoQZ1z8 Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 15:53:25 -0000 All, Working primarily from the HTML diff, towards the end of Section 3, the draft -03 text says in part: "The IPsec community generally prefers ESP with NULL encryption over AH, but AH is required in some protocols; further, AH is more appropriate when there are security-sensitive options in the IP header" The 1st part of this assumes that IP-layer options aren't in the packet (which most commonly is true) and that the deployment threat model does not consider option insertion attacks to be a major threat (a widely held belief for the commercial portions of the Internet). The 2nd part of this is vague, unclear, and a bit misleading. It could be read as indicating that ESP with NULL encryption is able to protect IP header options, but AH is preferred for that case. In fact, ESP is *NEVER CAPABLE* of (A) protecting IPv4 options or (B) of protecting IPv6 options that are seen & processed by intermediate systems (e.g. routers, security gateways, other middleboxes). ESP also NEVER can prevent option insertion attacks. Lastly, it is ALWAYS possible for an intermediate system (e.g. router with ACLs) to parse past the AH to see transport-layer headers, but even the best of the heuristics for parsing past an ESP header are not 100% reliable. [IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 routers with forwarding silicon that could parse AH and any other IPv4/IPv6 options - at wire-speed for 10 Gbps interfaces - 10 years ago. I am aware of 2 other very widely deployed implementations with the same ability to parse past AH to read TCP/UDP ports and apply ACLs at wire-speed. So this is a widely deployed capability, rather than theory. :-] We owe it to readers to be crisp, clear, complete, and accurate with the text in this draft. Candidate new text: "When no IPv4 options or IPv6 optional headers are present, and in environments without concerns about attacks based on option insertion (e.g. inserting a source routing header to facilitate pervasive eavesdropping), the IPsec community generally prefers ESP with NULL encryption over AH. However, some protocols require AH. Also, AH always protects all IPv4 options and IPv6 optional headers, while ESP NULL is unable to protect any IPv4 options or to protect IPv6 options that are seen & processed by intermediate systems (e.g. routers, security gateways, other middle-boxes). Some IP-layer options, for example IPSO [RFC-1108] and CALIPSO [RFC-5570], today are deployed in some environments while using AH to provide both integrity protection & authentication. Further, deployed routers from multiple vendors are able to parse past an AH header in order to read upper-layer protocol (e.g. TCP) header information (e.g. to apply port-based router ACLs) at wire-speed. By contrast, there is no 100% reliable way to parse past an ESP header, although some ESP header parsing heuristics have been documented [RFC-5879] that work in some cases. Yours, Ran Atkinson From nobody Wed Apr 2 10:25:44 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BE91A0242 for ; Wed, 2 Apr 2014 10:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzMqnHKZdAJH for ; Wed, 2 Apr 2014 10:25:37 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 231B81A0295 for ; Wed, 2 Apr 2014 10:25:37 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s32HPUYk085596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Apr 2014 10:25:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <5FB505F6-3CC8-4685-851D-09BB05813542@gmail.com> Date: Wed, 2 Apr 2014 10:25:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7AD00C63-C36C-47F0-9D41-916847F018A2@vpnc.org> References: <5FB505F6-3CC8-4685-851D-09BB05813542@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/0_9keHV_O6ctVTDWFNS5GZjBUsI Cc: IPsec ME WG List Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 17:25:42 -0000 On Apr 2, 2014, at 8:53 AM, RJ Atkinson wrote: > Working primarily from the HTML diff, towards the end of Section 3,=20 > the draft -03 text says in part: >=20 > "The IPsec community generally prefers ESP with NULL encryption > over AH, but AH is required in some protocols; further, AH is > more appropriate when there are security-sensitive options in > the IP header" >=20 > The 1st part of this assumes that IP-layer options aren't in the > packet (which most commonly is true) and that the deployment threat > model does not consider option insertion attacks to be a major threat > (a widely held belief for the commercial portions of the Internet). >=20 > The 2nd part of this is vague, unclear, and a bit misleading. It > could be read as indicating that ESP with NULL encryption is able to > protect IP header options, but AH is preferred for that case. That was certainly not the intention. > In fact, ESP is *NEVER CAPABLE* of (A) protecting IPv4 options or=20 > (B) of protecting IPv6 options that are seen & processed by=20 > intermediate systems (e.g. routers, security gateways, other=20 > middleboxes). ESP also NEVER can prevent option insertion attacks. Sure. > Lastly, it is ALWAYS possible for an intermediate system (e.g. router > with ACLs) to parse past the AH to see transport-layer headers,=20 > but even the best of the heuristics for parsing past an ESP header=20 > are not 100% reliable. Yep. > [IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 routers > with forwarding silicon that could parse AH and any other IPv4/IPv6 > options - at wire-speed for 10 Gbps interfaces - 10 years ago. I am > aware of 2 other very widely deployed implementations with the same > ability to parse past AH to read TCP/UDP ports and apply ACLs at > wire-speed. So this is a widely deployed capability, rather than > theory. :-] That's not an important note for this discussion, which is about what = the IPsec community has expressed as a general preference. You feel that = preference is wrong, and you have stated that in earlier WG discussions. > We owe it to readers to be crisp, clear, complete, and accurate=20 > with the text in this draft. Yes, but: > Candidate new text: >=20 > "When no IPv4 options or IPv6 optional headers are present, and=20 > in environments without concerns about attacks based on option > insertion (e.g. inserting a source routing header to facilitate > pervasive eavesdropping), the IPsec community generally prefers > ESP with NULL encryption over AH. However, some protocols > require AH. Also, AH always protects all IPv4 options and IPv6 > optional headers, while ESP NULL is unable to protect any IPv4 > options or to protect IPv6 options that are seen & processed by > intermediate systems (e.g. routers, security gateways, other > middle-boxes). Some IP-layer options, for example IPSO [RFC-1108] > and CALIPSO [RFC-5570], today are deployed in some environments=20 > while using AH to provide both integrity protection & = authentication. >=20 > Further, deployed routers from multiple vendors are able to parse > past an AH header in order to read upper-layer protocol > (e.g. TCP) header information (e.g. to apply port-based router > ACLs) at wire-speed. By contrast, there is no 100% reliable way > to parse past an ESP header, although some ESP header parsing > heuristics have been documented [RFC-5879] that work in some = cases. That is neither crisp nor clear; it is more complete; it is inaccurate = about the parameters that the IPsec community cares about. The proposed = text comes off as an advertisement for AH, but that's exactly the = opposite direction that the WG has been leaning for this document. If the problem is the lack of clarity in the current text, let's just = make it clearer: The IPsec community generally prefers ESP with NULL encryption over AH. = AH is still required in some protocols and operational environments when = there are security-sensitive options in the IP header, such as source = routing headers. Reducing the readability of this document to meet your views of AH does = a disservice to the overall value of the document. --Paul Hoffman= From nobody Wed Apr 2 12:33:49 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DEF1A03A2 for ; Wed, 2 Apr 2014 12:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OOFOJ6frmzf for ; Wed, 2 Apr 2014 12:33:43 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEDF1A03A8 for ; Wed, 2 Apr 2014 12:33:43 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so23998qgf.21 for ; Wed, 02 Apr 2014 12:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=4BINTfgYFHiOR8mamO1/62vwxeujIParIImoiBATLK4=; b=t+dGALrQ5bbx2pm3ANi+FYgbusJXNcgGiXa3GOZsjbYZYxVAXUDhotjTZ0OhOJ19tL dsZ9HAvCbsBhfNrz57KLlpMLN69b2nvNxc55j23eDal3YVWweH8/PVHmRmDEUC2vvD5M 6hFH01Ym8tXcqF8UvCyycOp1mbKC63chZglh1bgdN55PxB8vWKhYQ1Naj61WbTHMTz1U INI7Jcmy11pw6nF2ZzCeEYhfRzRPF9Bn24m6trAdFSdONVeszSZMsSj6Csthvm4v1vFp ZL0bzIBhHg1TGLVioYF/C6mD9CqNkjK5k2K7qKdRzI+bXpGlh9Uaawvxsz22kKLL1+o+ TuJA== X-Received: by 10.224.5.136 with SMTP id 8mr2890713qav.42.1396467219010; Wed, 02 Apr 2014 12:33:39 -0700 (PDT) Received: from [10.30.20.15] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id r5sm5531549qaj.24.2014.04.02.12.33.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 12:33:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <7AD00C63-C36C-47F0-9D41-916847F018A2@vpnc.org> Date: Wed, 2 Apr 2014 15:33:39 -0400 Content-Transfer-Encoding: 7bit Message-Id: <3760F0D0-F93A-4AFB-BBD4-772AA717F2B6@gmail.com> References: <5FB505F6-3CC8-4685-851D-09BB05813542@gmail.com> <7AD00C63-C36C-47F0-9D41-916847F018A2@vpnc.org> To: IPsec ME WG List X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/JaMrYzgxc2Bm_toBrzNP8CSqxPk Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 19:33:48 -0000 On 02 Apr 2014, at 13:25 , Paul Hoffman wrote: > That was certainly not the intention. OK. >> [IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 routers >> with forwarding silicon that could parse AH and any other IPv4/IPv6 >> options - at wire-speed for 10 Gbps interfaces - 10 years ago. I am >> aware of 2 other very widely deployed implementations with the same >> ability to parse past AH to read TCP/UDP ports and apply ACLs at >> wire-speed. So this is a widely deployed capability, rather than >> theory. :-] > > That's not an important note for this discussion, ... Ah, but it is important, because it talks about deployed reality, and many many users and implementers DO care about the ability to apply ACLs. > which is about what the IPsec community > has expressed as a general preference. You are mis-characterising the "VPN community" (e.g. VPNC) as being the whole "IPsec community". This I-D supposedly is NOT a VPN-focused draft, but instead claims to address the whole audience of IPsec implementers, users, and usages. > You feel that preference is wrong, and you have stated > that in earlier WG discussions. No. That is not what I believe or feel, NOR is the quote a correct summary what I have expressed in past discussions. Instead, that is a mis-apprehension of what I have said. In fact, I don't think that the preference for ESP with an integrated transform is wrong or bad - for VPN uses. Indeed, there are well-understood and broadly agreed reasons why - for VPNs - ESP with an integrated transform is preferable. Further, we all agree and understand that VPN is the most widely deployed use case. However, it is not the only deployed IPsec use case. A general IPsec Requirements document ought to be addressing all deployed use cases, and ought not be limited to VPN uses. >> We owe it to readers to be crisp, clear, complete, and accurate >> with the text in this draft. > > Yes, but: > >> Candidate new text: >> >> "When no IPv4 options or IPv6 optional headers are present, and >> in environments without concerns about attacks based on option >> insertion (e.g. inserting a source routing header to facilitate >> pervasive eavesdropping), the IPsec community generally prefers >> ESP with NULL encryption over AH. However, some protocols >> require AH. Also, AH always protects all IPv4 options and IPv6 >> optional headers, while ESP NULL is unable to protect any IPv4 >> options or to protect IPv6 options that are seen & processed by >> intermediate systems (e.g. routers, security gateways, other >> middle-boxes). Some IP-layer options, for example IPSO [RFC-1108] >> and CALIPSO [RFC-5570], today are deployed in some environments >> while using AH to provide both integrity protection & authentication. >> >> Further, deployed routers from multiple vendors are able to parse >> past an AH header in order to read upper-layer protocol >> (e.g. TCP) header information (e.g. to apply port-based router >> ACLs) at wire-speed. By contrast, there is no 100% reliable way >> to parse past an ESP header, although some ESP header parsing >> heuristics have been documented [RFC-5879] that work in some cases. > > That is neither crisp nor clear; it is more complete; > it is inaccurate about the parameters that the IPsec community cares about. Precisely HOW is it inaccurate ? I believe that everything in my text is accurate. If there is something inaccurate, please do say precisely what. > The proposed text comes off as an advertisement for AH, but that's exactly > the opposite direction that the WG has been leaning for this document. I'm open to having you or others propose some alternative text, provided that text makes clear that ESP can't protect IP options in transit, while AH can. This difference in the provided security properties is entirely factual. For VPN deployments, this might not matter, but for other existing IPsec deployments it is known to matter. Again, this document is not about a VPN profile of IPsec, it is about the entirety of IPsec. > The IPsec community generally prefers ESP with NULL encryption over AH. > AH is still required in some protocols and operational environments > when there are security-sensitive options in the IP header, such as > source routing headers. This does not make clear that ESP can't protect the IP options, which is an important-to-document limitation of ESP. It also should mention IP sensitivity label options, such as RFC-1108 and RFC-5570 as a use case for AH, in addition to source-routing headers. Yours, Ran From nobody Wed Apr 2 13:17:52 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA341A03C3 for ; Wed, 2 Apr 2014 13:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tePQ5lVSTneH for ; Wed, 2 Apr 2014 13:17:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9196F1A039C for ; Wed, 2 Apr 2014 13:17:45 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s32KHcm5092223 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 2 Apr 2014 13:17:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <3760F0D0-F93A-4AFB-BBD4-772AA717F2B6@gmail.com> Date: Wed, 2 Apr 2014 13:17:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0B1B3C1C-1EC6-4B22-98FA-E05E3506D3E3@vpnc.org> References: <5FB505F6-3CC8-4685-851D-09BB05813542@gmail.com> <7AD00C63-C36C-47F0-9D41-916847F018A2@vpnc.org> <3760F0D0-F93A-4AFB-BBD4-772AA717F2B6@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/AmvRtni9lYnOYgRczIwOGL5tOc0 Cc: IPsec ME WG List Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 20:17:50 -0000 Yaron obviously gets to call consensus on this. On Apr 2, 2014, at 12:33 PM, RJ Atkinson wrote: > On 02 Apr 2014, at 13:25 , Paul Hoffman wrote: >> That was certainly not the intention. >=20 > OK. >=20 >>> [IMPORTANT NOTE: A previous employer of mine shipped IPv4/IPv6 = routers >>> with forwarding silicon that could parse AH and any other IPv4/IPv6 >>> options - at wire-speed for 10 Gbps interfaces - 10 years ago. I am >>> aware of 2 other very widely deployed implementations with the same >>> ability to parse past AH to read TCP/UDP ports and apply ACLs at >>> wire-speed. So this is a widely deployed capability, rather than >>> theory. :-] >>=20 >> That's not an important note for this discussion, ... >=20 > Ah, but it is important, because it talks about deployed reality, > and many many users and implementers DO care about the ability=20 > to apply ACLs. You have not said why that is important for *this discussion* which is = about the document on cryptographic algorithm implementation = requirements. If an implementer cares about what your previous employer = shipped and so on, they are welcome to implement AH; nothing in the = wording of this document says otherwise. >> which is about what the IPsec community >> has expressed as a general preference. >=20 > You are mis-characterising the "VPN community" (e.g. VPNC) > as being the whole "IPsec community". =20 No, I'm talking about what has been said in the WG on this topic to = date. This WG is the best representation of the IPsec community that we = have. > This I-D supposedly > is NOT a VPN-focused draft, but instead claims to address=20 > the whole audience of IPsec implementers, users, and usages. Correct. If it was VPN focused, it would probably not even mention AH. >> You feel that preference is wrong, and you have stated >> that in earlier WG discussions. >=20 > No. =20 Actually, yes. Looking in the archives, I see you stating it in a few = different threads. > That is not what I believe or feel, NOR is the quote=20 > a correct summary what I have expressed in past discussions. > Instead, that is a mis-apprehension of what I have said. >=20 > In fact, I don't think that the preference for ESP with an integrated > transform is wrong or bad - for VPN uses. Indeed, there are=20 > well-understood and broadly agreed reasons why - for VPNs - > ESP with an integrated transform is preferable. Further, we all=20 > agree and understand that VPN is the most widely deployed use case. =20= > However, it is not the only deployed IPsec use case. =20 That is what you have said on earlier threads, so I'm not sure how you = could say that what I said is wrong. > A general IPsec Requirements document ought to be addressing > all deployed use cases, and ought not be limited to VPN uses. If that's what the WG wants, great. In me reading the list as a document = author, I don't see people agreeing with that. >>> We owe it to readers to be crisp, clear, complete, and accurate=20 >>> with the text in this draft. >>=20 >> Yes, but: >>=20 >>> Candidate new text: >>>=20 >>> "When no IPv4 options or IPv6 optional headers are present, and=20 >>> in environments without concerns about attacks based on option >>> insertion (e.g. inserting a source routing header to facilitate >>> pervasive eavesdropping), the IPsec community generally prefers >>> ESP with NULL encryption over AH. However, some protocols >>> require AH. Also, AH always protects all IPv4 options and IPv6 >>> optional headers, while ESP NULL is unable to protect any IPv4 >>> options or to protect IPv6 options that are seen & processed by >>> intermediate systems (e.g. routers, security gateways, other >>> middle-boxes). Some IP-layer options, for example IPSO [RFC-1108] >>> and CALIPSO [RFC-5570], today are deployed in some environments=20 >>> while using AH to provide both integrity protection & = authentication. >>>=20 >>> Further, deployed routers from multiple vendors are able to parse >>> past an AH header in order to read upper-layer protocol >>> (e.g. TCP) header information (e.g. to apply port-based router >>> ACLs) at wire-speed. By contrast, there is no 100% reliable way >>> to parse past an ESP header, although some ESP header parsing >>> heuristics have been documented [RFC-5879] that work in some = cases. >>=20 >> That is neither crisp nor clear; it is more complete; >=20 >> it is inaccurate about the parameters that the IPsec community cares = about. >=20 > Precisely HOW is it inaccurate ? There has been no one on the list other than you who has given those = parameters for the statement "the IPsec community generally prefers"... > I believe that everything in my text is accurate. > If there is something inaccurate, please do say precisely what. Done so, now twice. >> The proposed text comes off as an advertisement for AH, but that's = exactly >> the opposite direction that the WG has been leaning for this = document. >=20 > I'm open to having you or others propose some alternative text, = provided > that text makes clear that ESP can't protect IP options in transit,=20 > while AH can. This difference in the provided security properties is > entirely factual. For VPN deployments, this might not matter, but > for other existing IPsec deployments it is known to matter. Again, > this document is not about a VPN profile of IPsec, it is about the > entirety of IPsec. >=20 >> The IPsec community generally prefers ESP with NULL encryption over = AH. >> AH is still required in some protocols and operational environments >> when there are security-sensitive options in the IP header, such as >> source routing headers. >=20 > This does not make clear that ESP can't protect the IP options, > which is an important-to-document limitation of ESP. Good catch. Proposed improvement: The IPsec community generally prefers ESP with NULL encryption over AH. AH is still required in some protocols and operational environments when there are security-sensitive options in the IP header, such as source = routing headers; ESP inherently cannot those IP options. > It also should mention IP sensitivity label options, such as RFC-1108=20= > and RFC-5570 as a use case for AH, in addition to source-routing = headers. Having this document listing all of the IP options from Informational = RFCs would undermine the value of this document. --Paul Hoffman From nobody Wed Apr 2 13:35:03 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9A01A03D6 for ; Wed, 2 Apr 2014 13:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rZH42-MirEE for ; Wed, 2 Apr 2014 13:34:56 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB8E1A03D2 for ; Wed, 2 Apr 2014 13:34:56 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id j7so706660qaq.8 for ; Wed, 02 Apr 2014 13:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=5crLsyBBOkuYrP3L6B0mvIsgSb04FTUPYSh6uB0lHaE=; b=WTJtn9BBlKp9Gga26IqlE04yHkOgFu7z/Q20+DXML/DtAz1gAv32wiSF6dW7wWM6Kk l/TR5h668zo6gmieMpwElZzjOLOW2dHXUz1t1q+AlRCy7uvCp1ZYQx298htPfXBT1QvS YDztw07xJCcMhaYQTkkzwfFIE8hEhRv1xKplkJxzFt5EFAve1itFqdXLRurL/CMO8mV/ ThxLDq5SVqHDSk45T8kTy6TF4KlpkRfS2TRxjMAcT4CX85Twk4vNcSVcoDD20dYnrfZx XaYgGQha438ZDkkdfOivvA88r+DLhmO/SGme90F/KZaVrSDysyCh8pbcgFX4fG+d9xz3 wYmA== X-Received: by 10.229.179.65 with SMTP id bp1mr3172609qcb.11.1396470892562; Wed, 02 Apr 2014 13:34:52 -0700 (PDT) Received: from [10.30.20.15] (pool-173-79-6-58.washdc.fios.verizon.net. [173.79.6.58]) by mx.google.com with ESMTPSA id x8sm5814082qam.20.2014.04.02.13.34.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 13:34:52 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: <0B1B3C1C-1EC6-4B22-98FA-E05E3506D3E3@vpnc.org> Date: Wed, 2 Apr 2014 16:34:52 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <5FB505F6-3CC8-4685-851D-09BB05813542@gmail.com> <7AD00C63-C36C-47F0-9D41-916847F018A2@vpnc.org> <3760F0D0-F93A-4AFB-BBD4-772AA717F2B6@gmail.com> <0B1B3C1C-1EC6-4B22-98FA-E05E3506D3E3@vpnc.org> To: IPsec ME WG List X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Z4p0lmk8li28saB7g4SGIjIuItg Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 20:35:02 -0000 On 02 Apr 2014, at 16:17 , Paul Hoffman wrote: > Actually, yes. Looking in the archives, > I see you stating it in a few different threads. Again, that's not what I said, but instead what you have mis-read. >> A general IPsec Requirements document ought to be addressing >> all deployed use cases, and ought not be limited to VPN uses. > > If that's what the WG wants, great. In me reading the > list as a document author, I don't see people agreeing with that. If this I-D is NOT addressing all IPsec use cases, then why isn't this I-D titled the "IPsec VPN Requirements" document ? > Good catch. Proposed improvement: > > The IPsec community generally prefers ESP with NULL encryption over AH. > AH is still required in some protocols and operational environments when > there are security-sensitive options in the IP header, such as source > routing headers; ESP inherently cannot those IP options. I assume you meant to write: s/cannot those/cannot protect those/ If I understand the intended text, that is an important and very helpful improvement, and I very much appreciate it being added. >> It also should mention IP sensitivity label options, such as RFC-1108 >> and RFC-5570 as a use case for AH, in addition to source-routing headers. > > Having this document listing all of the IP options from Informational RFCs > would undermine the value of this document. Adding s/source routing headers;/source routing headers or sensitivity label options;/ plus adding those 2 RFC citations to your "proposed improvement" text above could not possibly "undermine the value of this document", particularly since both RFCs are examples of currently deployed use cases. Please re-consider applying the brief text edits I've provided just above and the corresponding citations to those 2 RFCs. Yours, Ran From nobody Wed Apr 2 15:13:25 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E561A03FB for ; Wed, 2 Apr 2014 15:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZ9xRRP7qGNm for ; Wed, 2 Apr 2014 15:13:15 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id B86351A03F1 for ; Wed, 2 Apr 2014 15:13:15 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8D009813B1 for ; Wed, 2 Apr 2014 18:13:10 -0400 (EDT) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s32MDAWi016392 for ; Wed, 2 Apr 2014 18:13:10 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 2 Apr 2014 18:13:10 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: IPsec ME WG List In-Reply-To: <3760F0D0-F93A-4AFB-BBD4-772AA717F2B6@gmail.com> Message-ID: References: <5FB505F6-3CC8-4685-851D-09BB05813542@gmail.com> <7AD00C63-C36C-47F0-9D41-916847F018A2@vpnc.org> <3760F0D0-F93A-4AFB-BBD4-772AA717F2B6@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/EXkvDv_UM3rpCrVB6xpI42huAKA Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 22:13:20 -0000 On Wed, 2 Apr 2014, RJ Atkinson wrote: >> The IPsec community generally prefers ESP with NULL encryption over AH. >> AH is still required in some protocols and operational environments >> when there are security-sensitive options in the IP header, such as >> source routing headers. > > This does not make clear that ESP can't protect the IP options, > which is an important-to-document limitation of ESP. In my 15 years of IPsec work, I've hardly seen requests for AH. When our KLIPS stack per default disabled AH support in the kernel module, no one complained. > It also should mention IP sensitivity label options, such as RFC-1108 > and RFC-5570 as a use case for AH, in addition to source-routing headers. There are people that still accept source routing? How archaic.... I'm with Paul Hoffman here. I think the current text is fine. Paul From nobody Wed Apr 2 23:41:27 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D6A1A00DA for ; Wed, 2 Apr 2014 23:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9N6IpxMo1xG for ; Wed, 2 Apr 2014 23:41:20 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id DB7FB1A00E2 for ; Wed, 2 Apr 2014 23:41:19 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w61so1320552wes.15 for ; Wed, 02 Apr 2014 23:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6fWfu1Hlhpc4tnLGMGB+7zDdWZf68od+Ow2azeHJCkI=; b=OSK57wLso12w0LiP9NZigIPCZstmT7MJKHg+mqk5cScmivxyxd4Km/W1f8NU1bl/Np 6OZyQB9MHNHM03GS4YBER7PkLGeLMAc+LKgyEIBnwpXPxGJ/d4RDkiIGhgukc/GcO5RB Z8+fkLRcWv4hXvTKd9KUU0h6BCBj3swuBl5dT1II7OqS66i/yH6XXDGqgC7oHyH4KcTi HhMoiEiLW8lu74Gu82X+2iYyS34EZokqKOkfj/L3iYt5vf6and/cVvMShq50kBkXOz+r pPQnK8M8HnHPOSGJ+0SxDZ+bC2OOCOGrTnYB4VMTAt0I5udYxubqLMjuu8XVx4J9BzHU KYdQ== X-Received: by 10.180.94.196 with SMTP id de4mr8228068wib.16.1396507275197; Wed, 02 Apr 2014 23:41:15 -0700 (PDT) Received: from [172.24.251.171] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id 4sm9753199eeq.33.2014.04.02.23.41.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Apr 2014 23:41:14 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: Date: Thu, 3 Apr 2014 09:41:05 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <41BF0C41-A0D9-4B8A-84EC-FB234E6015D8@gmail.com> References: <5FB505F6-3CC8-4685-851D-09BB05813542@gmail.com> <7AD00C63-C36C-47F0-9D41-916847F018A2@vpnc.org> <3760F0D0-F93A-4AFB-BBD4-772AA717F2B6@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/TcEgGmktqrVy78QVGTcGE_Yrrls Cc: IPsec ME WG List Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 06:41:25 -0000 On Apr 3, 2014, at 1:13 AM, Paul Wouters wrote: > On Wed, 2 Apr 2014, RJ Atkinson wrote: >=20 >>> The IPsec community generally prefers ESP with NULL encryption over = AH. >>> AH is still required in some protocols and operational environments >>> when there are security-sensitive options in the IP header, such as >>> source routing headers. >>=20 >> This does not make clear that ESP can't protect the IP options, >> which is an important-to-document limitation of ESP. >=20 > In my 15 years of IPsec work, I've hardly seen requests for AH. When = our > KLIPS stack per default disabled AH support in the kernel module, no = one > complained. FWIW nobody complained when we removed AH from our firewall in 2003, but = our product uses IPsec only for VPN. I=92m also with Paul on this. Yoav From nobody Thu Apr 3 05:53:51 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AADA41A0149 for ; Thu, 3 Apr 2014 05:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TioIgYJLQKy3 for ; Thu, 3 Apr 2014 05:53:43 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 342E71A0203 for ; Thu, 3 Apr 2014 05:52:59 -0700 (PDT) Received: by mail-ig0-f177.google.com with SMTP id ur14so1738931igb.10 for ; Thu, 03 Apr 2014 05:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A3Y4U0V1zi7+7jEaVFNXdm52+LgNdp+Zh5t5mQFkY6s=; b=BuDZ9iJG0aj0nf9SxmQPSwKU0IpGaFPTUvvu9LkUEa0KD8ZIpANst+G/UPFw8zTIpQ gney/BVoaLhVxqycnSZxRbxowptkwnJMKVQ6j7CozXHpmP2PkLFL0dfyZ8e8W5prDrT8 WjdeE4vse397wX2xr3J4OeyBS4+dKksKRQCf7JnL3H4zC7T8Ou4eOLsYfaI9luuyHWsZ /o+koza+/dGy2SaMRuQTHluO6BRiycEhAr+6bmoheIsCRm11MVZUh84GAOWI9RPW3Gfu Vqpyrib4OcJPr8oai8dDz9OPdp5VDRG9nONT8j2pJ8Ffb/aVRbccQphl/t2EVQRoxa+d xgtw== MIME-Version: 1.0 X-Received: by 10.50.79.135 with SMTP id j7mr15279492igx.32.1396529574927; Thu, 03 Apr 2014 05:52:54 -0700 (PDT) Received: by 10.64.108.7 with HTTP; Thu, 3 Apr 2014 05:52:54 -0700 (PDT) In-Reply-To: <41BF0C41-A0D9-4B8A-84EC-FB234E6015D8@gmail.com> References: <5FB505F6-3CC8-4685-851D-09BB05813542@gmail.com> <7AD00C63-C36C-47F0-9D41-916847F018A2@vpnc.org> <3760F0D0-F93A-4AFB-BBD4-772AA717F2B6@gmail.com> <41BF0C41-A0D9-4B8A-84EC-FB234E6015D8@gmail.com> Date: Thu, 3 Apr 2014 08:52:54 -0400 Message-ID: From: Richard Graveman To: Yoav Nir , Paul Hoffman , RJ Atkinson Content-Type: multipart/alternative; boundary=089e0122a7543ba86b04f622e1d5 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-rVYDepnJxxcXpQZrMWRzzj1js0 Cc: IPsec ME WG List , Paul Wouters Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 12:53:47 -0000 --089e0122a7543ba86b04f622e1d5 Content-Type: text/plain; charset=ISO-8859-1 IPsec ESP and AH have a long history with user communities that pre-date any discussion of IKE, VPN, or use cases. It is important not to damage this history by citing comments like "my customers do not use IP or the Internet that way." Fifteen years do not not capture this. I count somewhere around 21 years, but I'm usually off by one or two (which is why I don't write software anymore :-)). One of the leading, still breathing, IPsec authors said about 20 years ago, "There will never be an ESP NULL encryption option. Over my dead body." Tines change, But legitimate differences exist. No one is asking for a MUST do AH here. In addition to what Ran said about options, there may also be protection AH can provide for multicast that cannot be done otherwise. This has been discussed but to my knowledge never fully resolved. That being said, I think Ran's proposed text mixed what should be in the document with why something should be in the document, and these aspects should be separated. BR, Rich Graveman On Thu, Apr 3, 2014 at 2:41 AM, Yoav Nir wrote: > > On Apr 3, 2014, at 1:13 AM, Paul Wouters wrote: > > > On Wed, 2 Apr 2014, RJ Atkinson wrote: > > > >>> The IPsec community generally prefers ESP with NULL encryption over AH. > >>> AH is still required in some protocols and operational environments > >>> when there are security-sensitive options in the IP header, such as > >>> source routing headers. > >> > >> This does not make clear that ESP can't protect the IP options, > >> which is an important-to-document limitation of ESP. > > > > In my 15 years of IPsec work, I've hardly seen requests for AH. When our > > KLIPS stack per default disabled AH support in the kernel module, no one > > complained. > > FWIW nobody complained when we removed AH from our firewall in 2003, but > our product uses IPsec only for VPN. > > I'm also with Paul on this. > > Yoav > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --089e0122a7543ba86b04f622e1d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
IPsec ESP and AH have a long history w= ith user communities that pre-date any discussion of IKE, VPN, or use cases= . It is important not to damage this history by citing comments like "= my customers do not use IP or the Internet that way." Fifteen years do= not not capture this. I count somewhere around 21 years, but I'm usual= ly off by one or two (which is why I don't write software anymore :-)).=

One of the leading, still breathing, IPsec authors said abou= t 20 years ago, "There will never be an ESP NULL encryption option. Ov= er my dead body." Tines change, But legitimate differences exist. No o= ne is asking for a MUST do AH here.

In addition to what Ran said about options, there may also = be protection AH can provide for multicast that cannot be done otherwise. T= his has been discussed but to my knowledge never fully resolved.

That being said, I think Ran's proposed text mixed what should be= in the document with why something should be in the document, and these as= pects should be separated.

BR, Rich Graveman


On Thu, Apr 3, 2014 at 2:41 AM, Yoav Nir= <ynir.ietf@gmail.com> wrote:

On Apr 3, 2014, at 1:13 AM, Paul Wouters <paul@cypherpunks.ca> wrote:

> On Wed, 2 Apr 2014, RJ Atkinson wrote:
>
>>> The IPsec community generally prefers ESP with NULL encryption= over AH.
>>> AH is still required in some protocols and operational environ= ments
>>> when there are security-sensitive options in the IP header, su= ch as
>>> source routing headers.
>>
>> This does not make clear that ESP can't protect the IP options= ,
>> which is an important-to-document limitation of ESP.
>
> In my 15 years of IPsec work, I've hardly seen requests for AH. Wh= en our
> KLIPS stack per default disabled AH support in the kernel module, no o= ne
> complained.

FWIW nobody complained when we removed AH from our firewall in 2003, = but our product uses IPsec only for VPN.

I’m also with Paul on this.

Yoav

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

--089e0122a7543ba86b04f622e1d5-- From nobody Thu Apr 3 11:20:26 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A811A024D; Thu, 3 Apr 2014 11:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay90AqxvNv-x; Thu, 3 Apr 2014 11:19:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BA341A0276; Thu, 3 Apr 2014 11:19:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140403181957.17014.41208.idtracker@ietfa.amsl.com> Date: Thu, 03 Apr 2014 11:19:57 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/2UhpIsgEpFYAIzF-TgzWlBYh6S0 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 18:20:09 -0000 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 : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : David McGrew Wajdi Feghali Paul Hoffman Filename : draft-ietf-ipsecme-esp-ah-reqts-04.txt Pages : 11 Date : 2014-04-03 Abstract: This Internet Draft is standards track proposal to update to the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols makes use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-esp-ah-reqts-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 4 02:18:13 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B831A011A for ; Fri, 4 Apr 2014 02:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcZngtbmfeL0 for ; Fri, 4 Apr 2014 02:18:08 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id BBD9C1A001D for ; Fri, 4 Apr 2014 02:18:07 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s349HxuI013102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Apr 2014 12:17:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s349Hw2M003742; Fri, 4 Apr 2014 12:17:58 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21310.30918.867602.256237@fireball.kivinen.iki.fi> Date: Fri, 4 Apr 2014 12:17:58 +0300 From: Tero Kivinen To: RJ Atkinson In-Reply-To: References: <5FB505F6-3CC8-4685-851D-09BB05813542@gmail.com> <7AD00C63-C36C-47F0-9D41-916847F018A2@vpnc.org> <3760F0D0-F93A-4AFB-BBD4-772AA717F2B6@gmail.com> <0B1B3C1C-1EC6-4B22-98FA-E05E3506D3E3@vpnc.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 37 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/yYBX0Nr9OWAGgSKuN453n9Q8eN4 Cc: IPsec ME WG List Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:18:12 -0000 RJ Atkinson writes: > > If that's what the WG wants, great. In me reading the > > list as a document author, I don't see people agreeing with that. > > If this I-D is NOT addressing all IPsec use cases, then why isn't > this I-D titled the "IPsec VPN Requirements" document ? I think you are wrong there. VPN uses cases do not use ESP NULL (nor does it use AH). In all VPN cases the encryption is the important part there. I do not really see anybody running VPN tunnels in the internet using ESP NULL (or AH). As Paul said if this would be VPN specific then it would not say anything about AH or ESP NULL. > > The IPsec community generally prefers ESP with NULL encryption over AH. > > AH is still required in some protocols and operational environments when > > there are security-sensitive options in the IP header, such as source > > routing headers; ESP inherently cannot those IP options. > > I assume you meant to write: s/cannot those/cannot protect those/ ESP in tunnel mode can protect end to end options without any problems, and also protects the whole inner IP header. ESP cannot protect options which are used by the intermediate devices, but on the other those intermediate devices do not have the keying material to verify the authentication header anyways so whether AH or ESP NULL is used it does not matter. And if the intermediate devices do have the keying material then they can even parse through ESP NULL too as they do know the parameters. The main problem with the AH is that it does not work with NATs which makes its use in lots of environments difficult in the internet. It does work in the enterprice or other controlled environments. > >> It also should mention IP sensitivity label options, such as RFC-1108 > >> and RFC-5570 as a use case for AH, in addition to source-routing headers. > > > > Having this document listing all of the IP options from Informational RFCs > > would undermine the value of this document. > > Adding s/source routing headers;/source routing headers or sensitivity > label options;/ plus adding those 2 RFC citations to your "proposed > improvement" text above could not possibly "undermine the value of this > document", particularly since both RFCs are examples of currently > deployed use cases. As those options cannot be protected in transit with AH or ESP NULL without sharing the keying material to the intermediate devices, I see no point of listing those. > Please re-consider applying the brief text edits I've provided just above > and the corresponding citations to those 2 RFCs. I see no point of adding those citations, nor adding those examples. -- kivinen@iki.fi From nobody Fri Apr 4 02:33:28 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF221A0019 for ; Fri, 4 Apr 2014 02:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74YzY5zDKwzI for ; Fri, 4 Apr 2014 02:33:23 -0700 (PDT) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0EE1A00CA for ; Fri, 4 Apr 2014 02:33:23 -0700 (PDT) Received: by mail-qa0-f46.google.com with SMTP id i13so2872832qae.33 for ; Fri, 04 Apr 2014 02:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9oZBglDKj7w/O/VhG5oaxLrBw16s7yXIhHWORCLZKDs=; b=n5vU1iRR/H7Tm4TbYQn4kRqlvIat6lzlmNTqUimqzks90uhykRu5olQc6kObXajw/k oHuwBLpbORugq5BUuNz6bXX3iKR25Ylfj7OZcaLUiCyz3FyA8lCBjvuiO6kUpGL/Htj7 Dcn19JrxTkh5ADUjqMLRyInpJK7i+asSjdAq9b+u3SFA4SOpCn8AFr9O7AyeG6cJKG+x 74batt9h7TqIE1uo9FhpLM28JtmHwvdE6QETZqo78bhfAgto/SlH5EyauWGjkZ8z2hx2 Ehm3skFMRInTm0cXvbEydvVmsc/c56P9uLpnP755HtCAX6H6X+3/nLXqt+mTHJNkW4rl zUxg== MIME-Version: 1.0 X-Received: by 10.140.29.6 with SMTP id a6mr12356368qga.57.1396603998393; Fri, 04 Apr 2014 02:33:18 -0700 (PDT) Received: by 10.140.107.117 with HTTP; Fri, 4 Apr 2014 02:33:18 -0700 (PDT) In-Reply-To: References: Date: Fri, 4 Apr 2014 11:33:18 +0200 Message-ID: From: Daniel Migault To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=001a113a42c6375cd004f63435df Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/bwNNddLQnnORtp7r7VHNdzzSKP0 Cc: Valery Smyslov Subject: [IPsec] Fwd: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 09:33:27 -0000 --001a113a42c6375cd004f63435df Content-Type: text/plain; charset=ISO-8859-1 Hi, Here is the last version of our draft on clone IKE_SA. The main goal is to be handle to handle multiple interfaces. We believe this version -- the same as the one posted on March 13 -- is closed to the final one as we have considered previous reviews. We would like to have your feed backs, so we can move forward with the draft. The draft is only 7 pages -- excluding the appendix --, so please consider reviewing it. URL:http://www.ietf.org/internet-drafts/draft-mglt-ipsecme-clone-ike-sa-01.txt Htmlized: http://tools.ietf.org/html/draft-mglt-ipsecme-clone-ike-sa-01 BR, Daniel ---------- Forwarded message ---------- From: Daniel Migault Date: Thu, Mar 13, 2014 at 9:51 AM Subject: Fwd: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-01.txt To: "ipsec@ietf.org" Cc: Valery Smyslov Hi, Please find the new version for the clone IKE SA draft. This version includes all comments we received. Feel free to let us know if there are more comments to address. BR, Danie Abstract: This document considers a VPN End User setting a VPN with a security gateway where at least one of the peer has multiple interfaces. With the current IKEv2, the outer IP addresses of the VPN are determined by those used by IKEv2 channel. As a result using multiple interfaces requires to set an IKEv2 channel on each interface, or on each paths if both the VPN Client and the security gateway have multiple interfaces. Setting multiple IKEv2 channel involves multiple authentications which may each require multiple round trips and delay the VPN establishment. In addition multiple authentications unnecessarily increase load to the VPN client and the authentication infrastructure. This document presents the Clone IKE SA extension, where an additional IKEv2 channel is derived from an already authenticated IKEv2 channel. The newly created IKEv2 channel is set without the IKEv2 authentication exchange. The newly created IKEv2 channel can then be assigned to another interface using MOBIKE. -------- Original Message -------- Subject: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-01.txt Date: Thu, 13 Mar 2014 01:43:41 -0700 From: To: Valery Smyslov , Valery Smyslov , "Daniel Migault" , Daniel Migault A new version of I-D, draft-mglt-ipsecme-clone-ike-sa-01.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-ipsecme-clone-ike-sa Revision: 01 Title: Clone IKE SA Extension Document date: 2014-03-13 Group: Individual Submission Pages: 16 URL: http://www.ietf.org/internet-drafts/draft-mglt-ipsecme-clone-ike-sa-01.txt Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-ike-sa/ Htmlized: http://tools.ietf.org/html/draft-mglt-ipsecme-clone-ike-sa-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-clone-ike-sa-01 Abstract: This document considers a VPN End User setting a VPN with a security gateway where at least one of the peer has multiple interfaces. With the current IKEv2, the outer IP addresses of the VPN are determined by those used by IKEv2 channel. As a result using multiple interfaces requires to set an IKEv2 channel on each interface, or on each paths if both the VPN Client and the security gateway have multiple interfaces. Setting multiple IKEv2 channel involves multiple authentications which may each require multiple round trips and delay the VPN establishment. In addition multiple authentications unnecessarily increase load to the VPN client and the authentication infrastructure. This document presents the Clone IKE SA extension, where an additional IKEv2 channel is derived from an already authenticated IKEv2 channel. The newly created IKEv2 channel is set without the IKEv2 authentication exchange. The newly created IKEv2 channel can then be assigned to another interface using MOBIKE. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --001a113a42c6375cd004f63435df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Here is the last ver= sion of our draft on clone IKE_SA. The main goal is to be handle to handle = multiple interfaces. We believe this version -- the same as the one posted = on March 13 -- is closed to the final one as we have considered previous re= views.

We would like to have your feed backs, so we can move forward wit= h the draft. The draft is only 7 pages -- excluding the appendix --, so ple= ase consider reviewing it.

URL: http:/= /www.ietf.org/internet-drafts/draft-mglt-ipsecme-clone-ike-sa-01.txt Htmlized: http://tools.ietf.org/html/draft-mglt-ipsecme-cl= one-ike-sa-01

BR,
Daniel

---------- Forwarded message ----------=
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Thu, Mar 13, 2014 at 9:51 AM
Subject: Fwd: New Version Notificatio= n for draft-mglt-ipsecme-clone-ike-sa-01.txt
To: "ipsec@ietf.org" <ipsec@ietf.org>
Cc: Valery Smyslov <svanru@gmail.com= >


Hi,

Please find the new version for the clone IKE SA draft. This version
includes all comments we received. Feel free to let us know if there
are more comments to address.

BR,
Danie

Abstract:
=A0 =A0This document considers a VPN End User setting a VPN with a security=
=A0 =A0gateway where at least one of the peer has multiple interfaces.

=A0 =A0With the current IKEv2, the outer IP addresses of the VPN are
=A0 =A0determined by those used by IKEv2 channel. =A0As a result using
=A0 =A0multiple interfaces requires to set an IKEv2 channel on each
=A0 =A0interface, or on each paths if both the VPN Client and the security<= br> =A0 =A0gateway have multiple interfaces. =A0Setting multiple IKEv2 channel<= br> =A0 =A0involves multiple authentications which may each require multiple =A0 =A0round trips and delay the VPN establishment. =A0In addition multiple=
=A0 =A0authentications unnecessarily increase load to the VPN client and th= e
=A0 =A0authentication infrastructure.

=A0 =A0This document presents the Clone IKE SA extension, where an
=A0 =A0additional IKEv2 channel is derived from an already authenticated =A0 =A0IKEv2 channel. =A0The newly created IKEv2 channel is set without the=
=A0 =A0IKEv2 authentication exchange. =A0The newly created IKEv2 channel ca= n
=A0 =A0then be assigned to another interface using MOBIKE.




-------- Original Message --------
Subject: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-01.tx= t
Date: Thu, 13 Mar 2014 01:43:41 -0700
From: <internet-drafts@ietf.= org>
To: Valery Smyslov <svan@elvis.ru&g= t;, Valery Smyslov <svan@elvis.ru&g= t;,
"Daniel Migault" <daniel.migault@orange.com>, Daniel Migault
<daniel.migault@orange.com<= /a>>


A new version of I-D, draft-mglt-ipsecme-clone-ike-sa-01.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Name: draft-mglt-ipsecme-clone-ike-sa
Revision: 01
Title: Clone IKE SA Extension
Document date: 2014-03-13
Group: Individual Submission
Pages: 16
URL:
http://www.ietf.org/internet-drafts/draft-mgl= t-ipsecme-clone-ike-sa-01.txt
Status:
https://datatracker.ietf.org/doc/draft-mglt-ipsecme-cl= one-ike-sa/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-mgl= t-ipsecme-clone-ike-sa-01
Diff:
http://www.ietf.org/rfcdiff?url2=3Ddraft-mglt-ipse= cme-clone-ike-sa-01

Abstract:
=A0 =A0This document considers a VPN End User setting a VPN with a security=
=A0 =A0gateway where at least one of the peer has multiple interfaces.

=A0 =A0With the current IKEv2, the outer IP addresses of the VPN are
=A0 =A0determined by those used by IKEv2 channel. =A0As a result using
=A0 =A0multiple interfaces requires to set an IKEv2 channel on each
=A0 =A0interface, or on each paths if both the VPN Client and the security<= br> =A0 =A0gateway have multiple interfaces. =A0Setting multiple IKEv2 channel<= br> =A0 =A0involves multiple authentications which may each require multiple =A0 =A0round trips and delay the VPN establishment. =A0In addition multiple=
=A0 =A0authentications unnecessarily increase load to the VPN client and th= e
=A0 =A0authentication infrastructure.

=A0 =A0This document presents the Clone IKE SA extension, where an
=A0 =A0additional IKEv2 channel is derived from an already authenticated =A0 =A0IKEv2 channel. =A0The newly created IKEv2 channel is set without the=
=A0 =A0IKEv2 authentication exchange. =A0The newly created IKEv2 channel ca= n
=A0 =A0then be assigned to another interface using MOBIKE.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




--
Daniel Migault
Orange Labs -- Security
+33 6 = 70 72 69 58



--
Daniel Migault
Oran= ge Labs -- Security
+33 6 70 72 69 58
--001a113a42c6375cd004f63435df-- From nobody Fri Apr 4 08:43:15 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98ABE1A0235; Fri, 4 Apr 2014 08:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0GziIUowJmB; Fri, 4 Apr 2014 08:43:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C471A0152; Fri, 4 Apr 2014 08:43:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140404154308.32686.39942.idtracker@ietfa.amsl.com> Date: Fri, 04 Apr 2014 08:43:08 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/aUtLaK9QiXDWhB8ai7vYtQ8eC48 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 15:43:12 -0000 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 : IKEv2 Fragmentation Author : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-fragmentation-07.txt Pages : 23 Date : 2014-04-04 Abstract: This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 4 08:53:19 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7621A01F0 for ; Fri, 4 Apr 2014 08:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrKIGBkNQiWg for ; Fri, 4 Apr 2014 08:53:13 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9441A01C6 for ; Fri, 4 Apr 2014 08:53:12 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id 10so2639524lbg.35 for ; Fri, 04 Apr 2014 08:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=4kNsjB4dLLoDuUxXCcn6xyViOy+0tq3G8QjMM1IlZ2Y=; b=v9ULqFq1fZnR4/rzqgsamEYu5vVwMq5vOexQt+kczXfevHEQ/boxNdoafQI65mkiZt ggwKpSaLWXwUbX9iNRqhfMo4CAa5Cs7YgPWx2lvWywUxO+R9IfMDnt0R4b6H9h9srcR1 rZKHVZ3OXGGzv9GVXKcmAvbe5xWsn7hLsvFhP5FprVAx7tEMNWcet+SqjH1EZp63M5Ue gSdG0DNql3YfFxbKbOTlT+MlTV2gvuyRR4nMgKk6jT0LFoD1OR8u+9HdQLbYIHTNBZDh Q23KBgTG8QHgXXPQfVSSFQPWzdCOVTJ186TqBazEc8ml4JydiRpzWfGSV/F8XlNfS5l+ /6EQ== X-Received: by 10.112.85.6 with SMTP id d6mr8848067lbz.8.1396626787940; Fri, 04 Apr 2014 08:53:07 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id z10sm5919224lbu.1.2014.04.04.08.53.06 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 04 Apr 2014 08:53:07 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: References: <20140404154308.32686.39942.idtracker@ietfa.amsl.com> Date: Fri, 4 Apr 2014 19:53:05 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/EEbLMVuqZ59mz2vovk_J_qvN1OY Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 15:53:17 -0000 Hi all, the Security Considerations section of the draft is updated after discussion with Derek Atkins. Regards, Valery. ----- Original Message ----- From: To: Cc: Sent: Friday, April 04, 2014 7:43 PM Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-07.txt > > 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 : IKEv2 Fragmentation > Author : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-fragmentation-07.txt > Pages : 23 > Date : 2014-04-04 > > Abstract: > This document describes the way to avoid IP fragmentation of large > IKEv2 messages. This allows IKEv2 messages to traverse network > devices that don't allow IP fragments to pass through. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-07 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-07 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Apr 4 13:27:58 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5B61A05C3; Fri, 4 Apr 2014 13:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeeKJHow9xus; Fri, 4 Apr 2014 13:27:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 331C31A010C; Fri, 4 Apr 2014 13:27:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140404202750.31367.2461.idtracker@ietfa.amsl.com> Date: Fri, 04 Apr 2014 13:27:50 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/D58pilQRIZ9UYwZuvxVLLTy31Gw Cc: ipsec@ietf.org Subject: [IPsec] Last Call: (Internet Key Exchange Protocol Version 2 (IKEv2)) to Internet Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 20:27:54 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Internet Key Exchange Protocol Version 2 (IKEv2)' as Internet Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-04-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document replaces and updates RFC 5996, and includes all of the errata for it, and it is intended to update IKEv2 to be Internet Standard. The file can be obtained via http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Apr 4 14:43:22 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A57B1A012E for ; Fri, 4 Apr 2014 14:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dtiv6o0BczuS for ; Fri, 4 Apr 2014 14:43:13 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id C557B1A00EC for ; Fri, 4 Apr 2014 14:43:13 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 22F69813B1 for ; Fri, 4 Apr 2014 17:43:07 -0400 (EDT) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s34Lh6RZ022009 for ; Fri, 4 Apr 2014 17:43:06 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 4 Apr 2014 17:43:06 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/oE7P2-hl_FVPanWnRfIWJ2LiC24 Subject: [IPsec] Question on IPSEC Identification Type" registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 21:43:18 -0000 According to RFC 3554 (SCTP with IPsec): IANA has assigned number 12 for ID_LIST (defined in Section 3) in the "IPSEC Identification Type" registry which matches: http://www.iana.org/assignments/isakmp-registry/isakmp-registry.xhtml#isakmp-registry-31 But for IKEv2 we have: http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-10 12 ID_FC_NAME [RFC4595] (IKEv2 values for Fibre Channel) which on top of that is also not a real IKE value... I guess I'm not the first to run into this. Angelos ran into this in 2003: http://www.vpnc.org/ietf-ipsec/03.ipsec/msg01723.html I'm not sure how one conveys ID_LIST for SCTP in IKEv2. But perhaps no one really cared to fix this? (I don't) I guess at this point there is nothing much to do, possible add a warning note to the IANA registries for implementors.... I wish we could have kept these two registries more in sync..... Paul, off to split v1 and v2 versions of this now From nobody Mon Apr 7 05:20:44 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6242C1A03DB for ; Mon, 7 Apr 2014 05:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osQxcHLTaen5 for ; Mon, 7 Apr 2014 05:20:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1961A03D4 for ; Mon, 7 Apr 2014 05:20:36 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s37CKLwv029857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Apr 2014 15:20:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s37CKLZ8010161; Mon, 7 Apr 2014 15:20:21 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21314.38916.998882.266783@fireball.kivinen.iki.fi> Date: Mon, 7 Apr 2014 15:20:20 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 18 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/lVjpgM-hziqW9Kot0GHqK0uTAb0 Cc: "ipsec@ietf.org WG" Subject: [IPsec] Question on IPSEC Identification Type" registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 12:20:43 -0000 Paul Wouters writes: > > According to RFC 3554 (SCTP with IPsec): > > IANA has assigned number 12 for ID_LIST (defined in Section 3) in the > "IPSEC Identification Type" registry > > which matches: > > http://www.iana.org/assignments/isakmp-registry/isakmp-registry.xhtml#isakmp-registry-31 Yes, RFC 3554 is only for IKEv1. > But for IKEv2 we have: > > http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-10 > > 12 ID_FC_NAME [RFC4595] (IKEv2 values for Fibre Channel) > > which on top of that is also not a real IKE value... There is no need for ID_LIST in the IKEv2. First of all the ID_LIST is only meant to be used as traffic selector not Identity. In the IKEv1 the ID payloads had dual role for both Identity for the authentication (IDii, IDir) and the traffic selectors for the quick mode (IDci, IDcr). In IKEv2 we have separated these two uses for separate payloads, i.e. the ID payloads only act as Identity for authentication and the traffic selectors are used to tell which traffic is protected. Traffic selector payloads already support lists of traffic selectors, so there is no problem. The ID payload used in the authentication requires on identity but that usually is not a problem either, as the peer can use FQDN or similar for their identity instead of using list of IP addresses. > I guess I'm not the first to run into this. Angelos ran into this in > 2003: http://www.vpnc.org/ietf-ipsec/03.ipsec/msg01723.html This was way before the IKEv2 was even finished, and we did discuss it at the time and tried to make sure the IKEv2 supports ways of doing that. I do not know if people have actually implemented SCTP protected over IPsec in host to host mode (this problem does not really exists in the tunnel mode, or VPNs etc). > I'm not sure how one conveys ID_LIST for SCTP in IKEv2. But perhaps no > one really cared to fix this? (I don't) In traffic selectors just include all addresses in the traffic selectors. In the ID payload, just use some other identity than list of IP-addresses. > I guess at this point there is nothing much to do, possible add a > warning note to the IANA registries for implementors.... Why? Those two registries are different and the other protocol is even obsoleted... :-) > I wish we could have kept these two registries more in sync..... I agree that we most likely should have marked ID 12 as reserved as we did for all other IKEv1 ID payloads which are not applicable for IKEv2. > Paul, off to split v1 and v2 versions of this now You should have done that earlier already... the registries are different and there are other differences too. Also there is differences between the ipsec-registry and isakmp-registry too (for example the encryption algorithm of 8 is either CAMELLIA-CBC, or ESP_3IDEA). -- kivinen@iki.fi From nobody Fri Apr 11 12:09:33 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701141A02C2; Fri, 11 Apr 2014 12:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHL_x2ncreKd; Fri, 11 Apr 2014 12:09:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B045B1A0327; Fri, 11 Apr 2014 12:09:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140411190930.13415.44794.idtracker@ietfa.amsl.com> Date: Fri, 11 Apr 2014 12:09:30 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/eOiiz5Yrm_Jediq1iuRqT8zMYZU Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:09:32 -0000 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 : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : David McGrew Paul Hoffman Filename : draft-ietf-ipsecme-esp-ah-reqts-05.txt Pages : 11 Date : 2014-04-11 Abstract: This Internet Draft is standards track proposal to update to the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols makes use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-esp-ah-reqts-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 11 12:23:05 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF06C1A035F for ; Fri, 11 Apr 2014 12:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TsB93g43Fi4 for ; Fri, 11 Apr 2014 12:22:56 -0700 (PDT) Received: from mx5.gridway.net (mx5.gridway.net [72.1.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id 210791A074B for ; Fri, 11 Apr 2014 12:22:53 -0700 (PDT) Received: from delivery.mygridway.net (delivery.mygridway.net [72.1.205.180]) by mx5.gridway.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id s3BJMoiS022995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 11 Apr 2014 15:22:51 -0400 Received: from [10.8.0.179] (24.114.47.98) by delivery.mygridway.net (172.17.12.4) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 11 Apr 2014 15:22:50 -0400 Message-ID: <53484109.30802@elliptictech.com> Date: Fri, 11 Apr 2014 15:22:49 -0400 From: Michael Bowler User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 To: References: <20140411190930.13415.44794.idtracker@ietfa.amsl.com> In-Reply-To: <20140411190930.13415.44794.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [24.114.47.98] X-CanIt-Geo: ip=72.1.205.180; country=CA; region=Ontario; city=Ottawa; latitude=45.4167; longitude=-75.7000; http://maps.google.com/maps?q=45.4167,-75.7000&z=6 X-CanItPRO-Stream: base:outbound (inherits from base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 72.1.205.140 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/mdmIOIpFJqf2Eqdes0wJzzlZfo4 Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:23:01 -0000 Just a quick glance, but I see AES-GCM as a SHOULD+ in the AH section. The reference RFC4106 only applies to ESP. The AES-GMAC (RFC4543) requirement makes sense. Regards, Michael -- Michael Bowler mbowler@elliptictech.com Sr. IC Designer/Architect (613) 254-5456x107 Elliptic Technologies Inc. www.elliptictech.com From nobody Fri Apr 11 12:26:48 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9F71A075C for ; Fri, 11 Apr 2014 12:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUliyNTmR2xe for ; Fri, 11 Apr 2014 12:26:45 -0700 (PDT) Received: from mx5.gridway.net (mx5.gridway.net [72.1.205.140]) by ietfa.amsl.com (Postfix) with ESMTP id 655571A0737 for ; Fri, 11 Apr 2014 12:26:45 -0700 (PDT) Received: from delivery.mygridway.net (delivery.mygridway.net [72.1.205.180]) by mx5.gridway.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id s3BJQhwA023610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 11 Apr 2014 15:26:43 -0400 Received: from [10.8.0.179] (24.114.47.98) by delivery.mygridway.net (172.17.12.4) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 11 Apr 2014 15:26:42 -0400 Message-ID: <534841F2.8020304@elliptictech.com> Date: Fri, 11 Apr 2014 15:26:42 -0400 From: Michael Bowler User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 SeaMonkey/2.25 MIME-Version: 1.0 To: References: <20140411190930.13415.44794.idtracker@ietfa.amsl.com> <53484109.30802@elliptictech.com> In-Reply-To: <53484109.30802@elliptictech.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [24.114.47.98] X-CanIt-Geo: ip=72.1.205.180; country=CA; region=Ontario; city=Ottawa; latitude=45.4167; longitude=-75.7000; http://maps.google.com/maps?q=45.4167,-75.7000&z=6 X-CanItPRO-Stream: base:outbound (inherits from base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 72.1.205.140 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/zFUvWmmQplNE1p9HsjZqkjQydEc Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 19:26:46 -0000 Sorry, ignore that last comment... I mentally merged the table in 2.5 into section 2.4. Michael Bowler wrote: > Just a quick glance, but I see AES-GCM as a SHOULD+ in the AH section. > The reference RFC4106 only applies to ESP. The AES-GMAC (RFC4543) > requirement makes sense. > > Regards, > > Michael > -- Michael Bowler mbowler@elliptictech.com Sr. IC Designer/Architect (613) 254-5456x107 Elliptic Technologies Inc. www.elliptictech.com From nobody Thu Apr 17 10:23:29 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379BD1A0214; Thu, 17 Apr 2014 10:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrzxdEas0Ufi; Thu, 17 Apr 2014 10:23:22 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC301A0135; Thu, 17 Apr 2014 10:23:22 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s3HHNHN1025666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Apr 2014 12:23:18 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s3HHNGs8019997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 19:23:16 +0200 Received: from FR711WXCHMBA01.zeu.alcatel-lucent.com ([169.254.1.223]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 17 Apr 2014 19:23:16 +0200 From: "PUTMAN, Tony (Tony)" To: "ietf@ietf.org" Thread-Topic: [IPsec] Last Call: (Internet Key Exchange Protocol Version 2 (IKEv2)) to Internet Standard Thread-Index: AQHPUER+0n62SMALMEq7nBB2qf17BpsWIUEw Date: Thu, 17 Apr 2014 17:23:15 +0000 Message-ID: <14BE57EA00BC0C469E17B5AD698FE67766664CE4@FR711WXCHMBA01.zeu.alcatel-lucent.com> References: <20140404202750.31367.2461.idtracker@ietfa.amsl.com> In-Reply-To: <20140404202750.31367.2461.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/sidslir59HBKM3LqoecDaA4SBVc Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Last Call: (Internet Key Exchange Protocol Version 2 (IKEv2)) to Internet Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 17:23:25 -0000 All, In section 3.6 (top of page 94), there is the statement, "If multiple certificates are sent, the first certificate MUST contain the public key used to sign the AUTH payload." "sign" should be "validate". Regards, Tony -- Tony Putman Alcatel-Lucent Technologies -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of The IESG Sent: Friday, April 04, 2014 9:28 PM To: IETF-Announce Cc: ipsec@ietf.org Subject: [IPsec] Last Call: = (Internet Key Exchange Protocol Version 2 (IKEv2)) to Internet Standard The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Internet Key Exchange Protocol Version 2 (IKEv2)' as Internet Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-04-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document replaces and updates RFC 5996, and includes all of the errata for it, and it is intended to update IKEv2 to be Internet Standard. The file can be obtained via http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/ball= ot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Apr 17 10:42:44 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2728E1A017C; Thu, 17 Apr 2014 10:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTYpQGp48fjk; Thu, 17 Apr 2014 10:42:31 -0700 (PDT) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 560D51A0169; Thu, 17 Apr 2014 10:42:31 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id d49so928069eek.27 for ; Thu, 17 Apr 2014 10:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1Ca6BxJo3tE1mncnJkM+vZt51+XtswwzjUKrFM3ZzR8=; b=zhKZc+busMIG9OibELkbLk5YiuXVhYUSCkorv76ndogDVhRHDtxBmW3vpVM7emZA/5 XFp90RI0wv09Z/2mx+lGx23tpJg9EK9BWthYId1OkZ4QLaYxy1K/AA2NeEabP0iKE8F5 l61ve2ZcR3BACwAoyav+1iajIAACCuhtgTK7sQBPCtKlzFNU7P4zhbMWgJSJxu0xApP6 YpUK/Uff3/Pp99brCIpaMZ3aI2jJm3dvqiGTctmsWqk/bYqYTNHiuaglWS99XA1nw0dQ sXb2ibXP8LgfYKATrmdqiGiekrjraKhm+MVoWOWlXmT2QgTO0jvVUN4Cqrn15Or1O1VC vFfg== X-Received: by 10.14.241.139 with SMTP id g11mr15808458eer.49.1397756547023; Thu, 17 Apr 2014 10:42:27 -0700 (PDT) Received: from [192.168.1.101] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id w1sm69218854eel.16.2014.04.17.10.42.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Apr 2014 10:42:26 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: <14BE57EA00BC0C469E17B5AD698FE67766664CE4@FR711WXCHMBA01.zeu.alcatel-lucent.com> Date: Thu, 17 Apr 2014 20:42:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140404202750.31367.2461.idtracker@ietfa.amsl.com> <14BE57EA00BC0C469E17B5AD698FE67766664CE4@FR711WXCHMBA01.zeu.alcatel-lucent.com> To: "PUTMAN, Tony (Tony)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/LbZWeXo4OhwZJS-BnjVcT0hFYWc Cc: "ipsec@ietf.org" , "ietf@ietf.org" Subject: Re: [IPsec] Last Call: (Internet Key Exchange Protocol Version 2 (IKEv2)) to Internet Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 17:42:36 -0000 Hi, Tony Thanks for the review. I assume you mean that you don=92t sign with public keys. Replacing = =93sign=94 with =93validate=94 makes for a strange sentence, because the = sentence is about sending (and presumably signing) rather than receiving = (and validating). How about: =93If multiple certificate are sent, the first MUST contain the public = key associated with the private key used to sign the AUTH payload=94 Yoav On Apr 17, 2014, at 8:23 PM, PUTMAN, Tony (Tony) = wrote: > All, >=20 > In section 3.6 (top of page 94), there is the statement, > "If multiple certificates > are sent, the first certificate MUST contain the public key used to > sign the AUTH payload." >=20 > "sign" should be "validate". >=20 > Regards, > Tony > -- > Tony Putman > Alcatel-Lucent Technologies >=20 > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of The IESG > Sent: Friday, April 04, 2014 9:28 PM > To: IETF-Announce > Cc: ipsec@ietf.org > Subject: [IPsec] Last Call: = (Internet Key Exchange = Protocol Version 2 (IKEv2)) to Internet Standard >=20 >=20 > The IESG has received a request from the IP Security Maintenance and > Extensions WG (ipsecme) to consider the following document: > - 'Internet Key Exchange Protocol Version 2 (IKEv2)' > as Internet Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-04-18. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document describes version 2 of the Internet Key Exchange (IKE) > protocol. IKE is a component of IPsec used for performing mutual > authentication and establishing and maintaining Security = Associations > (SAs). This document replaces and updates RFC 5996, and includes = all > of the errata for it, and it is intended to update IKEv2 to be > Internet Standard. >=20 >=20 >=20 >=20 > The file can be obtained via > = http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/ >=20 > IESG discussion can be tracked via > = http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/bal= lot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Apr 17 15:28:37 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F34D1A00E6 for ; Thu, 17 Apr 2014 15:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kgw59-1ovGWv for ; Thu, 17 Apr 2014 15:28:31 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3161A0078 for ; Thu, 17 Apr 2014 15:28:30 -0700 (PDT) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd03.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3HMSOl4023538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Apr 2014 18:28:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s3HMSOl4023538 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1397773705; bh=qNq33BZF9IH+jPil6NvjyOa7yR8=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=vKuZlQNWw8g6+PtKiQzfX5OcrwRFVj3Ci25u03/M6xI1ZbfetKjGQGKMwuBXCXkpo KTU+F4wgE/lZIhLg78zYKIDaGudY7P2EI87RUq6THxu7pr0zkEtgJMbY3LETadbRaZ rqk2sqwZclL7p2hBXwmZQCc+vh1s4s+YXla6lcFQ= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd03.lss.emc.com s3HMSOl4023538 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd02.lss.emc.com (RSA Interceptor); Thu, 17 Apr 2014 18:28:18 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3HMSITP009153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Apr 2014 18:28:18 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Thu, 17 Apr 2014 18:28:18 -0400 From: "Black, David" To: "Rajeshwar Singh Jenwar (rsj)" , "IPsecme WG (ipsec@ietf.org)" Date: Thu, 17 Apr 2014 18:28:16 -0400 Thread-Topic: New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt Thread-Index: AQHPPeiOOW5BcXLSBkueOTatW1ZDU5reSmmggDhQuBA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C2EC424@MX15A.corp.emc.com> References: <20140312114328.20101.44457.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ZN1HRcALb62s9icy-TZJXEBqjNY Subject: Re: [IPsec] New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 22:28:35 -0000 Well, Joe Touch's comments on congestion still apply: http://www.ietf.org/mail-archive/web/ipsec/current/msg08654.html I suggest consulting RFC 5405 on this topic, and applying its guidance. Thanks, --David > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Rajeshwar Singh > Jenwar (rsj) > Sent: Wednesday, March 12, 2014 10:27 PM > To: IPsecme WG (ipsec@ietf.org) > Subject: [IPsec] FW: New Version Notification for draft-amjads-ipsecme-ik= ev2- > data-channel-01.txt >=20 > Hi, >=20 > We (Amjad and I) have published new version of "Data over IKEv2 for > application security" draft based on inputs/comments received. > Please review and provide comments/inputs/questions. >=20 > Kind Regards, > Raj >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, March 12, 2014 5:13 PM > To: Amjad Inamdar (amjads); Rajeshwar Singh Jenwar (rsj); Rajeshwar Singh > Jenwar (rsj); Amjad Inamdar (amjads) > Subject: New Version Notification for draft-amjads-ipsecme-ikev2-data-cha= nnel- > 01.txt >=20 >=20 > A new version of I-D, draft-amjads-ipsecme-ikev2-data-channel-01.txt > has been successfully submitted by Amjad S. Inamdar and posted to the IET= F > repository. >=20 > Name: draft-amjads-ipsecme-ikev2-data-channel > Revision: 01 > Title: IKEv2 based lightweight secure data communication draft- > amjads-ipsecme-ikev2-data-channel-01 (D-IKE) > Document date: 2014-03-12 > Group: Individual Submission > Pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-amjads-ipsecme- > ikev2-data-channel-01.txt > Status: https://datatracker.ietf.org/doc/draft-amjads-ipsecme-ike= v2- > data-channel/ > Htmlized: http://tools.ietf.org/html/draft-amjads-ipsecme-ikev2-dat= a- > channel-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-amjads-ipsecme-i= kev2- > data-channel-01 >=20 > Abstract: > The Internet Key Exchange (IKEv2) protocol provides authentication, > confidentiality, integrity, data-origin authentication and anti- > replay. Currently, IKEv2 is mainly used as a control channel to > negotiate IPsec SA(s). IPsec is not well suited to provide transport > layer security for applications as it resides at the network layer > and most of the IPsec implementations require integration into > operating systems making it difficult to deploy. IPsec uses > different sessions for control and data traffic which is not NAT and > load balancer friendly. TLS/DTLS, the other popular security > mechanism to provide the above security services does not mandate > mutual peer authentication and Diffie Hellman exchange. >=20 > This document describes an IKEv2 based lightweight secure data > communication protocol and a way to provide transport layer security > for UDP client/server applications. The protocol provides integrity > protected encryption and integrity-only protection based on > application needs. As most of the IoT applications are UDP based, > IKEv2 can be used for key management as well secure data > communication in IoT due to its simplicity, scalability, > lightweightedness and ease of deployment. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Apr 18 14:29:04 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FDA1A04CA; Fri, 18 Apr 2014 14:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id za0oDwEw2pVQ; Fri, 18 Apr 2014 14:29:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 425C81A01CB; Fri, 18 Apr 2014 14:29:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140418212900.8085.86263.idtracker@ietfa.amsl.com> Date: Fri, 18 Apr 2014 14:29:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/RwTv0Uk5zUKKzf4CgpLVbIL90Uc Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 21:29:01 -0000 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 : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : David McGrew Paul Hoffman Filename : draft-ietf-ipsecme-esp-ah-reqts-06.txt Pages : 11 Date : 2014-04-18 Abstract: This Internet Draft is standards track proposal to update to the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols makes use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. This document obsoletes RFC 4835. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-esp-ah-reqts-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 18 14:40:18 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB841A02D8; Fri, 18 Apr 2014 14:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM421DTp7Pug; Fri, 18 Apr 2014 14:40:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3781A007B; Fri, 18 Apr 2014 14:40:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140418214012.9776.90655.idtracker@ietfa.amsl.com> Date: Fri, 18 Apr 2014 14:40:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/0LebMw2Pqy1_mJFPv0KQ6Kn-74U Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 21:40:14 -0000 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 : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : David McGrew Paul Hoffman Filename : draft-ietf-ipsecme-esp-ah-reqts-07.txt Pages : 11 Date : 2014-04-18 Abstract: This Internet Draft is a standards track proposal to update the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. This document obsoletes RFC 4835. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-esp-ah-reqts-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 18 14:49:16 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E44931A03BE; Fri, 18 Apr 2014 14:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI8i1Ko9OJOG; Fri, 18 Apr 2014 14:49:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0A21A011C; Fri, 18 Apr 2014 14:49:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140418214912.8876.30442.idtracker@ietfa.amsl.com> Date: Fri, 18 Apr 2014 14:49:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/XzWaLGviVm-IZqf_dDsN_kFJW5o Cc: ipsec@ietf.org Subject: [IPsec] Last Call: (Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2014 21:49:14 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-05-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This Internet Draft is a standards track proposal to update the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. This document obsoletes RFC 4835. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Apr 20 08:32:01 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73CC1A001A for ; Sun, 20 Apr 2014 08:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhoCRNInBIB8 for ; Sun, 20 Apr 2014 08:31:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 11BD41A0010 for ; Sun, 20 Apr 2014 08:31:59 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3KFVqnK026147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 20 Apr 2014 08:31:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <59E0CE07-0523-4608-AFDE-C5E6F92CAB18@vpnc.org> Date: Sun, 20 Apr 2014 08:31:51 -0700 To: IPsec ME WG List Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/u1tu3uwNGbwSobSJXSNdBU7zNFA Subject: [IPsec] Seeking a volunteer to help move draft-kivinen-ipsecme-signature-auth with a copy edit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Apr 2014 15:32:00 -0000 Greetings again. We finished WG Last Call on = draft-kivinen-ipsecme-signature-auth a while ago, but as our Area = Director was reading it, she found some wording problems that were = significant enough for her to want to hold it back for an editing pass. = For example, there are places where singular and plurals are mixed up, = or words are repeated in a sentence, in a way that someone doing an IETF = Last Call might be confused. The chairs are seeking a volunteer to copy edit the draft. This could be = a great way for someone who wants to participate in the WG to contribute = to our work without having to write a protocol or even code one up. Part = of the work of the IETF is development of protocols, but another part is = moving those protocols forwards in a way where everyone can use them; = this request falls into the latter category. Please reply to me off-list if you're willing to help the WG and take = this on. I suspect this task would take at most only a few hours. --Paul Hoffman= From nobody Mon Apr 21 15:48:43 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AAF1A02DC for ; Mon, 21 Apr 2014 15:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtTjP3bq1ZZi for ; Mon, 21 Apr 2014 15:48:39 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC8F1A0067 for ; Mon, 21 Apr 2014 15:48:39 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s3LMmVp4092340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 21 Apr 2014 15:48:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <59E0CE07-0523-4608-AFDE-C5E6F92CAB18@vpnc.org> Date: Mon, 21 Apr 2014 15:48:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9957B93D-A7DC-4B57-9B94-37D82A928BE1@vpnc.org> References: <59E0CE07-0523-4608-AFDE-C5E6F92CAB18@vpnc.org> To: IPsec ME WG List X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/0hZihmI_NlK2EUvbXa1em_dbTd0 Subject: Re: [IPsec] Seeking a volunteer to help move draft-kivinen-ipsecme-signature-auth with a copy edit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Apr 2014 22:48:39 -0000 Thanks for the many offers! I accepted one and he has already finished = the task. Again, this WG works best when there are lots of volunteers for doing = things like reviews. Please keep this in mind when Yaron and I ask for = volunteers in the future. --Paul Hoffman= From nobody Tue Apr 22 02:57:06 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45531A02D7; Tue, 22 Apr 2014 02:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uf7e3JXpFr_5; Tue, 22 Apr 2014 02:57:00 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id C08A91A01D9; Tue, 22 Apr 2014 02:56:55 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s3M9ulVi025546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Apr 2014 04:56:49 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s3M9ul0U008820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 22 Apr 2014 11:56:47 +0200 Received: from FR711WXCHMBA01.zeu.alcatel-lucent.com ([169.254.1.223]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 22 Apr 2014 11:56:47 +0200 From: "PUTMAN, Tony (Tony)" To: Yoav Nir Thread-Topic: [IPsec] Last Call: (Internet Key Exchange Protocol Version 2 (IKEv2)) to Internet Standard Thread-Index: AQHPUER+0n62SMALMEq7nBB2qf17BpsWIUEw///ldYCAB3nA4A== Date: Tue, 22 Apr 2014 09:56:46 +0000 Message-ID: <14BE57EA00BC0C469E17B5AD698FE67766664FCB@FR711WXCHMBA01.zeu.alcatel-lucent.com> References: <20140404202750.31367.2461.idtracker@ietfa.amsl.com> <14BE57EA00BC0C469E17B5AD698FE67766664CE4@FR711WXCHMBA01.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/t3KMpP4LXOYyEYGNwpwvIS7xcGA Cc: "ipsec@ietf.org" , "ietf@ietf.org" Subject: Re: [IPsec] Last Call: (Internet Key Exchange Protocol Version 2 (IKEv2)) to Internet Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 09:57:05 -0000 Hi Yoav, Yes, that's what I meant; your suggestion is fine with me. To be honest, I= wasn't sure whether this was a "substantive comment" or not, but the quest= ion was raised to me by a colleague and I thought that I should pass it on.= Apologies if my comment was too brief (and for the late follow-up). Tony -----Original Message----- From: Yoav Nir [mailto:ynir.ietf@gmail.com] Sent: Thursday, April 17, 2014 6:42 PM To: PUTMAN, Tony (Tony) Cc: ietf@ietf.org; ipsec@ietf.org Subject: Re: [IPsec] Last Call: (Internet Key Exchange Protocol Version 2 (IKEv2)) to Internet Standar= d Hi, Tony Thanks for the review. I assume you mean that you don=92t sign with public keys. Replacing =93sign= =94 with =93validate=94 makes for a strange sentence, because the sentence = is about sending (and presumably signing) rather than receiving (and valida= ting). How about: =93If multiple certificate are sent, the first MUST contain the public key = associated with the private key used to sign the AUTH payload=94 Yoav On Apr 17, 2014, at 8:23 PM, PUTMAN, Tony (Tony) wrote: > All, > > In section 3.6 (top of page 94), there is the statement, > "If multiple certificates > are sent, the first certificate MUST contain the public key used to > sign the AUTH payload." > > "sign" should be "validate". > > Regards, > Tony > -- > Tony Putman > Alcatel-Lucent Technologies > > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of The IESG > Sent: Friday, April 04, 2014 9:28 PM > To: IETF-Announce > Cc: ipsec@ietf.org > Subject: [IPsec] Last Call: (Internet Key Exchange Protocol Version 2 (IKEv2)) to Internet Standard > > > The IESG has received a request from the IP Security Maintenance and > Extensions WG (ipsecme) to consider the following document: > - 'Internet Key Exchange Protocol Version 2 (IKEv2)' > as Internet Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-04-18. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes version 2 of the Internet Key Exchange (IKE) > protocol. IKE is a component of IPsec used for performing mutual > authentication and establishing and maintaining Security Associations > (SAs). This document replaces and updates RFC 5996, and includes all > of the errata for it, and it is intended to update IKEv2 to be > Internet Standard. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/ba= llot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > 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 nobody Fri Apr 25 05:38:56 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5451A04B1; Fri, 25 Apr 2014 05:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQjRtYJ9fi1S; Fri, 25 Apr 2014 05:38:49 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB9D1A04A8; Fri, 25 Apr 2014 05:38:49 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.7) with ESMTP id s3PCbowj029281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Apr 2014 15:37:50 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.14.7/Submit) id s3PCbofu022482; Fri, 25 Apr 2014 15:37:50 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21338.22302.684230.594132@fireball.kivinen.iki.fi> Date: Fri, 25 Apr 2014 15:37:50 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <20140404202750.31367.2461.idtracker@ietfa.amsl.com> <14BE57EA00BC0C469E17B5AD698FE67766664CE4@FR711WXCHMBA01.zeu.alcatel-lucent.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Tvh0Nr121nObcO_7-il7WWi1iJc Cc: "ipsec@ietf.org" , "PUTMAN, Tony \(Tony\)" , "ietf@ietf.org" Subject: Re: [IPsec] Last Call: (Internet Key Exchange Protocol Version 2 (IKEv2)) to Internet Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 12:38:53 -0000 Yoav Nir writes: > I assume you mean that you don=E2=80=99t sign with public keys. Repla= cing > =E2=80=9Csign=E2=80=9D with =E2=80=9Cvalidate=E2=80=9D makes for a st= range sentence, because the > sentence is about sending (and presumably signing) rather than > receiving (and validating).=20 >=20 > How about: > =E2=80=9CIf multiple certificate are sent, the first MUST contain the= public > key associated with the private key used to sign the AUTH payload=E2=80= =9D=20 Changed text to : If multiple certificates are sent, the first certificate MUST contain the public key associated with the private key used to sign the AUTH payload. --=20 kivinen@iki.fi From nobody Fri Apr 25 05:43:43 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B4F1A04B8 for ; Fri, 25 Apr 2014 05:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2AkRwszvKHl for ; Fri, 25 Apr 2014 05:43:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 933E11A04B7 for ; Fri, 25 Apr 2014 05:43:39 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.7) with ESMTP id s3PChSAE015095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Apr 2014 15:43:28 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.14.7/Submit) id s3PChRTp007762; Fri, 25 Apr 2014 15:43:27 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21338.22639.519882.711032@fireball.kivinen.iki.fi> Date: Fri, 25 Apr 2014 15:43:27 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <21087.60447.758422.672867@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 4 min X-Total-Time: 3 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/LK6rDT2JprO_mNr2ckyE_8HTGLU Cc: "ipsec@ietf.org WG" Subject: [IPsec] RFC5996bis section 3.1 comment X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 12:43:42 -0000 I am making new version of the rfc5996bis, so going through old emails too... Paul Wouters writes: > On Thu, 17 Oct 2013, Tero Kivinen wrote: > > [forgive me if already reported] > > Section 3.1 states: > > o Major Version (4 bits) - Indicates the major version of the IKE > protocol in use. Implementations based on this version of IKE > MUST set the major version to 2. Implementations based on > previous versions of IKE and ISAKMP MUST set the major version to > --> 1. Implementations based on this version of IKE MUST reject or > ignore messages containing a version number greater than 2 with an > INVALID_MAJOR_VERSION notification message as described in Section > 2.5. > > The reading of "this version" on the line marked "-->" is a little > unclear. Does it refer to the previous sentence's version (version 1) > or this version as in "this document's" version (version 2). I suggest > replacing "this version" with "this document's version" Changed to: Major Version (4 bits) - Indicates the major version of the IKE protocol in use. Implementations based on this version of IKE MUST set the major version to 2. Implementations based on previous versions of IKE and ISAKMP MUST set the major version to 1. Implementations based on this document's version (version 2) of IKE MUST reject or ignore messages containing a version number greater than 2 with an INVALID_MAJOR_VERSION notification message as described in Section 2.5. > o Minor Version (4 bits) - Indicates the minor version of the IKE > protocol in use. Implementations based on this version of IKE > MUST set the minor version to 0. They MUST ignore the minor > version number of received messages. > > For the Major we tell what IKEv1 implementations should do. Why don't we > do that for the Minor as well? Suggested addition: > > Implementations based on the previous major version of IKE and > ISAKMP MUST set the minor version to 0 and reject or ignore > messages containing a minor version number greater than 0 with > an INVALID_MINOR_VERSION notification message. I do not think we want to specify how IKEv1 implementations needs to work. This is IKEv2, and as IKEv2 will ignore the minor version number, it does not matter what IKEv1 implementations do it, or how they sent it. The Major version number text was needed as implementations need to know how to differentiate IKEv1 and IKEv2, minor version number handling of IKEv1 does not matter for IKEv2 implementations. -- kivinen@iki.fi From nobody Fri Apr 25 06:10:13 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBF01A04C2; Fri, 25 Apr 2014 06:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUy-WX9I8Whd; Fri, 25 Apr 2014 06:10:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C2C1A01D4; Fri, 25 Apr 2014 06:10:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140425131001.3084.47438.idtracker@ietfa.amsl.com> Date: Fri, 25 Apr 2014 06:10:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Ihpdw9KOCNFEVUMDn3xvqBpadvs Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-kivinen-ipsecme-ikev2-rfc5996bis-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Apr 2014 13:10:04 -0000 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 : Internet Key Exchange Protocol Version 2 (IKEv2) Authors : Charlie Kaufman Paul Hoffman Yoav Nir Pasi Eronen Tero Kivinen Filename : draft-kivinen-ipsecme-ikev2-rfc5996bis-03.txt Pages : 139 Date : 2014-04-25 Abstract: This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it, and it is intended to update IKEv2 to be Internet Standard. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-rfc5996bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-kivinen-ipsecme-ikev2-rfc5996bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 29 23:52:45 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A1F1A6EE8 for ; Tue, 29 Apr 2014 23:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JqvHnaRdlSj for ; Tue, 29 Apr 2014 23:52:28 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id E50731A6EE5 for ; Tue, 29 Apr 2014 23:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4338; q=dns/txt; s=iport; t=1398840747; x=1400050347; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=VYlBsjWh5D4m/03/Rydmu0oPntMp4cfz4+IDY1Zx+Zo=; b=Cta1fsYsdpFjVmfrCNwchAgcjc8vArEJm8vBmrQ+329KYktFJxgWXK/7 GWhWEywCri6FRtk/Jdgi+TN3Qm/bZPVa27BG8sowcqm90OWNCCVEZr6an uPLZHamIZZQE0jZ7oZ+PJey0Jhia91tuX+dK9hFWpFdVimsrQH5VULPLC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsGANucYFOtJA2M/2dsb2JhbABZgwZPUQa9N4c5gSQWdIIlAQEBBAEBATcrCQkOBAIBCBEEAQELFAkHJwsUCQgCBAESCAGIOAgFyhYXjgABAR4zBQaDHoEVBJpfkS6DMYFyOQ X-IronPort-AV: E=Sophos;i="4.97,956,1389744000"; d="scan'208";a="321400129" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP; 30 Apr 2014 06:52:25 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s3U6qPDg016148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 06:52:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 01:52:25 -0500 From: "Amjad Inamdar (amjads)" To: "Black, David" , "Rajeshwar Singh Jenwar (rsj)" , "IPsecme WG (ipsec@ietf.org)" Thread-Topic: New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt Thread-Index: AQHPPeiO1qUsOYKQVUCWirQNN+fFNJren44AgDhRGQCAExQE0A== Date: Wed, 30 Apr 2014 06:52:25 +0000 Message-ID: <62922D1DB814EF458679925ECD8AA68D242A33ED@xmb-rcd-x10.cisco.com> References: <20140312114328.20101.44457.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076C2EC424@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712076C2EC424@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.65.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/12JCxosBeAU4PPEdKsIqsQlx_QA Subject: Re: [IPsec] New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 06:52:31 -0000 Hi David, In the new version (version 1) of the draft, unlike IKEv2 control packets t= he data packets are not acknowledged and hence the comments on congestion a= nd windowing no longer apply. Thanks, -Amjad -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Black, David Sent: Friday, April 18, 2014 3:58 AM To: Rajeshwar Singh Jenwar (rsj); IPsecme WG (ipsec@ietf.org) Subject: Re: [IPsec] New Version Notification for draft-amjads-ipsecme-ikev= 2-data-channel-01.txt Well, Joe Touch's comments on congestion still apply: http://www.ietf.org/mail-archive/web/ipsec/current/msg08654.html I suggest consulting RFC 5405 on this topic, and applying its guidance. Thanks, --David > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Rajeshwar=20 > Singh Jenwar (rsj) > Sent: Wednesday, March 12, 2014 10:27 PM > To: IPsecme WG (ipsec@ietf.org) > Subject: [IPsec] FW: New Version Notification for=20 > draft-amjads-ipsecme-ikev2- data-channel-01.txt >=20 > Hi, >=20 > We (Amjad and I) have published new version of "Data over IKEv2 for=20 > application security" draft based on inputs/comments received. > Please review and provide comments/inputs/questions. >=20 > Kind Regards, > Raj >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, March 12, 2014 5:13 PM > To: Amjad Inamdar (amjads); Rajeshwar Singh Jenwar (rsj); Rajeshwar=20 > Singh Jenwar (rsj); Amjad Inamdar (amjads) > Subject: New Version Notification for=20 > draft-amjads-ipsecme-ikev2-data-channel- > 01.txt >=20 >=20 > A new version of I-D, draft-amjads-ipsecme-ikev2-data-channel-01.txt > has been successfully submitted by Amjad S. Inamdar and posted to the=20 > IETF repository. >=20 > Name: draft-amjads-ipsecme-ikev2-data-channel > Revision: 01 > Title: IKEv2 based lightweight secure data communication draft- > amjads-ipsecme-ikev2-data-channel-01 (D-IKE) > Document date: 2014-03-12 > Group: Individual Submission > Pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-amjads-ipsecme- > ikev2-data-channel-01.txt > Status: https://datatracker.ietf.org/doc/draft-amjads-ipsecme-ike= v2- > data-channel/ > Htmlized: http://tools.ietf.org/html/draft-amjads-ipsecme-ikev2-dat= a- > channel-01 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-amjads-ipsecme-i= kev2- > data-channel-01 >=20 > Abstract: > The Internet Key Exchange (IKEv2) protocol provides authentication, > confidentiality, integrity, data-origin authentication and anti- > replay. Currently, IKEv2 is mainly used as a control channel to > negotiate IPsec SA(s). IPsec is not well suited to provide transport > layer security for applications as it resides at the network layer > and most of the IPsec implementations require integration into > operating systems making it difficult to deploy. IPsec uses > different sessions for control and data traffic which is not NAT and > load balancer friendly. TLS/DTLS, the other popular security > mechanism to provide the above security services does not mandate > mutual peer authentication and Diffie Hellman exchange. >=20 > This document describes an IKEv2 based lightweight secure data > communication protocol and a way to provide transport layer security > for UDP client/server applications. The protocol provides integrity > protected encryption and integrity-only protection based on > application needs. As most of the IoT applications are UDP based, > IKEv2 can be used for key management as well secure data > communication in IoT due to its simplicity, scalability, > lightweightedness and ease of deployment. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > 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 nobody Wed Apr 30 07:23:54 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68CD21A6FC2 for ; Wed, 30 Apr 2014 07:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.952 X-Spam-Level: X-Spam-Status: No, score=-4.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6P0oVdCvHg5v for ; Wed, 30 Apr 2014 07:23:50 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9E01A08F6 for ; Wed, 30 Apr 2014 07:23:50 -0700 (PDT) Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3UENl5x020275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Apr 2014 10:23:47 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s3UENl5x020275 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1398867827; bh=fELareLc2ec/wuJfcnL321A2Ecs=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=IM7djdvUk6zP/I38FqtBDWdhOG2y4xd44FZ90TpPwLUDo3NY18pynfOMQaWheIsJo fpfSwKAOLjBmWa36mVV8LjVMx4k2qHUgzaiDW1oVZ7NHa3WS05P4Qele/EpIoutXzx Gf+kfbm0fmbe0TdXJwpk2KfymMSpPUiThdltlo1k= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd53.lss.emc.com s3UENl5x020275 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd52.lss.emc.com (RSA Interceptor); Wed, 30 Apr 2014 10:23:30 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s3UENUDU017356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Apr 2014 10:23:30 -0400 Received: from mx15a.corp.emc.com ([169.254.1.64]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Wed, 30 Apr 2014 10:23:30 -0400 From: "Black, David" To: "Amjad Inamdar (amjads)" , "Rajeshwar Singh Jenwar (rsj)" , "IPsecme WG (ipsec@ietf.org)" Date: Wed, 30 Apr 2014 10:23:28 -0400 Thread-Topic: New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt Thread-Index: AQHPPeiO1qUsOYKQVUCWirQNN+fFNJren44AgDhRGQCAExQE0IAAfqug Message-ID: <8D3D17ACE214DC429325B2B98F3AE712076C43817A@MX15A.corp.emc.com> References: <20140312114328.20101.44457.idtracker@ietfa.amsl.com> <8D3D17ACE214DC429325B2B98F3AE712076C2EC424@MX15A.corp.emc.com> <62922D1DB814EF458679925ECD8AA68D242A33ED@xmb-rcd-x10.cisco.com> In-Reply-To: <62922D1DB814EF458679925ECD8AA68D242A33ED@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-vikXVyq4mC1X-xA3TfW9TKZbj0 Subject: Re: [IPsec] New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 14:23:52 -0000 Amjad, I'm sorry, but that would be incorrect; please read RFC 5405 and apply its = design guidance. Thanks, --David (Transport Directorate member and tsvwg WG co-chair) > -----Original Message----- > From: Amjad Inamdar (amjads) [mailto:amjads@cisco.com] > Sent: Wednesday, April 30, 2014 2:52 AM > To: Black, David; Rajeshwar Singh Jenwar (rsj); IPsecme WG (ipsec@ietf.or= g) > Subject: RE: New Version Notification for draft-amjads-ipsecme-ikev2-data= - > channel-01.txt >=20 > Hi David, >=20 > In the new version (version 1) of the draft, unlike IKEv2 control packets= the > data packets are not acknowledged and hence the comments on congestion an= d > windowing no longer apply. >=20 > Thanks, > -Amjad >=20 > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Black, David > Sent: Friday, April 18, 2014 3:58 AM > To: Rajeshwar Singh Jenwar (rsj); IPsecme WG (ipsec@ietf.org) > Subject: Re: [IPsec] New Version Notification for draft-amjads-ipsecme-ik= ev2- > data-channel-01.txt >=20 > Well, Joe Touch's comments on congestion still apply: >=20 > http://www.ietf.org/mail-archive/web/ipsec/current/msg08654.html >=20 > I suggest consulting RFC 5405 on this topic, and applying its guidance. >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Rajeshwar > > Singh Jenwar (rsj) > > Sent: Wednesday, March 12, 2014 10:27 PM > > To: IPsecme WG (ipsec@ietf.org) > > Subject: [IPsec] FW: New Version Notification for > > draft-amjads-ipsecme-ikev2- data-channel-01.txt > > > > Hi, > > > > We (Amjad and I) have published new version of "Data over IKEv2 for > > application security" draft based on inputs/comments received. > > Please review and provide comments/inputs/questions. > > > > Kind Regards, > > Raj > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Wednesday, March 12, 2014 5:13 PM > > To: Amjad Inamdar (amjads); Rajeshwar Singh Jenwar (rsj); Rajeshwar > > Singh Jenwar (rsj); Amjad Inamdar (amjads) > > Subject: New Version Notification for > > draft-amjads-ipsecme-ikev2-data-channel- > > 01.txt > > > > > > A new version of I-D, draft-amjads-ipsecme-ikev2-data-channel-01.txt > > has been successfully submitted by Amjad S. Inamdar and posted to the > > IETF repository. > > > > Name: draft-amjads-ipsecme-ikev2-data-channel > > Revision: 01 > > Title: IKEv2 based lightweight secure data communication draft- > > amjads-ipsecme-ikev2-data-channel-01 (D-IKE) > > Document date: 2014-03-12 > > Group: Individual Submission > > Pages: 15 > > URL: http://www.ietf.org/internet-drafts/draft-amjads-ipsecm= e- > > ikev2-data-channel-01.txt > > Status: https://datatracker.ietf.org/doc/draft-amjads-ipsecme-i= kev2- > > data-channel/ > > Htmlized: http://tools.ietf.org/html/draft-amjads-ipsecme-ikev2-d= ata- > > channel-01 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-amjads-ipsecme= -ikev2- > > data-channel-01 > > > > Abstract: > > The Internet Key Exchange (IKEv2) protocol provides authentication, > > confidentiality, integrity, data-origin authentication and anti- > > replay. Currently, IKEv2 is mainly used as a control channel to > > negotiate IPsec SA(s). IPsec is not well suited to provide transpor= t > > layer security for applications as it resides at the network layer > > and most of the IPsec implementations require integration into > > operating systems making it difficult to deploy. IPsec uses > > different sessions for control and data traffic which is not NAT and > > load balancer friendly. TLS/DTLS, the other popular security > > mechanism to provide the above security services does not mandate > > mutual peer authentication and Diffie Hellman exchange. > > > > This document describes an IKEv2 based lightweight secure data > > communication protocol and a way to provide transport layer security > > for UDP client/server applications. The protocol provides integrity > > protected encryption and integrity-only protection based on > > application needs. As most of the IoT applications are UDP based, > > IKEv2 can be used for key management as well secure data > > communication in IoT due to its simplicity, scalability, > > lightweightedness and ease of deployment. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > tools.ietf.org. > > > > The IETF Secretariat > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec