From ynir@checkpoint.com Thu Dec 8 01:55:55 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4778321F8AF9 for ; Thu, 8 Dec 2011 01:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAtZG1o7F-P0 for ; Thu, 8 Dec 2011 01:55:54 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 521E621F867F for ; Thu, 8 Dec 2011 01:55:53 -0800 (PST) X-CheckPoint: {4EE0887C-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pB89tq0n020397 for ; Thu, 8 Dec 2011 11:55:52 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 8 Dec 2011 11:55:52 +0200 From: Yoav Nir To: "'IPsecme WG'" Date: Thu, 8 Dec 2011 11:55:51 +0200 Thread-Topic: Large Scale VPN Thread-Index: Acy1j5kUEZ3r8hYNSW2+GCmXReGEjw== Message-ID: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 09:55:55 -0000 Hi all. The discussion has died down a bit, so I thought I'd chime in with proposed= charter text. What do people think of the following? The first paragraph = is taken from Steve's email of 18-Nov. Yoav In an environment with many IPsec gateways and remote clients that share an= established trust infrastructure (in a single administrative domain or acr= oss multiple domains), customers want to get on-demand mesh IPsec capabilit= y for efficiency. However, this cannot be feasibly accomplished only with t= oday's IPsec and IKE due to problems with address lookup, reachability, pol= icy configuration, etc. The IPsecME working group will handle this large scale VPN problem by deliv= ering the following: * The working group will create a problem statement document including use = cases, definitions and proper requirements for discovery and updates. This = document would be solution-agnostic. Should reach WG last call around Octob= er 2012. * The working group will review and help publish Informational documents de= scribing current vendor proprietary solutions. These should be ready for IE= TF last call by August 2012. * The working group will choose a common solution for the discovery and upd= ate problems that will satisfy the requirements in the problem statement do= cument. The working group may consider multiple proposals, and then choose = one to bring to the standards track.= From paul.hoffman@vpnc.org Thu Dec 8 08:04:07 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC50921F86A1 for ; Thu, 8 Dec 2011 08:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RTKaWDeuyAf for ; Thu, 8 Dec 2011 08:04:07 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C30F721F85FF for ; Thu, 8 Dec 2011 08:04:06 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pB8G45i5060404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 8 Dec 2011 09:04:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> Date: Thu, 8 Dec 2011 08:04:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> To: IPsecme WG X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 16:04:07 -0000 On Dec 8, 2011, at 1:55 AM, Yoav Nir wrote: > In an environment with many IPsec gateways and remote clients that = share an established trust infrastructure (in a single administrative = domain or across multiple domains), customers want to get on-demand mesh = IPsec capability for efficiency. However, this cannot be feasibly = accomplished only with today's IPsec and IKE due to problems with = address lookup, reachability, policy configuration, etc. I don't think "mesh" is a well-defined term here. How about = "point-to-point"? > The IPsecME working group will handle this large scale VPN problem by = delivering the following: >=20 > * The working group will create a problem statement document including = use cases, definitions and proper requirements for discovery and = updates. This document would be solution-agnostic. Should reach WG last = call around October 2012. >=20 > * The working group will review and help publish Informational = documents describing current vendor proprietary solutions. These should = be ready for IETF last call by August 2012. >=20 > * The working group will choose a common solution for the discovery = and update problems that will satisfy the requirements in the problem = statement document. The working group may consider multiple proposals, = and then choose one to bring to the standards track. We would need a deadline for the last item. I suggest "December 2013". --Paul Hoffman From pcclark@nps.edu Wed Dec 7 14:25:26 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D6A21F8B53 for ; Wed, 7 Dec 2011 14:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMOsT-FH8xia for ; Wed, 7 Dec 2011 14:25:25 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 82A3721F8B16 for ; Wed, 7 Dec 2011 14:25:25 -0800 (PST) X-ASG-Debug-ID: 1323296725-036c924cfe1162a0001-2ho77O Received: from gulfstream.ern.nps.edu (gulfstream.ern.nps.edu [172.20.24.113]) by mule.nps.edu with ESMTP id 7h2d4xo5ETg0ny2O for ; Wed, 07 Dec 2011 14:25:25 -0800 (PST) X-Barracuda-Envelope-From: pcclark@nps.edu Received: from A2045.local (172.20.109.138) by smtp.nps.edu (172.20.24.113) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 7 Dec 2011 14:25:24 -0800 Message-ID: <4EDFE7D4.2050802@nps.edu> Date: Wed, 7 Dec 2011 14:25:24 -0800 From: Paul Clark User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Content-Type: multipart/alternative; boundary="------------060704070705080407000808" X-ASG-Orig-Subj: IPsec MIB confusion X-Barracuda-Connect: gulfstream.ern.nps.edu[172.20.24.113] X-Barracuda-Start-Time: 1323296725 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.82427 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Mailman-Approved-At: Thu, 08 Dec 2011 08:32:34 -0800 Subject: [IPsec] IPsec MIB confusion X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2011 22:28:49 -0000 --------------060704070705080407000808 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit In section 5 of the IPsec Security Policy Database MIB (RFC 4807), it makes reference to the spdIpHeaderFilterTable object in the overview and the tutorial, but that table is not listed in the MIB definition in section 6.What am I missing? -Paul --------------060704070705080407000808 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit

In section 5 of the IPsec Security Policy Database MIB (RFC 4807), it makes reference to the spdIpHeaderFilterTable object in the overview and the tutorial, but that table is not listed in the MIB definition in section 6.  What am I missing?


-Paul

--------------060704070705080407000808-- From yaronf.ietf@gmail.com Thu Dec 8 10:14:39 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285A321F8B36 for ; Thu, 8 Dec 2011 10:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V0JKAy3WMZ4 for ; Thu, 8 Dec 2011 10:14:38 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A31721F8B37 for ; Thu, 8 Dec 2011 10:14:38 -0800 (PST) Received: by bkbzs8 with SMTP id zs8so2261278bkb.31 for ; Thu, 08 Dec 2011 10:14:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=umkzuSblIbGDHvUixW6oLjgiynziCptX8UjVWR622Ag=; b=TW3Sv5LacHEoNGS5uA2Gqf1SwWTNVsNI8JrQK7O8RSjiNUlk5w2X8W0lTaIKDKK/BW 3IjDYq6v3AtXKOvKk1zR/LD+fo8O+BJMUBswy8u85DZFkzCT0IU8wXMXAjc66b1mGfcP L41jjinHd2NkGPaUYwSSthCHuqqXgJAZZ76Lc= Received: by 10.204.154.7 with SMTP id m7mr1981783bkw.71.1323368077088; Thu, 08 Dec 2011 10:14:37 -0800 (PST) Received: from [10.0.0.6] (bzq-79-181-231-7.red.bezeqint.net. [79.181.231.7]) by mx.google.com with ESMTPS id h7sm4564489bkw.12.2011.12.08.10.14.34 (version=SSLv3 cipher=OTHER); Thu, 08 Dec 2011 10:14:36 -0800 (PST) Message-ID: <4EE0FE88.7070808@gmail.com> Date: Thu, 08 Dec 2011 20:14:32 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Paul Hoffman References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 18:14:39 -0000 We as a group can commit to deliverable #1 and #3 (problem statement and standardized solution). But deliverable #2 (vendor protocols) is mostly out of our hands. So before we approve this charter, I would like to hear from people that represent vendors that they can commit to publish such a draft for their favorite solution. With a mostly complete -00 draft in, say, 4/2012. Please respond to the list or privately to Paul and myself. Also, I suggest to replace the sentence "The working group may consider multiple proposals, and then choose one to bring to the standards track." by "The working group may standardize one of the vendor solutions, a combination of several, or a new protocol." The latter is clearer, at least to me. Thanks, Yaron On 12/08/2011 06:04 PM, Paul Hoffman wrote: > On Dec 8, 2011, at 1:55 AM, Yoav Nir wrote: > >> In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand mesh IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc. > I don't think "mesh" is a well-defined term here. How about "point-to-point"? > >> The IPsecME working group will handle this large scale VPN problem by delivering the following: >> >> * The working group will create a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. Should reach WG last call around October 2012. >> >> * The working group will review and help publish Informational documents describing current vendor proprietary solutions. These should be ready for IETF last call by August 2012. >> >> * The working group will choose a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may consider multiple proposals, and then choose one to bring to the standards track. > We would need a deadline for the last item. I suggest "December 2013". > > --Paul Hoffman > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Thu Dec 8 10:24:27 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0532521F8B86 for ; Thu, 8 Dec 2011 10:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRs-YJPJt4H1 for ; Thu, 8 Dec 2011 10:24:23 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2044921F8BA0 for ; Thu, 8 Dec 2011 10:24:23 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pB8IOKIN067019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Dec 2011 11:24:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Paul Hoffman In-Reply-To: <4EE0FE88.7070808@gmail.com> Date: Thu, 8 Dec 2011 10:24:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> <4EE0FE88.7070808@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1251.1) Cc: IPsecme WG Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 18:24:27 -0000 On Dec 8, 2011, at 10:14 AM, Yaron Sheffer wrote: > We as a group can commit to deliverable #1 and #3 (problem statement = and standardized solution). But deliverable #2 (vendor protocols) is = mostly out of our hands. So before we approve this charter, I would like = to hear from people that represent vendors that they can commit to = publish such a draft for their favorite solution. With a mostly complete = -00 draft in, say, 4/2012. Please respond to the list or privately to = Paul and myself. >=20 > Also, I suggest to replace the sentence "The working group may = consider multiple proposals, and then choose one to bring to the = standards track." by "The working group may standardize one of the = vendor solutions, a combination of several, or a new protocol." The = latter is clearer, at least to me. +1 to both. --Paul Hoffman From ynir@checkpoint.com Thu Dec 8 12:01:09 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F20F21F8ACE for ; Thu, 8 Dec 2011 12:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeB5uXn1Mw+v for ; Thu, 8 Dec 2011 12:01:08 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6216921F8B29 for ; Thu, 8 Dec 2011 12:01:05 -0800 (PST) X-CheckPoint: {4EE11650-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pB8K13WT006634; Thu, 8 Dec 2011 22:01:04 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 8 Dec 2011 22:00:57 +0200 From: Yoav Nir To: Paul Hoffman Date: Thu, 8 Dec 2011 22:00:56 +0200 Thread-Topic: [IPsec] Large Scale VPN Thread-Index: Acy15BlHjJLOZnGgRnKnvA5NrwcARw== Message-ID: <344877D5-9E81-4C05-9BD1-6ABA7B17BD32@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 20:01:09 -0000 On Dec 8, 2011, at 6:04 PM, Paul Hoffman wrote: >=20 > On Dec 8, 2011, at 1:55 AM, Yoav Nir wrote: >=20 >> In an environment with many IPsec gateways and remote clients that share= an established trust infrastructure (in a single administrative domain or = across multiple domains), customers want to get on-demand mesh IPsec capabi= lity for efficiency. However, this cannot be feasibly accomplished only wit= h today's IPsec and IKE due to problems with address lookup, reachability, = policy configuration, etc. >=20 > I don't think "mesh" is a well-defined term here. How about "point-to-poi= nt"? point to point sounds to me too much like the old host-to-host IPsec idea t= hat never quite took off. I know this is part of Chris's use case, but I do= n't think that's our main focus. I can live with either point-to-point or m= esh, but either way we'll have to define it in the first deliverable. >=20 >> The IPsecME working group will handle this large scale VPN problem by de= livering the following: >>=20 >> * The working group will create a problem statement document including u= se cases, definitions and proper requirements for discovery and updates. Th= is document would be solution-agnostic. Should reach WG last call around Oc= tober 2012. >>=20 >> * The working group will review and help publish Informational documents= describing current vendor proprietary solutions. These should be ready for= IETF last call by August 2012. >>=20 >> * The working group will choose a common solution for the discovery and = update problems that will satisfy the requirements in the problem statement= document. The working group may consider multiple proposals, and then choo= se one to bring to the standards track. >=20 > We would need a deadline for the last item. I suggest "December 2013". Works for me. I was hesitant to suggest a date.= From ynir@checkpoint.com Thu Dec 8 12:06:37 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF97121F8B9B for ; Thu, 8 Dec 2011 12:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urOtcnpO8Npz for ; Thu, 8 Dec 2011 12:06:37 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C29C221F8B95 for ; Thu, 8 Dec 2011 12:06:36 -0800 (PST) X-CheckPoint: {4EE1179B-3-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pB8K6XJA007717; Thu, 8 Dec 2011 22:06:33 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 8 Dec 2011 22:06:33 +0200 From: Yoav Nir To: Yaron Sheffer Date: Thu, 8 Dec 2011 22:06:31 +0200 Thread-Topic: [IPsec] Large Scale VPN Thread-Index: Acy15OGD7seECASeQ9e+KsEVU7JsZw== Message-ID: <0898B4C9-10AF-4526-A232-ABA751849E08@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> <4EE0FE88.7070808@gmail.com> In-Reply-To: <4EE0FE88.7070808@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 20:06:38 -0000 On Dec 8, 2011, at 8:14 PM, Yaron Sheffer wrote: > We as a group can commit to deliverable #1 and #3 (problem statement and= =20 > standardized solution). But deliverable #2 (vendor protocols) is mostly=20 > out of our hands. That's why I used "review" and "help" rather than "write" or "produce". > So before we approve this charter, I would like to=20 > hear from people that represent vendors that they can commit to publish=20 > such a draft for their favorite solution. With a mostly complete -00=20 > draft in, say, 4/2012. Please respond to the list or privately to Paul=20 > and myself. >=20 > Also, I suggest to replace the sentence "The working group may consider=20 > multiple proposals, and then choose one to bring to the standards=20 > track." by "The working group may standardize one of the vendor=20 > solutions, a combination of several, or a new protocol." The latter is=20 > clearer, at least to me. Agree. How about: In an environment with many IPsec gateways and remote clients that share an= established trust infrastructure (in a single administrative domain or acr= oss multiple domains), customers want to get on-demand point-to-point IPsec= capability for efficiency. However, this cannot be feasibly accomplished o= nly with today's IPsec and IKE due to problems with address lookup, reachab= ility, policy configuration, etc. The IPsecME working group will handle this large scale VPN problem by deliv= ering the following: * The working group will create a problem statement document including use = cases, definitions and proper requirements for discovery and updates. This = document would be solution-agnostic. Should reach WG last call around Octob= er 2012. * The working group will review and help publish Informational documents de= scribing current vendor proprietary solutions. These should be ready for IE= TF last call by August 2012. * The working group will choose a common solution for the discovery and upd= ate problems that will satisfy the requirements in the problem statement do= cument. The working group may standardize one of the vendor solutions, a co= mbination, an superset of such a solution, or a new protocol. From paul.hoffman@vpnc.org Thu Dec 8 12:15:18 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB71C21F8B20 for ; Thu, 8 Dec 2011 12:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QVHwLgUsBsI for ; Thu, 8 Dec 2011 12:15:18 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3CC21F8B1F for ; Thu, 8 Dec 2011 12:15:18 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pB8KFGiQ071522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 8 Dec 2011 13:15:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Paul Hoffman In-Reply-To: <344877D5-9E81-4C05-9BD1-6ABA7B17BD32@checkpoint.com> Date: Thu, 8 Dec 2011 12:15:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6075BBC8-1B55-46C0-BEEC-E527367FE3BD@vpnc.org> References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> <344877D5-9E81-4C05-9BD1-6ABA7B17BD32@checkpoint.com> To: IPsecme WG X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 20:15:18 -0000 On Dec 8, 2011, at 12:00 PM, Yoav Nir wrote: >=20 > On Dec 8, 2011, at 6:04 PM, Paul Hoffman wrote: >=20 >>=20 >> On Dec 8, 2011, at 1:55 AM, Yoav Nir wrote: >>=20 >>> In an environment with many IPsec gateways and remote clients that = share an established trust infrastructure (in a single administrative = domain or across multiple domains), customers want to get on-demand mesh = IPsec capability for efficiency. However, this cannot be feasibly = accomplished only with today's IPsec and IKE due to problems with = address lookup, reachability, policy configuration, etc. >>=20 >> I don't think "mesh" is a well-defined term here. How about = "point-to-point"? >=20 > point to point sounds to me too much like the old host-to-host IPsec = idea that never quite took off. The points can be (and are likely to be) gateways. > I know this is part of Chris's use case, but I don't think that's our = main focus. I can live with either point-to-point or mesh, but either = way we'll have to define it in the first deliverable. I believe that we need to have a sensible definition for the charter. Is there a good definition of "mesh VPN" we can add to the proposed = charter text? Is there a preference for "point-to-point", maybe with a = better definition? --Paul Hoffman From mcr@sandelman.ca Thu Dec 8 12:16:36 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B985221F8B2A for ; Thu, 8 Dec 2011 12:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYzavVLd1wLC for ; Thu, 8 Dec 2011 12:16:36 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4887921F8B29 for ; Thu, 8 Dec 2011 12:16:36 -0800 (PST) Received: from marajade.sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id D13B734437 for ; Thu, 8 Dec 2011 15:14:57 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id CD47F98CC6; Thu, 8 Dec 2011 15:16:49 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id C72B798C63 for ; Thu, 8 Dec 2011 15:16:49 -0500 (EST) From: Michael Richardson To: "'IPsecme WG'" In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> X-Mailer: MH-E 8.1; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Thu, 08 Dec 2011 15:16:49 -0500 Message-ID: <3236.1323375409@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 20:16:37 -0000 I find the goals and schedule acceptable. >>>>> "Yoav" == Yoav Nir writes: Yoav> In an environment with many IPsec gateways and remote clients Yoav> that share an established trust infrastructure (in a single Yoav> administrative domain or across multiple domains), customers Yoav> want to get on-demand mesh IPsec capability for Yoav> efficiency. However, this cannot be feasibly accomplished only Yoav> with today's IPsec and IKE due to problems with address Yoav> lookup, reachability, policy configuration, etc. Yoav> The IPsecME working group will handle this large scale VPN Yoav> problem by delivering the following: Yoav> * The working group will create a problem statement document Yoav> including use cases, definitions and proper requirements for Yoav> discovery and updates. This document would be Yoav> solution-agnostic. Should reach WG last call around October Yoav> 2012. Yoav> * The working group will review and help publish Informational Yoav> documents describing current vendor proprietary Yoav> solutions. These should be ready for IETF last call by August Yoav> 2012. Yoav> * The working group will choose a common solution for the Yoav> discovery and update problems that will satisfy the Yoav> requirements in the problem statement document. The working Yoav> group may consider multiple proposals, and then choose one to Yoav> bring to the standards track. Yoav> _______________________________________________ IPsec mailing Yoav> list IPsec@ietf.org Yoav> https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Thu Dec 8 12:46:46 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3809C21F8ACE for ; Thu, 8 Dec 2011 12:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTboAWQalM+1 for ; Thu, 8 Dec 2011 12:46:45 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6829621F8AB9 for ; Thu, 8 Dec 2011 12:46:45 -0800 (PST) Received: by eekd4 with SMTP id d4so1449965eek.31 for ; Thu, 08 Dec 2011 12:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pM2UJnbKevAdQfYI4r0/SYxbDSN3WkWf1bNTUxwPahI=; b=eNwc+OlQ22LSpyNs7SygChY9l8BFfD4xlhbnhjrAgMfkUqKCY2Z+u8bfoKLy/XR4zm WAGsZdqoFVpPmwrXUweTC0zdClvCVgFYc1865qGrTowk6g9mCriu9B5tWbLsFNNoyPrE qcpneuyTff5djyP6YX0gavMS1RBu2ylSTomFQ= Received: by 10.14.12.78 with SMTP id 54mr375376eey.150.1323377204558; Thu, 08 Dec 2011 12:46:44 -0800 (PST) Received: from [10.0.0.6] (bzq-79-181-231-7.red.bezeqint.net. [79.181.231.7]) by mx.google.com with ESMTPS id 65sm21915456eeg.8.2011.12.08.12.46.40 (version=SSLv3 cipher=OTHER); Thu, 08 Dec 2011 12:46:41 -0800 (PST) Message-ID: <4EE1222E.6050102@gmail.com> Date: Thu, 08 Dec 2011 22:46:38 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Yoav Nir References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> <4EE0FE88.7070808@gmail.com> <0898B4C9-10AF-4526-A232-ABA751849E08@checkpoint.com> In-Reply-To: <0898B4C9-10AF-4526-A232-ABA751849E08@checkpoint.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 20:46:46 -0000 I'm fine with the new text. Again, provided that people come forward with a commitment to work on the vendor documents. Thanks, Yaron On 12/08/2011 10:06 PM, Yoav Nir wrote: > On Dec 8, 2011, at 8:14 PM, Yaron Sheffer wrote: > >> We as a group can commit to deliverable #1 and #3 (problem statement and >> standardized solution). But deliverable #2 (vendor protocols) is mostly >> out of our hands. > That's why I used "review" and "help" rather than "write" or "produce". > >> So before we approve this charter, I would like to >> hear from people that represent vendors that they can commit to publish >> such a draft for their favorite solution. With a mostly complete -00 >> draft in, say, 4/2012. Please respond to the list or privately to Paul >> and myself. >> >> Also, I suggest to replace the sentence "The working group may consider >> multiple proposals, and then choose one to bring to the standards >> track." by "The working group may standardize one of the vendor >> solutions, a combination of several, or a new protocol." The latter is >> clearer, at least to me. > Agree. How about: > > In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc. > > The IPsecME working group will handle this large scale VPN problem by delivering the following: > > * The working group will create a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. Should reach WG last call around October 2012. > > * The working group will review and help publish Informational documents describing current vendor proprietary solutions. These should be ready for IETF last call by August 2012. > > * The working group will choose a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol. > From praveenys@juniper.net Thu Dec 8 13:34:16 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25F2B21F8B59 for ; Thu, 8 Dec 2011 13:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVmUV2PvgHzI for ; Thu, 8 Dec 2011 13:34:15 -0800 (PST) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id BCBD921F8B1E for ; Thu, 8 Dec 2011 13:34:08 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTuEtSMcLFx0ypt+rq9UtaQIi9Rj/6R11@postini.com; Thu, 08 Dec 2011 13:34:10 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 8 Dec 2011 13:33:26 -0800 From: Praveen Sathyanarayan To: Yaron Sheffer , Yoav Nir Date: Thu, 8 Dec 2011 13:33:26 -0800 Thread-Topic: [IPsec] Large Scale VPN Thread-Index: Acy18QU54jI0GAY9SGmtoA+6YqFAoA== Message-ID: In-Reply-To: <4EE1222E.6050102@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2011 21:34:16 -0000 I am representing Juniper. Juniper will plan to publish a draft. Thanks, Praveen On 12/8/11 12:46 PM, "Yaron Sheffer" wrote: I'm fine with the new text. Again, provided that people come forward with a commitment to work on the vendor documents. Thanks, Yaron On 12/08/2011 10:06 PM, Yoav Nir wrote: > On Dec 8, 2011, at 8:14 PM, Yaron Sheffer wrote: > >> We as a group can commit to deliverable #1 and #3 (problem statement and >> standardized solution). But deliverable #2 (vendor protocols) is mostly >> out of our hands. > That's why I used "review" and "help" rather than "write" or "produce". > >> So before we approve this charter, I would like to >> hear from people that represent vendors that they can commit to publish >> such a draft for their favorite solution. With a mostly complete -00 >> draft in, say, 4/2012. Please respond to the list or privately to Paul >> and myself. >> >> Also, I suggest to replace the sentence "The working group may consider >> multiple proposals, and then choose one to bring to the standards >> track." by "The working group may standardize one of the vendor >> solutions, a combination of several, or a new protocol." The latter is >> clearer, at least to me. > Agree. How about: > > In an environment with many IPsec gateways and remote clients that share >an established trust infrastructure (in a single administrative domain or >across multiple domains), customers want to get on-demand point-to-point >IPsec capability for efficiency. However, this cannot be feasibly >accomplished only with today's IPsec and IKE due to problems with address >lookup, reachability, policy configuration, etc. > > The IPsecME working group will handle this large scale VPN problem by >delivering the following: > > * The working group will create a problem statement document including >use cases, definitions and proper requirements for discovery and updates. >This document would be solution-agnostic. Should reach WG last call >around October 2012. > > * The working group will review and help publish Informational documents >describing current vendor proprietary solutions. These should be ready >for IETF last call by August 2012. > > * The working group will choose a common solution for the discovery and >update problems that will satisfy the requirements in the problem >statement document. The working group may standardize one of the vendor >solutions, a combination, an superset of such a solution, or a new >protocol. > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Mon Dec 12 01:44:30 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 307D521F8AF9 for ; Mon, 12 Dec 2011 01:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFsaT9zf2lgk for ; Mon, 12 Dec 2011 01:44:29 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2D121F8AF5 for ; Mon, 12 Dec 2011 01:44:28 -0800 (PST) X-CheckPoint: {4EE5CBA7-4-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pBC9iPJB004357; Mon, 12 Dec 2011 11:44:25 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 12 Dec 2011 11:44:25 +0200 From: Yoav Nir To: IPsecme WG Date: Mon, 12 Dec 2011 11:44:32 +0200 Thread-Topic: [IPsec] Large Scale VPN Thread-Index: Acy4sqGYIYr5N/UAS7WJH5yLYyVUvQ== Message-ID: <8047115F-1E4C-4D26-BC9D-B86D620DEBB7@checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> <4EE0FE88.7070808@gmail.com> <0898B4C9-10AF-4526-A232-ABA751849E08@checkpoint.com> In-Reply-To: <0898B4C9-10AF-4526-A232-ABA751849E08@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Paul Hoffman Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 09:44:30 -0000 Hi all If we want Paul and Yaron to take this to our AD, we need to show that ther= e are more people who think these work items are a good idea. More people t= han just me and MCR. So please show your support (or objections!) soon. An= "I think this is a good idea", "I think we should use ternary logic", or "= +1" is all it takes. Yoav On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote: >=20 > Agree. How about: >=20 > In an environment with many IPsec gateways and remote clients that share = an established trust infrastructure (in a single administrative domain or a= cross multiple domains), customers want to get on-demand point-to-point IPs= ec capability for efficiency. However, this cannot be feasibly accomplished= only with today's IPsec and IKE due to problems with address lookup, reach= ability, policy configuration, etc. >=20 > The IPsecME working group will handle this large scale VPN problem by del= ivering the following: >=20 > * The working group will create a problem statement document including us= e cases, definitions and proper requirements for discovery and updates. Thi= s document would be solution-agnostic. Should reach WG last call around Oct= ober 2012. >=20 > * The working group will review and help publish Informational documents = describing current vendor proprietary solutions. These should be ready for = IETF last call by August 2012. >=20 > * The working group will choose a common solution for the discovery and u= pdate problems that will satisfy the requirements in the problem statement = document. The working group may standardize one of the vendor solutions, a = combination, an superset of such a solution, or a new protocol. From shanna@juniper.net Mon Dec 12 07:22:59 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9950B21F8B66 for ; Mon, 12 Dec 2011 07:22:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.453 X-Spam-Level: X-Spam-Status: No, score=-106.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4YbyxkgyHsP for ; Mon, 12 Dec 2011 07:22:59 -0800 (PST) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9635C21F8B5B for ; Mon, 12 Dec 2011 07:22:52 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTuYcPpc4lTzZ4lxm974CPj2ekMSe9Szg@postini.com; Mon, 12 Dec 2011 07:22:58 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 12 Dec 2011 07:20:14 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 12 Dec 2011 10:19:04 -0500 From: Stephen Hanna To: Yoav Nir , IPsecme WG Date: Mon, 12 Dec 2011 10:19:02 -0500 Thread-Topic: [IPsec] Large Scale VPN Thread-Index: Acy4sqGYIYr5N/UAS7WJH5yLYyVUvQAGl8fg Message-ID: References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> <4EE0FE88.7070808@gmail.com> <0898B4C9-10AF-4526-A232-ABA751849E08@checkpoint.com> <8047115F-1E4C-4D26-BC9D-B86D620DEBB7@checkpoint.com> In-Reply-To: <8047115F-1E4C-4D26-BC9D-B86D620DEBB7@checkpoint.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 Cc: Paul Hoffman Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 15:22:59 -0000 Yes, I definitely think this is a good idea. Thanks, Steve > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Yoav Nir > Sent: Monday, December 12, 2011 4:45 AM > To: IPsecme WG > Cc: Paul Hoffman > Subject: Re: [IPsec] Large Scale VPN >=20 > Hi all >=20 > If we want Paul and Yaron to take this to our AD, we need to show that > there are more people who think these work items are a good idea. More > people than just me and MCR. So please show your support (or > objections!) soon. An "I think this is a good idea", "I think we should > use ternary logic", or "+1" is all it takes. >=20 > Yoav >=20 > On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote: > > > > Agree. How about: > > > > In an environment with many IPsec gateways and remote clients that > share an established trust infrastructure (in a single administrative > domain or across multiple domains), customers want to get on-demand > point-to-point IPsec capability for efficiency. However, this cannot be > feasibly accomplished only with today's IPsec and IKE due to problems > with address lookup, reachability, policy configuration, etc. > > > > The IPsecME working group will handle this large scale VPN problem by > delivering the following: > > > > * The working group will create a problem statement document > including use cases, definitions and proper requirements for discovery > and updates. This document would be solution-agnostic. Should reach WG > last call around October 2012. > > > > * The working group will review and help publish Informational > documents describing current vendor proprietary solutions. These should > be ready for IETF last call by August 2012. > > > > * The working group will choose a common solution for the discovery > and update problems that will satisfy the requirements in the problem > statement document. The working group may standardize one of the vendor > solutions, a combination, an superset of such a solution, or a new > protocol. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From david.black@emc.com Mon Dec 12 07:32:59 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4364E21F8B66 for ; Mon, 12 Dec 2011 07:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3f37Cy4LKMS for ; Mon, 12 Dec 2011 07:32:53 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id A9DEA21F8B7E for ; Mon, 12 Dec 2011 07:32:53 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pBCFWoX9014766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Dec 2011 10:32:51 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 12 Dec 2011 10:32:29 -0500 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pBCFWPx0024505; Mon, 12 Dec 2011 10:32:28 -0500 Received: from mx14a.corp.emc.com ([169.254.1.79]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Mon, 12 Dec 2011 10:32:26 -0500 From: To: Date: Mon, 12 Dec 2011 10:32:25 -0500 Thread-Topic: [IPsec] Large Scale VPN Thread-Index: Acy4sqGYIYr5N/UAS7WJH5yLYyVUvQAGl8fgAAWM5kA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A000CEB4@MX14A.corp.emc.com> References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> <4EE0FE88.7070808@gmail.com> <0898B4C9-10AF-4526-A232-ABA751849E08@checkpoint.com> <8047115F-1E4C-4D26-BC9D-B86D620DEBB7@checkpoint.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-EMM-MHVC: 1 Cc: paul.hoffman@vpnc.org Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 15:32:59 -0000 +1, Thanks, --David > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of= Stephen Hanna > Sent: Monday, December 12, 2011 10:19 AM > To: Yoav Nir; IPsecme WG > Cc: Paul Hoffman > Subject: Re: [IPsec] Large Scale VPN >=20 > Yes, I definitely think this is a good idea. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Yoav Nir > > Sent: Monday, December 12, 2011 4:45 AM > > To: IPsecme WG > > Cc: Paul Hoffman > > Subject: Re: [IPsec] Large Scale VPN > > > > Hi all > > > > If we want Paul and Yaron to take this to our AD, we need to show that > > there are more people who think these work items are a good idea. More > > people than just me and MCR. So please show your support (or > > objections!) soon. An "I think this is a good idea", "I think we should > > use ternary logic", or "+1" is all it takes. > > > > Yoav > > > > On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote: > > > > > > Agree. How about: > > > > > > In an environment with many IPsec gateways and remote clients that > > share an established trust infrastructure (in a single administrative > > domain or across multiple domains), customers want to get on-demand > > point-to-point IPsec capability for efficiency. However, this cannot be > > feasibly accomplished only with today's IPsec and IKE due to problems > > with address lookup, reachability, policy configuration, etc. > > > > > > The IPsecME working group will handle this large scale VPN problem by > > delivering the following: > > > > > > * The working group will create a problem statement document > > including use cases, definitions and proper requirements for discovery > > and updates. This document would be solution-agnostic. Should reach WG > > last call around October 2012. > > > > > > * The working group will review and help publish Informational > > documents describing current vendor proprietary solutions. These should > > be ready for IETF last call by August 2012. > > > > > > * The working group will choose a common solution for the discovery > > and update problems that will satisfy the requirements in the problem > > statement document. The working group may standardize one of the vendor > > solutions, a combination, an superset of such a solution, or a new > > protocol. > > > > _______________________________________________ > > 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 mark.boltz@stonesoft.com Mon Dec 12 07:50:11 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A9121F8B53 for ; Mon, 12 Dec 2011 07:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEv0Ee6ebk0V for ; Mon, 12 Dec 2011 07:50:09 -0800 (PST) Received: from hki-smtp-1a.stonesoft.com (hki-smtp-1a.stonesoft.com [192.89.38.178]) by ietfa.amsl.com (Postfix) with ESMTP id 68D4221F8B0C for ; Mon, 12 Dec 2011 07:50:09 -0800 (PST) Received: from hki-smtp-1a.stonesoft.com (localhost.localdomain [127.0.0.1]) by localhost.stonesoft.com (Postfix) with ESMTP id 05551348157; Mon, 12 Dec 2011 17:50:05 +0200 (EET) Received: from outlook.stonesoft.com (unknown [172.16.40.22]) by hki-smtp-1a.stonesoft.com (Postfix) with ESMTP id DBF9C348085; Mon, 12 Dec 2011 17:50:04 +0200 (EET) Received: from HKI-EXC-1.stonesoft.com ([fe80::b914:799e:5fe4:7c73]) by HKI-EXC-2.stonesoft.com ([fe80::400e:df46:3369:4741%14]) with mapi id 14.01.0339.001; Mon, 12 Dec 2011 17:50:06 +0200 From: Mark Boltz To: " " Thread-Topic: [IPsec] Large Scale VPN Thread-Index: Acy1j5kUEZ3r8hYNSW2+GCmXReGEjwAIqZYAAASOKwAAA+k1gACzcXMAAAuuqgAAAHeogAAAnJwA Date: Mon, 12 Dec 2011 15:50:06 +0000 Message-ID: <63F50912-44A5-42C1-9247-4BB42073F5BC@stonesoft.com> References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> <4EE0FE88.7070808@gmail.com> <0898B4C9-10AF-4526-A232-ABA751849E08@checkpoint.com> <8047115F-1E4C-4D26-BC9D-B86D620DEBB7@checkpoint.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A000CEB4@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A000CEB4@MX14A.corp.emc.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.0.52] Content-Type: text/plain; charset="us-ascii" Content-ID: <414DACEB73040D40809060C827D33AD6@stonesoft.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 15:50:11 -0000 +1 from me as well. The approach is a good idea, and the WG should proceed = as outlined. Mark On Dec 12, 2011, at 10:32 AM, wrote: > +1, Thanks, --David >=20 >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf O= f Stephen Hanna >> Sent: Monday, December 12, 2011 10:19 AM >> To: Yoav Nir; IPsecme WG >> Cc: Paul Hoffman >> Subject: Re: [IPsec] Large Scale VPN >>=20 >> Yes, I definitely think this is a good idea. >>=20 >> Thanks, >>=20 >> Steve >>=20 >>> -----Original Message----- >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >>> Of Yoav Nir >>> Sent: Monday, December 12, 2011 4:45 AM >>> To: IPsecme WG >>> Cc: Paul Hoffman >>> Subject: Re: [IPsec] Large Scale VPN >>>=20 >>> Hi all >>>=20 >>> If we want Paul and Yaron to take this to our AD, we need to show that >>> there are more people who think these work items are a good idea. More >>> people than just me and MCR. So please show your support (or >>> objections!) soon. An "I think this is a good idea", "I think we should >>> use ternary logic", or "+1" is all it takes. >>>=20 >>> Yoav >>>=20 >>> On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote: >>>>=20 >>>> Agree. How about: >>>>=20 >>>> In an environment with many IPsec gateways and remote clients that >>> share an established trust infrastructure (in a single administrative >>> domain or across multiple domains), customers want to get on-demand >>> point-to-point IPsec capability for efficiency. However, this cannot be >>> feasibly accomplished only with today's IPsec and IKE due to problems >>> with address lookup, reachability, policy configuration, etc. >>>>=20 >>>> The IPsecME working group will handle this large scale VPN problem by >>> delivering the following: >>>>=20 >>>> * The working group will create a problem statement document >>> including use cases, definitions and proper requirements for discovery >>> and updates. This document would be solution-agnostic. Should reach WG >>> last call around October 2012. >>>>=20 >>>> * The working group will review and help publish Informational >>> documents describing current vendor proprietary solutions. These should >>> be ready for IETF last call by August 2012. >>>>=20 >>>> * The working group will choose a common solution for the discovery >>> and update problems that will satisfy the requirements in the problem >>> statement document. The working group may standardize one of the vendor >>> solutions, a combination, an superset of such a solution, or a new >>> protocol. >>>=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 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nmelam@juniper.net Mon Dec 12 10:47:20 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3E621F8713 for ; Mon, 12 Dec 2011 10:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXCqP9O2ojIt for ; Mon, 12 Dec 2011 10:47:19 -0800 (PST) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3A53721F84A5 for ; Mon, 12 Dec 2011 10:47:14 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTuZMJDW/hoSwKnRHBXhNu4KTrcLBDCu4@postini.com; Mon, 12 Dec 2011 10:47:19 PST Received: from juniper.net (10.150.59.109) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 12 Dec 2011 10:46:38 -0800 Date: Mon, 12 Dec 2011 10:46:37 -0800 From: Suresh Melam To: Mark Boltz Message-ID: <20111212184637.GA16780@juniper.net> References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> <4EE0FE88.7070808@gmail.com> <0898B4C9-10AF-4526-A232-ABA751849E08@checkpoint.com> <8047115F-1E4C-4D26-BC9D-B86D620DEBB7@checkpoint.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A000CEB4@MX14A.corp.emc.com> <63F50912-44A5-42C1-9247-4BB42073F5BC@stonesoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <63F50912-44A5-42C1-9247-4BB42073F5BC@stonesoft.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "" , " " , "" Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 18:47:20 -0000 +1 thanks, -suresh On Mon, Dec 12, 2011 at 07:50:06AM -0800, Mark Boltz wrote: > +1 from me as well. The approach is a good idea, and the WG should proceed as outlined. > > Mark > > On Dec 12, 2011, at 10:32 AM, > wrote: > > > +1, Thanks, --David > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Stephen Hanna > >> Sent: Monday, December 12, 2011 10:19 AM > >> To: Yoav Nir; IPsecme WG > >> Cc: Paul Hoffman > >> Subject: Re: [IPsec] Large Scale VPN > >> > >> Yes, I definitely think this is a good idea. > >> > >> Thanks, > >> > >> Steve > >> > >>> -----Original Message----- > >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > >>> Of Yoav Nir > >>> Sent: Monday, December 12, 2011 4:45 AM > >>> To: IPsecme WG > >>> Cc: Paul Hoffman > >>> Subject: Re: [IPsec] Large Scale VPN > >>> > >>> Hi all > >>> > >>> If we want Paul and Yaron to take this to our AD, we need to show that > >>> there are more people who think these work items are a good idea. More > >>> people than just me and MCR. So please show your support (or > >>> objections!) soon. An "I think this is a good idea", "I think we should > >>> use ternary logic", or "+1" is all it takes. > >>> > >>> Yoav > >>> > >>> On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote: > >>>> > >>>> Agree. How about: > >>>> > >>>> In an environment with many IPsec gateways and remote clients that > >>> share an established trust infrastructure (in a single administrative > >>> domain or across multiple domains), customers want to get on-demand > >>> point-to-point IPsec capability for efficiency. However, this cannot be > >>> feasibly accomplished only with today's IPsec and IKE due to problems > >>> with address lookup, reachability, policy configuration, etc. > >>>> > >>>> The IPsecME working group will handle this large scale VPN problem by > >>> delivering the following: > >>>> > >>>> * The working group will create a problem statement document > >>> including use cases, definitions and proper requirements for discovery > >>> and updates. This document would be solution-agnostic. Should reach WG > >>> last call around October 2012. > >>>> > >>>> * The working group will review and help publish Informational > >>> documents describing current vendor proprietary solutions. These should > >>> be ready for IETF last call by August 2012. > >>>> > >>>> * The working group will choose a common solution for the discovery > >>> and update problems that will satisfy the requirements in the problem > >>> statement document. The working group may standardize one of the vendor > >>> solutions, a combination, an superset of such a solution, or a new > >>> protocol. > >>> > >>> _______________________________________________ > >>> IPsec mailing list > >>> IPsec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ipsec > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From Michael@huaweisymantec.com Mon Dec 12 11:36:02 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B05F21F8B15 for ; Mon, 12 Dec 2011 11:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXhIGy0auqNQ for ; Mon, 12 Dec 2011 11:36:01 -0800 (PST) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [218.17.155.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0C021F8AFF for ; Mon, 12 Dec 2011 11:36:01 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_D6MWOv3S13cy0qDluHVMyw)" Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0LW300IABVRXN520@hstga02-in.huaweisymantec.com> for ipsec@ietf.org; Tue, 13 Dec 2011 03:35:57 +0800 (CST) Received: from m90003900a ([69.199.248.19]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTPA id <0LW300KTJVRS7B00@hstml01-in.huaweisymantec.com> for ipsec@ietf.org; Tue, 13 Dec 2011 03:35:56 +0800 (CST) Message-id: <5E00D7FB144C41B5B78625B2DAE07ADD@china.huawei.com> From: Michael Ko To: Yoav Nir , IPsecme WG References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> <4EE0FE88.7070808@gmail.com> <0898B4C9-10AF-4526-A232-ABA751849E08@checkpoint.com> <8047115F-1E4C-4D26-BC9D-B86D620DEBB7@checkpoint.com> Date: Mon, 12 Dec 2011 11:35:52 -0800 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.6109 Cc: Paul Hoffman Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 19:36:02 -0000 This is a multi-part message in MIME format. --Boundary_(ID_D6MWOv3S13cy0qDluHVMyw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT As I indicated in the side meeting and mailing list discussions, I definitely support this going forward. Mike ----- Original Message ----- From: Yoav Nir To: IPsecme WG Cc: Paul Hoffman Sent: Monday, December 12, 2011 1:44 AM Subject: Re: [IPsec] Large Scale VPN Hi all If we want Paul and Yaron to take this to our AD, we need to show that there are more people who think these work items are a good idea. More people than just me and MCR. So please show your support (or objections!) soon. An "I think this is a good idea", "I think we should use ternary logic", or "+1" is all it takes. Yoav On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote: > > Agree. How about: > > In an environment with many IPsec gateways and remote clients that share > an established trust infrastructure (in a single administrative domain or > across multiple domains), customers want to get on-demand point-to-point > IPsec capability for efficiency. However, this cannot be feasibly > accomplished only with today's IPsec and IKE due to problems with address > lookup, reachability, policy configuration, etc. > > The IPsecME working group will handle this large scale VPN problem by > delivering the following: > > * The working group will create a problem statement document including use > cases, definitions and proper requirements for discovery and updates. This > document would be solution-agnostic. Should reach WG last call around > October 2012. > > * The working group will review and help publish Informational documents > describing current vendor proprietary solutions. These should be ready for > IETF last call by August 2012. > > * The working group will choose a common solution for the discovery and > update problems that will satisfy the requirements in the problem > statement document. The working group may standardize one of the vendor > solutions, a combination, an superset of such a solution, or a new > protocol. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_D6MWOv3S13cy0qDluHVMyw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
As I indicated in the side meeting and mailing list discussions, I definitely support this going forward.
 
Mike
----- Original Message -----
From: Yoav Nir
Sent: Monday, December 12, 2011 1:44 AM
Subject: Re: [IPsec] Large Scale VPN

Hi all

If we want Paul and Yaron to take this to our AD, we need to show that there are more people who think these work items are a good idea. More people than just me and MCR.  So please show your support (or objections!) soon. An "I think this is a good idea", "I think we should use ternary logic", or "+1" is all it takes.

Yoav

On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote:
>
> Agree. How about:
>
> In an environment with many IPsec gateways and remote clients that share an established trust infrastructure (in a single administrative domain or across multiple domains), customers want to get on-demand point-to-point IPsec capability for efficiency. However, this cannot be feasibly accomplished only with today's IPsec and IKE due to problems with address lookup, reachability, policy configuration, etc.
>
> The IPsecME working group will handle this large scale VPN problem by delivering the following:
>
> * The working group will create a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. Should reach WG last call around October 2012.
>
> * The working group will review and help publish Informational documents describing current vendor proprietary solutions. These should be ready for IETF last call by August 2012.
>
> * The working group will choose a common solution for the discovery and update problems that will satisfy the requirements in the problem statement document. The working group may standardize one of the vendor solutions, a combination, an superset of such a solution, or a new protocol.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--Boundary_(ID_D6MWOv3S13cy0qDluHVMyw)-- From Chris.Ulliott@cesg.gsi.gov.uk Tue Dec 13 01:08:54 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87BC21F85A7 for ; Tue, 13 Dec 2011 01:08:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDiCE5iZhD1X for ; Tue, 13 Dec 2011 01:08:54 -0800 (PST) Received: from mail185.messagelabs.com (mail185.messagelabs.com [85.158.143.19]) by ietfa.amsl.com (Postfix) with SMTP id 9867521F85A4 for ; Tue, 13 Dec 2011 01:08:51 -0800 (PST) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-11.tower-185.messagelabs.com!1323767328!7202553!1 X-Originating-IP: [62.25.106.208] X-StarScan-Version: 6.4.3; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 12475 invoked from network); 13 Dec 2011 09:08:48 -0000 Received: from gateway-102.energis.gsi.gov.uk (HELO mx.hosting-w.gsi.gov.uk) (62.25.106.208) by server-11.tower-185.messagelabs.com with SMTP; 13 Dec 2011 09:08:48 -0000 From: "Ulliott, Chris" To: 'Yoav Nir' , IPsecme WG Date: Tue, 13 Dec 2011 09:08:15 +0000 Thread-Topic: [IPsec] Large Scale VPN Thread-Index: Acy4sqGYIYr5N/UAS7WJH5yLYyVUvQAw/Q0w Message-ID: <0FA1220694422B418A3D8E77361B31DB03A65624@PIACHEVEX00.GCHQ.GOV.UK> In-Reply-To: <8047115F-1E4C-4D26-BC9D-B86D620DEBB7@checkpoint.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 Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 09:08:55 -0000 Protective Marking: UNCLASSIFIED +1, looks good to me! Chris -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Yoav Nir Sent: Monday, December 12, 2011 9:45 AM To: IPsecme WG Cc: Paul Hoffman Subject: Re: [IPsec] Large Scale VPN Hi all If we want Paul and Yaron to take this to our AD, we need to show that the= re are more people who think these work items are a good idea. More people= than just me and MCR. So please show your support (or objections!) soon.= An "I think this is a good idea", "I think we should use ternary logic", = or "+1" is all it takes. Yoav On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote: > > Agree. How about: > > In an environment with many IPsec gateways and remote clients that share= an established trust infrastructure (in a single administrative domain or= across multiple domains), customers want to get on-demand point-to-point = IPsec capability for efficiency. However, this cannot be feasibly accompli= shed only with today's IPsec and IKE due to problems with address lookup, = reachability, policy configuration, etc. > > The IPsecME working group will handle this large scale VPN problem by de= livering the following: > > * The working group will create a problem statement document including u= se cases, definitions and proper requirements for discovery and updates. T= his document would be solution-agnostic. Should reach WG last call around = October 2012. > > * The working group will review and help publish Informational documents= describing current vendor proprietary solutions. These should be ready fo= r IETF last call by August 2012. > > * The working group will choose a common solution for the discovery and = update problems that will satisfy the requirements in the problem statemen= t document. The working group may standardize one of the vendor solutions,= a combination, an superset of such a solution, or a new protocol. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec **************************************************************************= ** Communications with GCHQ may be monitored and/or recorded=20 for system efficiency and other lawful purposes. Any views or=20 opinions expressed in this e-mail do not necessarily reflect GCHQ=20 policy. This email, and any attachments, is intended for the=20 attention of the addressee(s) only. Its unauthorised use,=20 disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmaster@gchq.gsi.gov.uk. =20 This information is exempt from disclosure under the Freedom of=20 Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to=20 GCHQ on 01242 221491 ext 30306 (non-secure) or email infoleg@gchq.gsi.gov.uk **************************************************************************= ** The original of this email was scanned for viruses by the Government Secur= e Intranet virus scanning service supplied by Cable&Wireless Worldwide in = partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On l= eaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or r= ecorded for legal purposes. From B22160@freescale.com Mon Dec 12 11:35:50 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E48D21F8B15 for ; Mon, 12 Dec 2011 11:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaAbEhH0wn5X for ; Mon, 12 Dec 2011 11:35:49 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6262021F8AFF for ; Mon, 12 Dec 2011 11:35:49 -0800 (PST) Received: from mail222-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Mon, 12 Dec 2011 19:35:46 +0000 Received: from mail222-ch1 (localhost [127.0.0.1]) by mail222-ch1-R.bigfish.com (Postfix) with ESMTP id 9ABD760A86; Mon, 12 Dec 2011 19:06:35 +0000 (UTC) X-SpamScore: -46 X-BigFish: VS-46(zz9371I542M1432N98dK14ffO4015Lzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h8e2h8e3h944h) X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI; H:mail.freescale.net; RD:none; EFVD:NLI X-FB-SS: 13, Received: from mail222-ch1 (localhost.localdomain [127.0.0.1]) by mail222-ch1 (MessageSwitch) id 1323716795474217_13869; Mon, 12 Dec 2011 19:06:35 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244]) by mail222-ch1.bigfish.com (Postfix) with ESMTP id 6AD6E700046; Mon, 12 Dec 2011 19:06:35 +0000 (UTC) Received: from mail.freescale.net (70.37.183.190) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 12 Dec 2011 19:06:33 +0000 Received: from 039-SN2MPN1-011.039d.mgd.msft.net ([169.254.1.205]) by 039-SN1MMR1-002.039d.mgd.msft.net ([10.84.1.15]) with mapi id 14.01.0355.003; Mon, 12 Dec 2011 13:06:34 -0600 From: Addepalli Srini-B22160 To: Suresh Melam , Mark Boltz Thread-Topic: [IPsec] Large Scale VPN Thread-Index: AQHMuP6HhhTDBIa2NUii/WP/xOksrZXYkEzw Date: Mon, 12 Dec 2011 19:06:33 +0000 Message-ID: References: <006FEB08D9C6444AB014105C9AEB133F0179B226F98C@il-ex01.ad.checkpoint.com> <4EE0FE88.7070808@gmail.com> <0898B4C9-10AF-4526-A232-ABA751849E08@checkpoint.com> <8047115F-1E4C-4D26-BC9D-B86D620DEBB7@checkpoint.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A000CEB4@MX14A.corp.emc.com> <63F50912-44A5-42C1-9247-4BB42073F5BC@stonesoft.com> <20111212184637.GA16780@juniper.net> In-Reply-To: <20111212184637.GA16780@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.29.194.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-Mailman-Approved-At: Tue, 13 Dec 2011 08:18:47 -0800 Cc: "" , " " , "" Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 19:35:50 -0000 +1 Srini -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= uresh Melam Sent: Monday, December 12, 2011 10:47 AM To: Mark Boltz Cc: ; ; Subject: Re: [IPsec] Large Scale VPN +1 thanks, -suresh On Mon, Dec 12, 2011 at 07:50:06AM -0800, Mark Boltz wrote: > +1 from me as well. The approach is a good idea, and the WG should procee= d as outlined. >=20 > Mark >=20 > On Dec 12, 2011, at 10:32 AM, =20 > wrote: >=20 > > +1, Thanks, --David > >=20 > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On=20 > >> Behalf Of Stephen Hanna > >> Sent: Monday, December 12, 2011 10:19 AM > >> To: Yoav Nir; IPsecme WG > >> Cc: Paul Hoffman > >> Subject: Re: [IPsec] Large Scale VPN > >>=20 > >> Yes, I definitely think this is a good idea. > >>=20 > >> Thanks, > >>=20 > >> Steve > >>=20 > >>> -----Original Message----- > >>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On=20 > >>> Behalf Of Yoav Nir > >>> Sent: Monday, December 12, 2011 4:45 AM > >>> To: IPsecme WG > >>> Cc: Paul Hoffman > >>> Subject: Re: [IPsec] Large Scale VPN > >>>=20 > >>> Hi all > >>>=20 > >>> If we want Paul and Yaron to take this to our AD, we need to show=20 > >>> that there are more people who think these work items are a good=20 > >>> idea. More people than just me and MCR. So please show your=20 > >>> support (or > >>> objections!) soon. An "I think this is a good idea", "I think we=20 > >>> should use ternary logic", or "+1" is all it takes. > >>>=20 > >>> Yoav > >>>=20 > >>> On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote: > >>>>=20 > >>>> Agree. How about: > >>>>=20 > >>>> In an environment with many IPsec gateways and remote clients=20 > >>>> that > >>> share an established trust infrastructure (in a single=20 > >>> administrative domain or across multiple domains), customers want=20 > >>> to get on-demand point-to-point IPsec capability for efficiency.=20 > >>> However, this cannot be feasibly accomplished only with today's=20 > >>> IPsec and IKE due to problems with address lookup, reachability, poli= cy configuration, etc. > >>>>=20 > >>>> The IPsecME working group will handle this large scale VPN=20 > >>>> problem by > >>> delivering the following: > >>>>=20 > >>>> * The working group will create a problem statement document > >>> including use cases, definitions and proper requirements for=20 > >>> discovery and updates. This document would be solution-agnostic.=20 > >>> Should reach WG last call around October 2012. > >>>>=20 > >>>> * The working group will review and help publish Informational > >>> documents describing current vendor proprietary solutions. These=20 > >>> should be ready for IETF last call by August 2012. > >>>>=20 > >>>> * The working group will choose a common solution for the=20 > >>>> discovery > >>> and update problems that will satisfy the requirements in the=20 > >>> problem statement document. The working group may standardize one=20 > >>> of the vendor solutions, a combination, an superset of such a=20 > >>> solution, or a new protocol. > >>>=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 > >=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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From prbatra@cisco.com Fri Dec 16 04:06:15 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FEC421F8B6D for ; Fri, 16 Dec 2011 04:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM670RSaF-ap for ; Fri, 16 Dec 2011 04:06:14 -0800 (PST) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B121F8B6C for ; Fri, 16 Dec 2011 04:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=6302; q=dns/txt; s=iport; t=1324037172; x=1325246772; h=mime-version:subject:date:message-id:from:to; bh=aOSLC53+66LIvIEbiycgENUgr9aVuIkw2giOX3wBO3s=; b=WgfBXu6anVYMjimalhu2FtfjWPUWw4Zp33XoJVX2Y3eJmIJEEM2wBVzh jhkR/KRl+t6dXxr6fcigKqbg2nM7ActiaHOhlB3yuysBmyNL+9tEkcyOz zl0k0ItLfyOLfgTnR2B68Ymz4hM8Sf2c7uMnR3Wwwrt51wC9F7Zi6XCdX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAPEy605Io8UY/2dsb2JhbABEgk6qCYF0AQQSAQkRA1sBKgYYB1cBBAsQGqBqgSYBnkWIaoI3YwSIMp54 X-IronPort-AV: E=Sophos;i="4.71,362,1320624000"; d="scan'208,217";a="1769212" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 16 Dec 2011 12:06:10 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBGC64j0013558 for ; Fri, 16 Dec 2011 12:06:10 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Dec 2011 17:35:58 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBBEB.125EE9FC" Date: Fri, 16 Dec 2011 17:35:57 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: collison during initial exchange - RFC 5996 Thread-Index: Acy76xHmi/ho5BncQ2i4kwDcCdgi+w== From: "Prashant Batra (prbatra)" To: X-OriginalArrivalTime: 16 Dec 2011 12:05:58.0871 (UTC) FILETIME=[127BBE70:01CCBBEB] Subject: [IPsec] collison during initial exchange - RFC 5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 12:06:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBBEB.125EE9FC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a question on possible collision that can occur during initial exchange (INIT).=20 If two peers send INIT_REQ at the same time, maybe because of some data which matches the traffic_selector on both the peers, how a peer should decide whether it has to drop=20 the request and wait for the response or send the response for this request. This is similar to collision in case of IKE_REKEY, but I could not find any text in RFC 5996 to handle this scenario. =20 Regards, Prashant ------_=_NextPart_001_01CCBBEB.125EE9FC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a question on possible collision that can = occur during initial exchange (INIT).

If two peers send INIT_REQ at the same = time,

maybe  because of some data which matches the = traffic_selector on both the peers, how a peer should decide whether it has to drop =

the request and wait for the response or send the = response for this request.

This is similar to collision in case of IKE_REKEY, = but I could not find any text in RFC 5996 to handle this = scenario.

 

Regards,

Prashant

------_=_NextPart_001_01CCBBEB.125EE9FC-- From kivinen@iki.fi Fri Dec 16 05:55:21 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 453C621F8B67 for ; Fri, 16 Dec 2011 05:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHt1aaE+DrKE for ; Fri, 16 Dec 2011 05:55:20 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E3721F8B62 for ; Fri, 16 Dec 2011 05:55:19 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id pBGDtClF019667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2011 15:55:12 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id pBGDt9e1026650; Fri, 16 Dec 2011 15:55:10 +0200 (EET) 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: <20203.19901.967544.547378@fireball.kivinen.iki.fi> Date: Fri, 16 Dec 2011 15:55:09 +0200 From: Tero Kivinen To: "Prashant Batra (prbatra)" In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 20 min X-Total-Time: 29 min Cc: ipsec@ietf.org Subject: [IPsec] collison during initial exchange - RFC 5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 13:55:21 -0000 Prashant Batra (prbatra) writes: > I have a question on possible collision that can occur during initial > exchange (INIT). > > If two peers send INIT_REQ at the same time, > > maybe because of some data which matches the traffic_selector on both > the peers, how a peer should decide whether it has to drop > > the request and wait for the response or send the response for this > request. This is not collision, as there is no way to detect this at IKE_SA_INIT phase. We do not know wheter the identities used are going to be the same. Implementations should simply continue processing both requests and create two separate IKE SAs. > This is similar to collision in case of IKE_REKEY, but I could not find > any text in RFC 5996 to handle this scenario. This is different from IKE_REKEY collision, as here we create two overlapping IKE (and most likely also Child) SAs. This is completely valid and allowed by the RFC5996, and there is no need to delete either one of them. The reason IKE_REKEY etc needs special checks for the collisions is to ensure that Child SAs are moved to the correct IKE SA after the rekey, and that the number of IKE SAs would not multiply after each rekey (i.e. if each IKE SA rekey could potentially create 2 new IKE SAs, which each of them could again be rekeyed and potentially create 2 more (in total of 4) IKE SAs etc). In the initial connection case there is no possiblity for that as after the peers do have IKE SAs up they use normal rekey procedure which does include collision detection, so the worst case scenario is that those two IKE SAs stay up and both of them will get rekeyed as normally. Note, that INITIAL_CONTACT notification can also make situation different. In this kind of situation where both ends does simultaneous connect, both ends are likely to include INITIAL_CONTACT notification too. Now if one of the IKE_AUTH exchanges finishes first, then when the later exchange will notice that there is old IKE SA between the same authenticated identities, and will silently remove that older first IKE SA (and Child SA) and create new second one. This will cause the first peer to send packets to SAs which have already been deleted, which will cause the receiving peer to send INVALID_SPI message inside the surviving 2nd IKE SA, thus deleting the first Child SA. In this case the first peer will then most likely move its traffic to the surving 2nd Child SA, and later also delete the IKE SA when it times out. If first peer is sending IKE packets to the IKE SA which have already been deleted, then second peer will reply with INVALID_IKE_SPI outside the IKE SAs, and then first peer will delete its IKE SA (after timeout) and will most likely move to use the surviving IKE SA and Child SA. If the IKE_AUTH exchanges are processed simultaneously then neither end has IKE SAs between the peers, as both of the IKE SAs are still in the process of being created. Neither end deleteds IKE SAs, thus this will cause two IKE SAs to be created (which again is not a problem). It is important that INITIAL_CONTACT processing do not remove half created IKE SAs, only fully connected IKE SAs, as otherwise in this case the both ends would delete the IKE SAs and then the whole process would start over. -- kivinen@iki.fi From nmelam@juniper.net Fri Dec 16 17:42:44 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D483121F84DB for ; Fri, 16 Dec 2011 17:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQj32Jt+ogFW for ; Fri, 16 Dec 2011 17:42:44 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5D74521F84D7 for ; Fri, 16 Dec 2011 17:42:39 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTuvzjx2DmnyQUKrfjTz0WUxI8TochPDO@postini.com; Fri, 16 Dec 2011 17:42:43 PST Received: from juniper.net (10.150.59.109) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 16 Dec 2011 17:41:51 -0800 Date: Fri, 16 Dec 2011 17:41:50 -0800 From: Suresh Melam To: Tero Kivinen Message-ID: <20111217014150.GA22320@juniper.net> References: <20203.19901.967544.547378@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20203.19901.967544.547378@fireball.kivinen.iki.fi> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "ipsec@ietf.org" , "Prashant Batra \(prbatra\)" Subject: Re: [IPsec] collison during initial exchange - RFC 5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 01:42:44 -0000 Ending up with two IKE SAs, may not be an issue in terms of functionality, but can be seen as an issue in terms of scalability. Can we come up with a "standard" way of discarding the extraneous IKE SA, so that both peers will discard the "same" extraneous SA? Any non standard method to discard, may end up in two peers discarding both the SAs. It may also be just plain confusing to the end user, as you mentioned below, in a scenario with two CHILD SAs negotiated from two IKE SAs can continue to rekey forever, and then one peer may use one CHILD SA for its outgoing traffic whereas other peer use the "other" CHILD SA for its outgoing traffic. Again not a functionality issue, but could be seen as an usability issue. thanks, -suresh On Fri, Dec 16, 2011 at 05:55:09AM -0800, Tero Kivinen wrote: > Prashant Batra (prbatra) writes: > > I have a question on possible collision that can occur during initial > > exchange (INIT). > > > > If two peers send INIT_REQ at the same time, > > > > maybe because of some data which matches the traffic_selector on both > > the peers, how a peer should decide whether it has to drop > > > > the request and wait for the response or send the response for this > > request. > > This is not collision, as there is no way to detect this at > IKE_SA_INIT phase. We do not know wheter the identities used are going > to be the same. > > Implementations should simply continue processing both requests and > create two separate IKE SAs. > > > This is similar to collision in case of IKE_REKEY, but I could not find > > any text in RFC 5996 to handle this scenario. > > This is different from IKE_REKEY collision, as here we create two > overlapping IKE (and most likely also Child) SAs. This is completely > valid and allowed by the RFC5996, and there is no need to delete > either one of them. The reason IKE_REKEY etc needs special checks for > the collisions is to ensure that Child SAs are moved to the correct > IKE SA after the rekey, and that the number of IKE SAs would not > multiply after each rekey (i.e. if each IKE SA rekey could potentially > create 2 new IKE SAs, which each of them could again be rekeyed and > potentially create 2 more (in total of 4) IKE SAs etc). > > In the initial connection case there is no possiblity for that as > after the peers do have IKE SAs up they use normal rekey procedure > which does include collision detection, so the worst case scenario is > that those two IKE SAs stay up and both of them will get rekeyed as > normally. > > Note, that INITIAL_CONTACT notification can also make situation > different. In this kind of situation where both ends does simultaneous > connect, both ends are likely to include INITIAL_CONTACT notification > too. > > Now if one of the IKE_AUTH exchanges finishes first, then when the > later exchange will notice that there is old IKE SA between the same > authenticated identities, and will silently remove that older first > IKE SA (and Child SA) and create new second one. This will cause the > first peer to send packets to SAs which have already been deleted, > which will cause the receiving peer to send INVALID_SPI message inside > the surviving 2nd IKE SA, thus deleting the first Child SA. In this > case the first peer will then most likely move its traffic to the > surving 2nd Child SA, and later also delete the IKE SA when it times > out. > > If first peer is sending IKE packets to the IKE SA which have already > been deleted, then second peer will reply with INVALID_IKE_SPI outside > the IKE SAs, and then first peer will delete its IKE SA (after > timeout) and will most likely move to use the surviving IKE SA and > Child SA. > > If the IKE_AUTH exchanges are processed simultaneously then neither > end has IKE SAs between the peers, as both of the IKE SAs are still in > the process of being created. Neither end deleteds IKE SAs, thus this > will cause two IKE SAs to be created (which again is not a problem). > It is important that INITIAL_CONTACT processing do not remove half > created IKE SAs, only fully connected IKE SAs, as otherwise in this > case the both ends would delete the IKE SAs and then the whole process > would start over. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Mon Dec 19 06:15:10 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207FE21F8B85 for ; Mon, 19 Dec 2011 06:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3RwBr675ML6 for ; Mon, 19 Dec 2011 06:15:09 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1471E21F8B84 for ; Mon, 19 Dec 2011 06:15:08 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id pBJEEvAV025076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Dec 2011 16:14:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id pBJEEucX028131; Mon, 19 Dec 2011 16:14:56 +0200 (EET) 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: <20207.18144.582445.403025@fireball.kivinen.iki.fi> Date: Mon, 19 Dec 2011 16:14:56 +0200 From: Tero Kivinen To: Suresh Melam In-Reply-To: <20111217014150.GA22320@juniper.net> References: <20203.19901.967544.547378@fireball.kivinen.iki.fi> <20111217014150.GA22320@juniper.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: "ipsec@ietf.org" , "Prashant Batra \(prbatra\)" Subject: Re: [IPsec] collison during initial exchange - RFC 5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 14:15:10 -0000 Suresh Melam writes: > Ending up with two IKE SAs, may not be an issue in terms of functionality, > but can be seen as an issue in terms of scalability. I do not think so. I do not think this is very common situation hapening in the wild. It can happen if both ends decide to try to connect to each other exactly at the same time, which is usually not so common. The more common situation is that the network breaks down and both ends drop connections, and then connection come up again, and both ends try to reconnect, but in this situation this kind of thing can be solved by good implementation solutions, like using random backoff, jitter in the connections, checking out whether other end has already started connecting to us before starting to connect to them etc, or using different timers depending whether the original lost connection was initiated by this end or other end. As this kind of timing issues usually only happen (in large scale) between very similar implementations (i.e. both ends are from same vendor) it is usually enough to have vendor specific implementation solution for this. > Can we come up with a "standard" way of discarding the extraneous IKE SA, > so that both peers will discard the "same" extraneous SA? Any non standard > method to discard, may end up in two peers discarding both the SAs. There is no way to know they are really extraneous, as it is completely legal for other end to create two IKE SAs if he feels like it. So neither one of them is extraneous in that sense. > It may also be just plain confusing to the end user, as you mentioned > below, in a scenario with two CHILD SAs negotiated from two IKE SAs can > continue to rekey forever, and then one peer may use one CHILD SA for its > outgoing traffic whereas other peer use the "other" CHILD SA for its > outgoing traffic. End user does not see any difference. For end user his traffic just goes through and thats it. End users should not see IKE SAs or Child SAs.... > Again not a functionality issue, but could be seen as an usability > issue. Which can be solved by good engineering solutions in the vendors implementations. For example if this is really a scalability issue for the scenario, then the vendor having scalability problems can detect this situation and move his Child SAs from his own IKE SA to the other ends IKE SA, and when that is done (and ole Child SAs have been deleted) delete the old IKE SA. Again the implementation needs to add jitter and bias to make sure that if two of the same vendors implementations are talking to each other, both ends do not start doing this simultaneously. -- kivinen@iki.fi From paul.hoffman@vpnc.org Mon Dec 19 09:17:05 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0258111E809B for ; Mon, 19 Dec 2011 09:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOFzfC-OGCtX for ; Mon, 19 Dec 2011 09:17:04 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAC421F84AC for ; Mon, 19 Dec 2011 09:17:04 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pBJHH37Q063628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 19 Dec 2011 10:17:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Dec 2011 09:17:03 -0800 References: <20111219165356.001C372E002@rfc-editor.org> To: IPsecme WG Message-Id: <53B4342C-DD4C-4B9A-B9E4-85C80B5D258D@vpnc.org> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [IPsec] Fwd: RFC 6467 on Secure Password Framework for Internet Key Exchange Version 2 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 17:17:05 -0000 Begin forwarded message: > From: rfc-editor@rfc-editor.org > Subject: RFC 6467 on Secure Password Framework for Internet Key = Exchange Version 2 (IKEv2) > Date: December 19, 2011 8:53:55 AM PST > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: rfc-editor@rfc-editor.org >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6467 >=20 > Title: Secure Password Framework for Internet=20 > Key Exchange Version 2 (IKEv2)=20 > Author: T. Kivinen > Status: Informational > Stream: IETF > Date: December 2011 > Mailbox: kivinen@iki.fi > Pages: 10 > Characters: 21987 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: = draft-kivinen-ipsecme-secure-password-framework-03.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6467.txt >=20 > This document defines a generic way for Internet Key Exchange > version 2 (IKEv2) to use any of the symmetric secure password=20 > authentication methods. Multiple methods are already specified=20 > in other documents, and this document does not add any new one. =20 > This document specifies a way to agree on which method is to be=20 > used in the current connection. This document also provides a=20 > common way to transmit, between peers, payloads that are specific > to secure password authentication methods. >=20 >=20 > INFORMATIONAL: This memo provides information for the Internet = community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. From praveenys@juniper.net Mon Dec 19 12:18:38 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F6F21F85A7 for ; Mon, 19 Dec 2011 12:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAayc-0pbqk9 for ; Mon, 19 Dec 2011 12:18:38 -0800 (PST) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 25F1021F85A4 for ; Mon, 19 Dec 2011 12:18:34 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTu+cCn+tpe7H+nJ/kreeGMrfcymSfF8A@postini.com; Mon, 19 Dec 2011 12:18:34 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Mon, 19 Dec 2011 12:16:15 -0800 From: Praveen Sathyanarayan To: Tero Kivinen , Suresh Melam Date: Mon, 19 Dec 2011 12:16:12 -0800 Thread-Topic: [IPsec] collison during initial exchange - RFC 5996 Thread-Index: Acy+iw8Lw93NXxgYRteaDigeoRQb5A== Message-ID: In-Reply-To: <20207.18144.582445.403025@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.1.0.101012 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] collison during initial exchange - RFC 5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 20:18:38 -0000 Hi Tero, Looks like there were few discussion happened on this topic while writing RFC 5996. Why it was not noted in RFC? Even if it was not decided to address it in RFC, I think there is a good value to note it. I have few more comments inline. -- Praveen On 12/19/11 6:14 AM, "Tero Kivinen" wrote: Suresh Melam writes: > Ending up with two IKE SAs, may not be an issue in terms of >functionality, > but can be seen as an issue in terms of scalability. I do not think so. I do not think this is very common situation hapening in the wild. It can happen if both ends decide to try to connect to each other exactly at the same time, which is usually not so common. The more common situation is that the network breaks down and both ends drop connections, and then connection come up again, and both ends try to reconnect, [PRAVEEN] It is not very common, but common enough. We have seen several customer running into it. Again this is more of scalability issue. Takes more CPU and memory in maintaining this extraneous SAs. Also it is a source of confusion for several customers. but in this situation this kind of thing can be solved by good implementation solutions, like using random backoff, jitter in the connections, checking out whether other end has already started connecting to us before starting to connect to them etc, or using different timers depending whether the original lost connection was initiated by this end or other end. [PRAVEEN] Are you suggesting that add jitter before triggering the negotiation? If so, it is not practical. Adding jitter will result in packet loss. If you are suggesting jitter in state m/c (delay in responding to 2nd or 3rd packet so that one of the negotiation will be completed soon), then it should be done only after authenticating peer (for security reasons). And this can be too late in IKEv2 (as there are only 2 pair of exchange). Thus I don't see a practical solution for it. IMO, we should let negotiation to complete and come up with tie breaker to cleanup extraneous SAs. As this kind of timing issues usually only happen (in large scale) between very similar implementations (i.e. both ends are from same vendor) it is usually enough to have vendor specific implementation solution for this. > Can we come up with a "standard" way of discarding the extraneous IKE SA, > so that both peers will discard the "same" extraneous SA? Any non >standard > method to discard, may end up in two peers discarding both the SAs. There is no way to know they are really extraneous, as it is completely legal for other end to create two IKE SAs if he feels like it. So neither one of them is extraneous in that sense. [PRAVEEN] In our opinion, there should be a optional standard way of cleaning up extraneous SAs. It is shouldn't be mandatory but it can be optional. Vendor can decide if they want to implement it or not. I believe there are vendors already doing it in non standard way if both devices belongs to same vendor. > It may also be just plain confusing to the end user, as you mentioned > below, in a scenario with two CHILD SAs negotiated from two IKE SAs can > continue to rekey forever, and then one peer may use one CHILD SA for its > outgoing traffic whereas other peer use the "other" CHILD SA for its > outgoing traffic. End user does not see any difference. For end user his traffic just goes through and thats it. End users should not see IKE SAs or Child SAs....=20 > Again not a functionality issue, but could be seen as an usability > issue. Which can be solved by good engineering solutions in the vendors implementations. For example if this is really a scalability issue for the scenario, then the vendor having scalability problems can detect this situation and move his Child SAs from his own IKE SA to the other ends IKE SA, and when that is done (and ole Child SAs have been deleted) delete the old IKE SA. Again the implementation needs to add jitter and bias to make sure that if two of the same vendors implementations are talking to each other, both ends do not start doing this simultaneously. --=20 kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From svanru@gmail.com Mon Dec 19 22:33:47 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B4A11E80CA for ; Mon, 19 Dec 2011 22:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.486 X-Spam-Level: X-Spam-Status: No, score=-0.486 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, XMAILER_MIMEOLE_OL_7533E=0.513] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri4tU9AyxhCL for ; Mon, 19 Dec 2011 22:33:46 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 711F911E809D for ; Mon, 19 Dec 2011 22:33:46 -0800 (PST) Received: by wgbds13 with SMTP id ds13so8433121wgb.1 for ; Mon, 19 Dec 2011 22:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=+05pADoEH0a6yVDdOa9yQ/Re/2bFptlCmn6QoDr9SWg=; b=jmKk11d1Sc8Fo2bC/GQo4R/HKmRSBvaWLTcIfWlTrCmEokDwyfHh8cj0elhd/rgytL mMcjobPwTrkb6spWR6Qvq0giXlt9JG/aVvobPb/0+4T0K6vEDANTg+zlZW1TjhE1t9U0 vn0fZvjGjyjrD8Pti1atQMbe6ILqfokTBRU10= Received: by 10.180.85.4 with SMTP id d4mr1751421wiz.0.1324362825621; Mon, 19 Dec 2011 22:33:45 -0800 (PST) Received: from svanpc ([80.68.68.210]) by mx.google.com with ESMTPS id fn3sm747077wbb.17.2011.12.19.22.33.43 (version=SSLv3 cipher=OTHER); Mon, 19 Dec 2011 22:33:44 -0800 (PST) Message-ID: From: "Valery Smyslov" To: References: <20203.19901.967544.547378@fireball.kivinen.iki.fi> Date: Tue, 20 Dec 2011 10:35:36 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4963.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4963.1700 Subject: [IPsec] IKE SA close/rekey collision X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 06:33:47 -0000 Hi, section 2.25.2 describes some rules to deal with IKE SA close and rekey collisions. In particular, it states: If a peer receives a request to close an IKE SA that it is currently rekeying, it SHOULD reply as usual, and forget about its own rekeying request. Following this rule may lead to situation when IKE SA states become out of sync. Consider the following example: Host A Host B ------------------------------------------------------------------- send req1: SA(..,SPIa1,..),Ni1,.. --> --> recv req1 <-- send resp1: SA(..,SPIb2,..),Nr2,.. (lost) Consider the situation when resp1 get lost. At this point Host B thinks that old SA is successfully rekeyed. And if it has any reason to close it (for example, its lifetime is over and Host B was about to start its rekeying by itself unless it noticed that Host A has already done it), it will safely (as it thinks) make close request. <-- send req2 D() recv resq2 <-- >From Host A's point of view this is exactly the situation described in 2.25.2. According to the given rule it replies as usual to req2 and forgets about its req1. resend resp2 --> --> recv resp2 As a result - old IKE SA is closed, but the two peers have different views on its successor- Host A thinks that old SA wasn't rekeyed at all and kills its Child SAs, while Host B thinks it was successfully rekeyed and all its Child SAs survived. >From my point of view correct rule for this situation should be: If a peer receives a request to close an IKE SA that it is currently rekeying and it did notice simultaneous rekey, it SHOULD reply as usual, and forget about its own rekeying request. If a peer receives a request to close an IKE SA that it is currently rekeying and it didn't notice simultaneous rekey, it SHOULD postpone to reply to this request untill its own rekeying request is completed (successfully or not). Regards, Valery Smyslov. From kivinen@iki.fi Tue Dec 20 04:38:17 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447DE21F8B0D for ; Tue, 20 Dec 2011 04:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Nb3IyUE5Qcf for ; Tue, 20 Dec 2011 04:38:16 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E8221F8AFF for ; Tue, 20 Dec 2011 04:38:16 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id pBKCc5T6026316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2011 14:38:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id pBKCc5nj017273; Tue, 20 Dec 2011 14:38:05 +0200 (EET) 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: <20208.33197.299188.451177@fireball.kivinen.iki.fi> Date: Tue, 20 Dec 2011 14:38:05 +0200 From: Tero Kivinen To: Praveen Sathyanarayan In-Reply-To: References: <20207.18144.582445.403025@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 14 min Cc: "ipsec@ietf.org" , Suresh Melam Subject: Re: [IPsec] collison during initial exchange - RFC 5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 12:38:17 -0000 Praveen Sathyanarayan writes: > [PRAVEEN] It is not very common, but common enough. We have seen several > customer running into it. Again this is more of scalability issue. Takes > more CPU and memory in maintaining this extraneous SAs. Also it is a > source of confusion for several customers. If it is ont very common, it should not really affect scalability, I mean you should not design system so that adding 1% of more SAs will cause it to run out of CPU or memory... And if this happens more than 1% of all IKE SA, then I think there is something in the scenario or implementation which causes it to happen. > [PRAVEEN] Are you suggesting that add jitter before triggering the > negotiation? If so, it is not practical. Adding jitter will result in > packet loss. Adding jitter before triggering after the connection has been lost because network breakdown should not affect that much. When the network connection broke down you already lost packets regardless what you did. The only way I could think how this could happen a bit more often is the case where there is already IPsec connection between the peers, and networks breaks down, and both ends try to reconnect the IKE SA simultaneously. > If you are suggesting jitter in state m/c (delay in responding to m/c? No idea what that state is. > 2nd or 3rd packet so that one of the negotiation will be completed > soon), then it should be done only after authenticating peer (for > security reasons). And this can be too late in IKEv2 (as there are > only 2 pair of exchange). I was suggesting jittering and random backoff for the retransmissions of the IKE SA INIT. I.e. when the network comes up again after the break, both ends (or only one end) might detect that link came up and it might want to add some random 2 second jitter before retransmission of its packet. > Thus I don't see a practical solution for it. IMO, we should let > negotiation to complete and come up with tie breaker to cleanup > extraneous SAs. As I do not think this is problem really happening that often, that adding special code for it will most likely just cause more problems than solve issues. For example I am not sure how many implementations actually implement the current simultaneous exchanges stuff we have in the RFC5996. My guess is that there are several implementations implementing at least some parts of it, but not that many who implement every single parts of it. > [PRAVEEN] In our opinion, there should be a optional standard way of > cleaning up extraneous SAs. It is shouldn't be mandatory but it can be > optional. Vendor can decide if they want to implement it or not. I believe > there are vendors already doing it in non standard way if both devices > belongs to same vendor. And I think this kind of solution is best to be left to the vendors. Especially if we do not mandate it, then either end still needs to be able to cope with implementations not implementing it. Having vendors specific way of solving this is fine, as this kind of timing issues mostly only occur when you have two similar implementations (i.e. from same vendor) talking to each other. Usually different vendors use so different timers, and jitters etc that this kind of problems do not occur between implementations of different vendors. -- kivinen@iki.fi From kivinen@iki.fi Tue Dec 20 05:02:45 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2FA21F8B11 for ; Tue, 20 Dec 2011 05:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeSvUH8YiAe6 for ; Tue, 20 Dec 2011 05:02:44 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AF421F8B0B for ; Tue, 20 Dec 2011 05:02:44 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id pBKD2fE0000988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2011 15:02:41 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id pBKD2cHX001659; Tue, 20 Dec 2011 15:02:38 +0200 (EET) 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: <20208.34670.839660.296878@fireball.kivinen.iki.fi> Date: Tue, 20 Dec 2011 15:02:38 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <20203.19901.967544.547378@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 22 min Cc: ipsec@ietf.org Subject: [IPsec] IKE SA close/rekey collision X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 13:02:45 -0000 Valery Smyslov writes: > section 2.25.2 describes some rules to deal with IKE SA close and > rekey collisions. > In particular, it states: > > If a peer receives a request to close an IKE SA that it is currently > rekeying, it SHOULD reply as usual, and forget about its own rekeying > request. > > Following this rule may lead to situation when IKE SA states become > out of sync. > Consider the following example: > > Host A Host B > ------------------------------------------------------------------- > send req1: > SA(..,SPIa1,..),Ni1,.. --> > --> recv req1 > <-- send resp1: SA(..,SPIb2,..),Nr2,.. (lost) > > Consider the situation when resp1 get lost. At this point > Host B thinks that old SA is successfully rekeyed. > And if it has any reason to close it (for example, its > lifetime is over and Host B was about to start its > rekeying by itself unless it noticed that Host A has > already done it), it will safely (as it thinks) make > close request. > > <-- send req2 D() > recv resq2 <-- RFC 5996 section 2.8 says: After the new equivalent IKE SA is created, the initiator deletes the old IKE SA, and the Delete payload to delete itself MUST be the last request sent over the old IKE SA. I.e. host B is not supposed to delete the IKE SA, it is supposed to wait for the host A to delete the SA. This is required as otherwise host B does not know whether the Host A received the its IKE SA rekey response. When the host A send delete on the old IKE SA, host B will know that the host A has finished the rekey, and the old IKE SA can be deleted. So here host B is not following the RFC5996 and that causes the problem. > From Host A's point of view this is exactly the situation > described in 2.25.2. According to the given rule it replies > as usual to req2 and forgets about its req1. > > resend resp2 --> > --> recv resp2 > > As a result - old IKE SA is closed, but the two peers > have different views on its successor- Host A thinks > that old SA wasn't rekeyed at all and kills its Child SAs, > while Host B thinks it was successfully rekeyed and all its > Child SAs survived. I think host B never should start any new operations on the old IKE SA after it has been rekeyed. I.e. when host B notices that old IKE SA has (from its point of view) being rekeyed, it should not send any new requests through it. It should always use the new IKE SA. On the other hand if host B has already decided to delete the IKE SA, and his request has for example got lost before it receives the IKE SA rekey, it should fail the rekey request with TEMPORARY_FAILURE (2.25.2, first paragraph, last sentence: "If a peer receives a request to rekey an IKE SA that it is currently trying to close, it SHOULD reply with TEMPORARY_FAILURE.") > >From my point of view correct rule for this situation should be: > > If a peer receives a request to close an IKE SA that it is currently > rekeying and it did notice simultaneous rekey, it SHOULD reply > as usual, and forget about its own rekeying request. > > If a peer receives a request to close an IKE SA that it is currently > rekeying and it didn't notice simultaneous rekey, it SHOULD > postpone to reply to this request untill its own rekeying request > is completed (successfully or not). I think the correct solution is to say that peer should not send any new exchanges through the IKE SA the other end has already rekeyed. It can only wait for its older requests to finish, and wait for the other end (the one who initiated the IKE SA rekey) to delete the old IKE SA. Currently we only have "SHOULD NOT start new CREATE_CHILD_SA exchanges" (section 1.3.2): Once a peer receives a request to rekey an IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed. I think this should really have been Once a peer receives a request to rekey an IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any new exchanges on the IKE SA that is being rekeyed (except the final IKE SA delete from the peer who initiated IKE SA rekey). I.e. SHOULD NOT start any new exchanges, not only CREATE_CHILD_SA exchanges. -- kivinen@iki.fi From MLS@cisco.com Wed Dec 21 17:16:18 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCF211E80E3 for ; Wed, 21 Dec 2011 17:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+bWKfhTuVZa for ; Wed, 21 Dec 2011 17:16:17 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8008311E80C0 for ; Wed, 21 Dec 2011 17:16:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4567; q=dns/txt; s=iport; t=1324516577; x=1325726177; h=date:from:subject:to:cc:message-id:mime-version; bh=SIst5SAGWLdqgQJC3w2rAbETTvquGWFpCzlrp3dN5kM=; b=F25Swg2OEMrNur6gEaYUXZ2RfBT3f27MYEDGX3HIx0PSS8MAnzUXvVdz 3his5xCLI0eIsJoz+B4KkZfaGh3icauTsIijYQ/Ne1/vrYAJLb/Q7z9OT fL7XVoIgU2Y6LEk0FCkye1LqjxtBE9CEIRRLoFobANJ+pKUfQ34DSpWTI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFABEppk6tJV2d/2dsb2JhbACRAwGNV3iUVZI0hhkEhlCJQY8W X-IronPort-AV: E=Sophos;i="4.71,390,1320624000"; d="scan'208";a="43532046" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 22 Dec 2011 01:16:17 +0000 Received: from Magno.Cisco.COM (magno.cisco.com [172.16.177.227]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pBM1GGbS013206 for ; Thu, 22 Dec 2011 01:16:16 GMT Received: from Cisco.COM by Cisco.COM (PMDF V5.1-7 #12361) id <01O9UR5SKA1296VL1D@Cisco.COM> for ipsec@ietf.org; Wed, 21 Dec 2011 17:16:14 PST Date: Wed, 21 Dec 2011 17:16:14 -0800 (PST) From: Mike Sullenberger To: ipsec@ietf.org Message-id: <01O9UR5SKAYW96VL1D@Cisco.COM> X-VMS-To: IN%"ipsec@ietf.org" X-VMS-Cc: MLS MIME-version: 1.0 Cc: MLS@cisco.com Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 01:16:18 -0000 Everyone, I noticed that in the four vendor presentations in the "P2P VPN - side meeting" in TAIPEI that none of vendors chose to extend or augment IKE/IPsec to solve this class of problems. This is not to say that vendors haven't chosen to extend IKE/IPsec to solve other classes of issues, I.e. XAuth and Mode-config. My firm belief is that IKE/IPsec is at the wrong level to solve or standardize the creation of encrypted dynamic mesh networks. DMVPN, as one example, has for over 8 years solved this issue by using protocols that are specifically designed for the different needs for creating encrypted dynamic mesh networks. If you modify IKE/IPsec to perform these functions then you will end up having to add (redo) the functionality of already existing protocols in IKE/IPsec and the result will not be able to do as "good" a job. 1. I have no problem with creating a problem statment including use cases, but I am not sure how usefull this will be coming from the ipsecME WG when the solution for the problem statement shouldn't be done in IKE/IPsec. 2. I don't see how nor why the ipsecME WG should be involved in vendors publishing an informational RFCs about their solutions. I didn't think that there is a need for a WG's approval or help to publish an informational RFC. Note, we (Cisco) have said that we are willing to submit an informational RFC about DMVPN and having it ready by August 2012 is fine. 3. Again I firmly believe that a standardized solution to encrypted dynamic mesh networks should not be done by modifying IKE/IPsec. Therefore the ipsecME WG is the not the right IETF WG to analyze and or select a solution. 4. At least three vendors (Cisco, Juniper and Alcatel) have very successfully implemented large-scale encrypted dynamic mesh networks by using IKE/IPsec for encryption, GRE for protocol independent tunneling, NHRP for endpoint discovery and Routing protocols (even static routing) for the routing/forwarding of data traffic (subnets) through the encrypted tunnels. I therefore vote against this change to the ipsecME WG charter. -1 Thanks, Mike Sullenberger >If we want Paul and Yaron to take this to our AD, we need to show >that there are more people who think these work items are a good >idea. More people than just me and MCR. So please show your >support (or objections!) soon. An "I think this is a good idea", >"I think we should use ternary logic", or "+1" is all it takes. > >Yoav > >On Dec 8, 2011, at 10:06 PM, Yoav Nir wrote: >> >> Agree. How about: >> >> In an environment with many IPsec gateways and remote clients that >> share an established trust infrastructure (in a single >> administrative domain or across multiple domains), customers want >> to get on-demand point-to-point IPsec capability for efficiency. >> However, this cannot be feasibly accomplished only with today's >> IPsec and IKE due to problems with address lookup, reachability, >> policy configuration, etc. >> >> The IPsecME working group will handle this large scale VPN problem >> by delivering the following: >> >> * The working group will create a problem statement document >> including use cases, definitions and proper requirements for >> discovery and updates. This document would be solution-agnostic. >> Should reach WG last call around October 2012. >> >> * The working group will review and help publish Informational >> documents describing current vendor proprietary solutions. >> These should be ready for IETF last call by August 2012. >> >> * The working group will choose a common solution for the >> discovery and update problems that will satisfy the >> requirements in the problem statement document. The working >> group may standardize one of the vendor solutions, a >> combination, an superset of such a solution, or a new >> protocol. >> >> +------------------------------------------------+ | Mike Sullenberger; DSE | | mls@cisco.com .:|:.:|:. | | Customer Advocacy CISCO | +------------------------------------------------+ +------------------------------------------------+ | Mike Sullenberger; DSE | | mls@cisco.com .:|:.:|:. | | Customer Advocacy CISCO | +------------------------------------------------+ From ynir@checkpoint.com Thu Dec 22 05:00:10 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2B821F8B33 for ; Thu, 22 Dec 2011 05:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHQlQI8dsbAT for ; Thu, 22 Dec 2011 05:00:09 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EF85621F8B2D for ; Thu, 22 Dec 2011 05:00:06 -0800 (PST) X-CheckPoint: {4EF3281C-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pBMD02PW003121; Thu, 22 Dec 2011 15:00:02 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 22 Dec 2011 15:00:01 +0200 From: Yoav Nir To: Mike Sullenberger Date: Thu, 22 Dec 2011 14:59:59 +0200 Thread-Topic: [IPsec] Large Scale VPN Thread-Index: AczAqZ0/Dy423cOwRnqZcBrOSxr3Lw== Message-ID: <9FE89CD6-07D8-44C6-B139-9EAC01721C20@checkpoint.com> References: <01O9UR5SKAYW96VL1D@Cisco.COM> In-Reply-To: <01O9UR5SKAYW96VL1D@Cisco.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Large Scale VPN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 13:00:10 -0000 SNefIE1pa2UNCk9uIERlYyAyMiwgMjAxMSwgYXQgMzoxNiBBTSwgTWlrZSBTdWxsZW5iZXJnZXIg d3JvdGU6DQoNCj4gRXZlcnlvbmUsDQo+IA0KPiBJIG5vdGljZWQgdGhhdCBpbiB0aGUgZm91ciB2 ZW5kb3IgcHJlc2VudGF0aW9ucyBpbiB0aGUgIlAyUCBWUE4gLSBzaWRlDQo+IG1lZXRpbmciIGlu IFRBSVBFSSB0aGF0IG5vbmUgb2YgdmVuZG9ycyBjaG9zZSB0byBleHRlbmQgb3IgYXVnbWVudCBJ S0UvSVBzZWMNCj4gdG8gc29sdmUgdGhpcyBjbGFzcyBvZiBwcm9ibGVtcy4gIFRoaXMgaXMgbm90 IHRvIHNheSB0aGF0IHZlbmRvcnMgaGF2ZW4ndA0KPiBjaG9zZW4gdG8gZXh0ZW5kIElLRS9JUHNl YyB0byBzb2x2ZSBvdGhlciBjbGFzc2VzIG9mIGlzc3VlcywgSS5lLiBYQXV0aCBhbmQNCj4gTW9k ZS1jb25maWcuDQo+IA0KPiBNeSBmaXJtIGJlbGllZiBpcyB0aGF0IElLRS9JUHNlYyBpcyBhdCB0 aGUgd3JvbmcgbGV2ZWwgdG8gc29sdmUgb3INCj4gc3RhbmRhcmRpemUgdGhlIGNyZWF0aW9uIG9m IGVuY3J5cHRlZCBkeW5hbWljIG1lc2ggbmV0d29ya3MuICBETVZQTiwgYXMgb25lDQo+IGV4YW1w bGUsIGhhcyBmb3Igb3ZlciA4IHllYXJzIHNvbHZlZCB0aGlzIGlzc3VlIGJ5IHVzaW5nIHByb3Rv Y29scyB0aGF0IGFyZQ0KPiBzcGVjaWZpY2FsbHkgZGVzaWduZWQgZm9yIHRoZSBkaWZmZXJlbnQg bmVlZHMgZm9yIGNyZWF0aW5nIGVuY3J5cHRlZCBkeW5hbWljDQo+IG1lc2ggbmV0d29ya3MuICBJ ZiB5b3UgbW9kaWZ5IElLRS9JUHNlYyB0byBwZXJmb3JtIHRoZXNlIGZ1bmN0aW9ucyB0aGVuIHlv dQ0KPiB3aWxsIGVuZCB1cCBoYXZpbmcgdG8gYWRkIChyZWRvKSB0aGUgZnVuY3Rpb25hbGl0eSBv ZiBhbHJlYWR5IGV4aXN0aW5nDQo+IHByb3RvY29scyBpbiBJS0UvSVBzZWMgYW5kIHRoZSByZXN1 bHQgd2lsbCBub3QgYmUgYWJsZSB0byBkbyBhcyAiZ29vZCIgYQ0KPiBqb2IuDQoNCkkgYmVsaWV2 ZSB0aGF0IElQc2VjIHR1bm5lbHMgd29yayB2ZXJ5IHdlbGwuIFRoZSBjdXJyZW50IHN0YW5kYXJk cyBsYWNrIHR3byB0aGluZ3M6DQogMS4gVGhlIGFiaWxpdHkgdG8gZGlzY292ZXIgaG93IHRvIGdl dCB0byBzb21lIGFkZHJlc3MgKHdoYXQgaXMgdGhlIG5leHQgZ2F0ZXdheQ0KICAgIHRvIHdoaWNo IEkgc2hvdWxkIGVzdGFibGlzaCBhIHR1bm5lbA0KIDIuIFRoZSBhYmlsaXR5IHRvIGVzdGFibGlz aCB0cnVzdCBiZXR3ZWVuIHR3byBnYXRld2F5cy4gSXQncyBub3QgZW5vdWdoIHRvIGZpbmQgDQog ICAgYW4gSVAgYWRkcmVzcyBmb3IgdGhlICJuZXh0IGhvcCIsIHlvdSBhbHNvIG5lZWQgdG8gbGVh cm4gaG93IHRvIGF1dGhlbnRpY2F0ZSANCiAgICBpdC4NCg0KUm91dGluZyBwcm90b2NvbHMgY2Fu IGRvICMxIG9uIHJlYWwgbmV0d29ya3MuIFJ1bm5pbmcgdGhlbSBvbiB0dW5uZWxzIHNlZW1zIHRv DQpiZSBsaWtlIHVzaW5nIGxpbmtzIGFzIG1ldGFwaG9ycyBmb3IgdHVubmVscy4gQnV0IHRoYXQn cyBqdXN0IG15IGJpYXMuDQpUaGV5IGRvbid0IGRvIG11Y2ggZm9yICMyIHVubGVzcyB5b3UgZXh0 ZW5kIHRoZW0sIGFuZCB0aGVuIHlvdSBtaWdodCBhcyB3ZWxsIA0KZXh0ZW5kIGFueSBvdGhlciBw cm90b2NvbC4NCg0KPiANCj4gICAxLiBJIGhhdmUgbm8gcHJvYmxlbSB3aXRoIGNyZWF0aW5nIGEg cHJvYmxlbSBzdGF0bWVudCBpbmNsdWRpbmcgdXNlDQo+ICAgICAgY2FzZXMsIGJ1dCBJIGFtIG5v dCBzdXJlIGhvdyB1c2VmdWxsIHRoaXMgd2lsbCBiZSBjb21pbmcgZnJvbSB0aGUNCj4gICAgICBp cHNlY01FIFdHIHdoZW4gdGhlIHNvbHV0aW9uIGZvciB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgc2hv dWxkbid0DQo+ICAgICAgYmUgZG9uZSBpbiBJS0UvSVBzZWMuDQoNCkkgdGhpbmsgdGhlIHNvbHV0 aW9uIGlzIGZvciB0aGUgSVBzZWNNRSBncm91cCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgaXQgaXMg aW4gSUtFLCBpbiBhIHdlYiBzZXJ2aWNlLCBvciBpbiBhIGNvbWJpbmF0aW9uIG9mIG1HUkUsIE5I UlAgYW5kIE9TUEYuIFRoaXMgaXMgYWJvdXQgYnVpbGRpbmcgbGFyZ2Ugc2NhbGUgSVBzZWMgVlBO cywgYW5kIHRoYXQncyB0aGUgam9iIG9mIHRoZSBJUHNlY01FIGdyb3VwLCBldmVuIGlmIGl0IGlu dm9sdmVzIGV4dGVuZGluZyBhIHJvdXRpbmcgcHJvdG9jb2wuDQoNCj4gICAyLiBJIGRvbid0IHNl ZSBob3cgbm9yIHdoeSB0aGUgaXBzZWNNRSBXRyBzaG91bGQgYmUgaW52b2x2ZWQgaW4gdmVuZG9y cw0KPiAgICAgIHB1Ymxpc2hpbmcgYW4gaW5mb3JtYXRpb25hbCBSRkNzIGFib3V0IHRoZWlyIHNv bHV0aW9ucy4gSSBkaWRuJ3QgdGhpbmsNCj4gICAgICB0aGF0IHRoZXJlIGlzIGEgbmVlZCBmb3Ig YSBXRydzIGFwcHJvdmFsIG9yIGhlbHAgdG8gcHVibGlzaCBhbg0KPiAgICAgIGluZm9ybWF0aW9u YWwgUkZDLg0KPiANCj4gICAgICBOb3RlLCB3ZSAoQ2lzY28pIGhhdmUgc2FpZCB0aGF0IHdlIGFy ZSB3aWxsaW5nIHRvIHN1Ym1pdCBhbg0KPiAgICAgIGluZm9ybWF0aW9uYWwgUkZDIGFib3V0IERN VlBOIGFuZCBoYXZpbmcgaXQgcmVhZHkgYnkgQXVndXN0IDIwMTIgaXMNCj4gICAgICBmaW5lLg0K DQpUaGUgdGVybSBJIHVzZWQgd2FzICJyZXZpZXcgYW5kIGhlbHAgcHVibGlzaCIuIEl0J3MgZ29p bmcgdG8gYmUgYW4gSW5mb3JtYXRpb25hbCBkb2N1bWVudCBkZXNjcmliaW5nIGFuIGV4aXN0aW5n IHRlY2hub2xvZ3kuIE9mIGNvdXJzZSB0aGUgV0cgaGFzIG5vIGlucHV0IG9uIHRoZSB0ZWNobmlj YWwgaXNzdWVzIGluIERNVlBOLiBUaGUgY29tbWVudHMgeW91J2xsIGJlIGFibGUgdG8gZ2V0IGZy b20gdGhlIGdyb3VwIGFyZSBhbG9uZyB0aGUgbGluZXMgb2YgInNlY3Rpb24gIzMgaXMgbm90IGNs ZWFyIiwgb3IgImNvdWxkIHlvdSByZXBocmFzZSBzZWN0aW9uIDIuMyBpbiBSRkMgNDMwMSB0ZXJt aW5vbG9neT8iLCBub3QgImxldCdzIGNoYW5nZSB0aGUgZW5jb2RpbmcgaGVyZSB0byBYTUwiDQoN Cj4gICAzLiBBZ2FpbiBJIGZpcm1seSBiZWxpZXZlIHRoYXQgYSBzdGFuZGFyZGl6ZWQgc29sdXRp b24gdG8gZW5jcnlwdGVkDQo+ICAgICAgZHluYW1pYyBtZXNoIG5ldHdvcmtzIHNob3VsZCBub3Qg YmUgZG9uZSBieSBtb2RpZnlpbmcgSUtFL0lQc2VjLg0KPiAgICAgIFRoZXJlZm9yZSB0aGUgaXBz ZWNNRSBXRyBpcyB0aGUgbm90IHRoZSByaWdodCBJRVRGIFdHIHRvIGFuYWx5emUgYW5kDQo+ICAg ICAgb3Igc2VsZWN0IGEgc29sdXRpb24uDQoNCkkgdGhpbmsgb3RoZXJ3aXNlLCByZWdhcmRsZXNz IG9mIHRoZSBzcGVjaWZpYyB0ZWNobm9sb2d5Lg0KDQo+ICAgNC4gQXQgbGVhc3QgdGhyZWUgdmVu ZG9ycyAoQ2lzY28sIEp1bmlwZXIgYW5kIEFsY2F0ZWwpIGhhdmUgdmVyeQ0KPiAgICAgIHN1Y2Nl c3NmdWxseSBpbXBsZW1lbnRlZCBsYXJnZS1zY2FsZSBlbmNyeXB0ZWQgZHluYW1pYyBtZXNoIG5l dHdvcmtzDQo+ICAgICAgYnkgdXNpbmcgSUtFL0lQc2VjIGZvciBlbmNyeXB0aW9uLCBHUkUgZm9y IHByb3RvY29sIGluZGVwZW5kZW50DQo+ICAgICAgdHVubmVsaW5nLCBOSFJQIGZvciBlbmRwb2lu dCBkaXNjb3ZlcnkgYW5kIFJvdXRpbmcgcHJvdG9jb2xzIChldmVuDQo+ICAgICAgc3RhdGljIHJv dXRpbmcpIGZvciB0aGUgcm91dGluZy9mb3J3YXJkaW5nIG9mIGRhdGEgdHJhZmZpYyAoc3VibmV0 cykNCj4gICAgICB0aHJvdWdoIHRoZSBlbmNyeXB0ZWQgdHVubmVscy4NCg0KSSBzZWVtIHRvIHJl bWVtYmVyIGZyb20gdGhlIEp1bmlwZXIgcHJlc2VudGF0aW9uIHRoYXQgdGhleSBkaWQgbm90IHVz ZSBHUkUgKGV4Y2VwdCBhcyBhIENpc2NvIGNvbXBhdGliaWxpdHkgZmVhdHVyZSAtIENoZWNrIFBv aW50IGhhcyB0aGF0IHRvbykuIE5vIGlkZWEgYWJvdXQgQWxjYXRlbA0KPiANCj4gSSB0aGVyZWZv cmUgdm90ZSBhZ2FpbnN0IHRoaXMgY2hhbmdlIHRvIHRoZSBpcHNlY01FIFdHIGNoYXJ0ZXIuDQo+ IA0KPiAtMQ0KPiANCj4gVGhhbmtzLA0KPiANCj4gTWlrZSBTdWxsZW5iZXJnZXINCj4gDQo+PiBJ ZiB3ZSB3YW50IFBhdWwgYW5kIFlhcm9uIHRvIHRha2UgdGhpcyB0byBvdXIgQUQsIHdlIG5lZWQg dG8gc2hvdw0KPj4gdGhhdCB0aGVyZSBhcmUgbW9yZSBwZW9wbGUgd2hvIHRoaW5rIHRoZXNlIHdv cmsgaXRlbXMgYXJlIGEgZ29vZA0KPj4gaWRlYS4gTW9yZSBwZW9wbGUgdGhhbiBqdXN0IG1lIGFu ZCBNQ1IuICBTbyBwbGVhc2Ugc2hvdyB5b3VyDQo+PiBzdXBwb3J0IChvciBvYmplY3Rpb25zISkg c29vbi4gQW4gIkkgdGhpbmsgdGhpcyBpcyBhIGdvb2QgaWRlYSIsDQo+PiAiSSB0aGluayB3ZSBz aG91bGQgdXNlIHRlcm5hcnkgbG9naWMiLCBvciAiKzEiIGlzIGFsbCBpdCB0YWtlcy4NCj4+IA0K Pj4gWW9hdg0KPj4gDQo+PiBPbiBEZWMgOCwgMjAxMSwgYXQgMTA6MDYgUE0sIFlvYXYgTmlyIHdy b3RlOg0KPj4+IA0KPj4+IEFncmVlLiBIb3cgYWJvdXQ6DQo+Pj4gDQo+Pj4gSW4gYW4gZW52aXJv bm1lbnQgd2l0aCBtYW55IElQc2VjIGdhdGV3YXlzIGFuZCByZW1vdGUgY2xpZW50cyB0aGF0DQo+ Pj4gc2hhcmUgYW4gZXN0YWJsaXNoZWQgdHJ1c3QgaW5mcmFzdHJ1Y3R1cmUgKGluIGEgc2luZ2xl DQo+Pj4gYWRtaW5pc3RyYXRpdmUgZG9tYWluIG9yIGFjcm9zcyBtdWx0aXBsZSBkb21haW5zKSwg Y3VzdG9tZXJzIHdhbnQNCj4+PiB0byBnZXQgb24tZGVtYW5kIHBvaW50LXRvLXBvaW50IElQc2Vj IGNhcGFiaWxpdHkgZm9yIGVmZmljaWVuY3kuDQo+Pj4gSG93ZXZlciwgdGhpcyBjYW5ub3QgYmUg ZmVhc2libHkgYWNjb21wbGlzaGVkIG9ubHkgd2l0aCB0b2RheSdzDQo+Pj4gSVBzZWMgYW5kIElL RSBkdWUgdG8gcHJvYmxlbXMgd2l0aCBhZGRyZXNzIGxvb2t1cCwgcmVhY2hhYmlsaXR5LA0KPj4+ IHBvbGljeSBjb25maWd1cmF0aW9uLCBldGMuDQo+Pj4gDQo+Pj4gVGhlIElQc2VjTUUgd29ya2lu ZyBncm91cCB3aWxsIGhhbmRsZSB0aGlzIGxhcmdlIHNjYWxlIFZQTiBwcm9ibGVtDQo+Pj4gYnkg ZGVsaXZlcmluZyB0aGUgZm9sbG93aW5nOg0KPj4+IA0KPj4+ICogVGhlIHdvcmtpbmcgZ3JvdXAg d2lsbCBjcmVhdGUgYSBwcm9ibGVtIHN0YXRlbWVudCBkb2N1bWVudA0KPj4+ICBpbmNsdWRpbmcg dXNlIGNhc2VzLCBkZWZpbml0aW9ucyBhbmQgcHJvcGVyIHJlcXVpcmVtZW50cyBmb3INCj4+PiAg ZGlzY292ZXJ5IGFuZCB1cGRhdGVzLiBUaGlzIGRvY3VtZW50IHdvdWxkIGJlIHNvbHV0aW9uLWFn bm9zdGljLg0KPj4+ICBTaG91bGQgcmVhY2ggV0cgbGFzdCBjYWxsIGFyb3VuZCBPY3RvYmVyIDIw MTIuDQo+Pj4gDQo+Pj4gKiBUaGUgd29ya2luZyBncm91cCB3aWxsIHJldmlldyBhbmQgaGVscCBw dWJsaXNoIEluZm9ybWF0aW9uYWwNCj4+PiAgZG9jdW1lbnRzIGRlc2NyaWJpbmcgY3VycmVudCB2 ZW5kb3IgcHJvcHJpZXRhcnkgc29sdXRpb25zLg0KPj4+ICBUaGVzZSBzaG91bGQgYmUgcmVhZHkg Zm9yIElFVEYgbGFzdCBjYWxsIGJ5IEF1Z3VzdCAyMDEyLg0KPj4+IA0KPj4+ICogVGhlIHdvcmtp bmcgZ3JvdXAgd2lsbCBjaG9vc2UgYSBjb21tb24gc29sdXRpb24gZm9yIHRoZQ0KPj4+ICBkaXNj b3ZlcnkgYW5kIHVwZGF0ZSBwcm9ibGVtcyB0aGF0IHdpbGwgc2F0aXNmeSB0aGUNCj4+PiAgcmVx dWlyZW1lbnRzIGluIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBkb2N1bWVudC4gVGhlIHdvcmtpbmcN Cj4+PiAgZ3JvdXAgbWF5IHN0YW5kYXJkaXplIG9uZSBvZiB0aGUgdmVuZG9yIHNvbHV0aW9ucywg YQ0KPj4+ICBjb21iaW5hdGlvbiwgYW4gc3VwZXJzZXQgb2Ygc3VjaCBhIHNvbHV0aW9uLCBvciBh IG5ldw0KPj4+ICBwcm90b2NvbC4NCj4+PiANCj4+PiANCj4gDQo+ICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+IHwgTWlrZSBTdWxsZW5iZXJnZXI7 IERTRSAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+IHwgbWxzQGNpc2NvLmNvbSAgICAgICAg ICAgICAgICAuOnw6Ljp8Oi4gICAgICAgICB8DQo+IHwgQ3VzdG9tZXIgQWR2b2NhY3kgICAgICAg ICAgICAgIENJU0NPICAgICAgICAgICB8DQo+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+IA0KPiANCj4gDQo+ICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+IHwgTWlrZSBTdWxsZW5iZXJnZXI7IERT RSAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+IHwgbWxzQGNpc2NvLmNvbSAgICAgICAgICAg ICAgICAuOnw6Ljp8Oi4gICAgICAgICB8DQo+IHwgQ3VzdG9tZXIgQWR2b2NhY3kgICAgICAgICAg ICAgIENJU0NPICAgICAgICAgICB8DQo+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IElQc2VjIG1haWxpbmcgbGlzdA0KPiBJUHNlY0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQo+IA0KPiBTY2FubmVk IGJ5IENoZWNrIFBvaW50IFRvdGFsIFNlY3VyaXR5IEdhdGV3YXkuDQoNCg== From gpoothia@microsoft.com Thu Dec 22 11:07:53 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B926C11E8095 for ; Thu, 22 Dec 2011 11:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lojzorAsRNQw for ; Thu, 22 Dec 2011 11:07:52 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id A90EA11E8093 for ; Thu, 22 Dec 2011 11:07:51 -0800 (PST) Received: from mail47-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 22 Dec 2011 19:07:38 +0000 Received: from mail47-ch1 (localhost [127.0.0.1]) by mail47-ch1-R.bigfish.com (Postfix) with ESMTP id 7AB0B401D5 for ; Thu, 22 Dec 2011 19:08:15 +0000 (UTC) X-SpamScore: 0 X-BigFish: VS0(zzc85fhzz1202hzz8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-FB-SS: 13, Received-SPF: pass (mail47-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=gpoothia@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail47-ch1 (localhost.localdomain [127.0.0.1]) by mail47-ch1 (MessageSwitch) id 1324580895286136_2590; Thu, 22 Dec 2011 19:08:15 +0000 (UTC) Received: from CH1EHSMHS014.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail47-ch1.bigfish.com (Postfix) with ESMTP id 410BD80046 for ; Thu, 22 Dec 2011 19:08:15 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS014.bigfish.com (10.43.70.14) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 22 Dec 2011 19:07:37 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.251]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0247.005; Thu, 22 Dec 2011 11:07:34 -0800 From: Gaurav Poothia To: "ipsec@ietf.org" Thread-Topic: Question about ECDSA cert usage for IKEv2 auth Thread-Index: AczA3PWOAFGS65FITcimoorNuDtLjA== Date: Thu, 22 Dec 2011 19:07:33 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_CB499891AA34514FA9A903C49361CE4A12EF1412TK5EX14MBXC292r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: Brian Swander Subject: [IPsec] Question about ECDSA cert usage for IKEv2 auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 19:07:53 -0000 --_000_CB499891AA34514FA9A903C49361CE4A12EF1412TK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, The basic IKEv2 cert auth mechanism for RSA (from RFC 5996) seems to be to = hash using SHA-1 before signing. However when using ECDSA certs for IKEv2 I am trying to make sure I am read= ing RFC 4754 correctly when it says the following: "Moreover, ECDSA cannot be specified for IKEv2 independently of an associated hash function since IKEv2 does not have a transform type for hash functions. For this reason, it is necessary to specify the hash function as part of the signature algorithm. Furthermore, the elliptic curve group must be specified since the choice of hash function depends on it as well. As a result, it is necessary to specify three signature algorithms, named ECDSA-256, ECDSA-384, and ECDSA-521. Each of these algorithms represents an instantiation of the ECDSA algorithm using a particular elliptic curve group and hash function. The three hash functions are specified in [SHS]. For reasons of consistency, this document defines the signatures for IKE in the same way. Digital Signature Algorithm Elliptic Curve Group Hash Function ----------- -------------------------- --------------- ECDSA-256 256-bit random ECP group SHA-256 ECDSA-384 384-bit random ECP group SHA-384 ECDSA-521 521-bit random ECP group SHA-512" Does this mean we proceed just like RSA here but hash with SHA-256 and not = SHA-1 for ECDSA-256 cert and then proceed to sign as usual. Similarly use SHA-384 and SHA-512 for ECDSA-384 and ECDSA-521 respectively. Is that the correct reading of this excerpt? Thanks --_000_CB499891AA34514FA9A903C49361CE4A12EF1412TK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

The basic IKEv2 cert auth mechanism for RSA (from RF= C 5996) seems to be to hash using SHA-1 before signing.

 

However when using ECDSA certs for IKEv2 I am trying= to make sure I am reading RFC 4754 correctly when it says the following:

R= 20;Moreover, ECDSA cannot be specified for IKEv2

   independently of an associated hash function sinc= e IKEv2 does not

   have a transform type for hash functions.  F= or this reason, it is

   necessary to specify the hash function as part of= the signature

   algorithm.  Furthermore, the elliptic curve = group must be specified

   since the choice of hash function depends on it a= s well.  As a

   result, it is necessary to specify three signatur= e algorithms, named

   ECDSA-256, ECDSA-384, and ECDSA-521.  Each o= f these algorithms

   represents an instantiation of the ECDSA algorith= m using a particular

   elliptic curve group and hash function.  The= three hash functions are

   specified in [SHS].  For reasons of consiste= ncy, this document

   defines the signatures for IKE in the same way.

 

        Digital<= /span>

       Signature

       Algorithm  &nbs= p;         Elliptic Curve Group&nbs= p;       Hash Function

      -----------   &n= bsp;    --------------------------    -------= --------

       ECDSA-256  &nbs= p;       256-bit random ECP group  =       SHA-256

       ECDSA-384  &nbs= p;       384-bit random ECP group  =       SHA-384

       ECDSA-521  &nbs= p;       521-bit random ECP group  =       SHA-512”

 

Does this mean we proceed just like RSA here but has= h with SHA-256 and not SHA-1 for ECDSA-256 cert and then proceed to sign as= usual.

Similarly use SHA-384 and SHA-512 for ECDSA-384 and = ECDSA-521 respectively.

Is that the correct reading of this excerpt?

 

Thanks

 

--_000_CB499891AA34514FA9A903C49361CE4A12EF1412TK5EX14MBXC292r_-- From ynir@checkpoint.com Thu Dec 22 13:35:20 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CA81F0C4C for ; Thu, 22 Dec 2011 13:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4LN36tW4fuF for ; Thu, 22 Dec 2011 13:35:20 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C206A1F0C49 for ; Thu, 22 Dec 2011 13:35:18 -0800 (PST) X-CheckPoint: {4EF3A0D8-2-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pBMLZGpa028606; Thu, 22 Dec 2011 23:35:16 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 22 Dec 2011 23:35:08 +0200 From: Yoav Nir To: Gaurav Poothia Date: Thu, 22 Dec 2011 23:35:06 +0200 Thread-Topic: [IPsec] Question about ECDSA cert usage for IKEv2 auth Thread-Index: AczA8ZOeRtgDInzRRe2Mwqdi+zcR1w== Message-ID: <933F7325-CD75-4494-80D2-C3354E0CBB15@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_933F7325CD75449480D2C3354E0CBB15checkpointcom_" MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Brian Swander Subject: Re: [IPsec] Question about ECDSA cert usage for IKEv2 auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 21:35:20 -0000 --_000_933F7325CD75449480D2C3354E0CBB15checkpointcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Dec 22, 2011, at 9:07 PM, Gaurav Poothia wrote: Hello, The basic IKEv2 cert auth mechanism for RSA (from RFC 5996) seems to be to = hash using SHA-1 before signing. However when using ECDSA certs for IKEv2 I am trying to make sure I am read= ing RFC 4754 correctly when it says the following: =93Moreover, ECDSA cannot be specified for IKEv2 independently of an associated hash function since IKEv2 does not have a transform type for hash functions. For this reason, it is necessary to specify the hash function as part of the signature algorithm. Furthermore, the elliptic curve group must be specified since the choice of hash function depends on it as well. As a result, it is necessary to specify three signature algorithms, named ECDSA-256, ECDSA-384, and ECDSA-521. Each of these algorithms represents an instantiation of the ECDSA algorithm using a particular elliptic curve group and hash function. The three hash functions are specified in [SHS]. For reasons of consistency, this document defines the signatures for IKE in the same way. Digital Signature Algorithm Elliptic Curve Group Hash Function ----------- -------------------------- --------------- ECDSA-256 256-bit random ECP group SHA-256 ECDSA-384 384-bit random ECP group SHA-384 ECDSA-521 521-bit random ECP group SHA-512=94 Does this mean we proceed just like RSA here but hash with SHA-256 and not = SHA-1 for ECDSA-256 cert and then proceed to sign as usual. Similarly use SHA-384 and SHA-512 for ECDSA-384 and ECDSA-521 respectively. Is that the correct reading of this excerpt? Hi Gaurav This is pretty much correct. With ECDSA you first hash with the specified h= ash function, and then sign the hash with the ECDSA group. Note how the num= bers almost match up, so the size of the has is exactly the size of the buf= fer to be signed. This is different from RSA, where the hash is much shorter than the buffer = to be signed. Even the longest hash anyone uses has only a 512-bit output, = while 1024-bit signatures are considered too short these days, and 512-bit = signatures are apparently grounds for blacklisting a CA. With RSA you use t= he RSASSA-PKCS1-v1_5 signature scheme, and that includes an identifier for = the hash algorithm, so you can use any hash you want. Hope this helps Yoav --_000_933F7325CD75449480D2C3354E0CBB15checkpointcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =
On Dec 22, 2011, at 9:07 PM, Gaurav Poothia wrote:

Hello,
The basic IKEv2 cert auth mechan= ism for RSA (from RFC 5996) seems to be to hash using SHA-1 before signing.=
 
However when using ECDSA certs for IKEv2 I = am trying to make sure I am reading RFC 4754 correctly when it says the fol= lowing:
=93Moreover, ECDSA cannot be specified for IKEv2
   independently of an associated hash funct= ion since IKEv2 does not
   have a transfo= rm type for hash functions.  For this reason, it is<= /div>
   necessary to specify the hash function as part of the sig= nature
   algorithm.  Furthermore, th= e elliptic curve group must be specified
 &nbs= p; since the choice of hash function depends on it as well.  As a=
   result, it is necessary to specify three si= gnature algorithms, named
   ECDSA-256, EC= DSA-384, and ECDSA-521.  Each of these algorithms
   elliptic curve group and has= h function.  The three hash functions are
 = ;  specified in [SHS].  For reasons of consistency, this document=
   defines the signatures for IKE in the = same way.
 
 &nbs= p;      Digital
 &nbs= p;     Signature
  &nb= sp;    Algorithm       &n= bsp;    Elliptic Curve Group     &n= bsp;  Hash Function
    &nb= sp; -----------        -----------------= ---------    ---------------
 &n= bsp;     ECDSA-256      &= nbsp;   256-bit random ECP group     &nb= sp;  SHA-256
     &nbs= p; ECDSA-384          384-bit = random ECP group        SHA-384
       ECDSA-521  &n= bsp;       521-bit random ECP group &nbs= p;      SHA-512=94
 <= /o:p>
Does this mean we proceed just like RSA here but hash with SHA-256 a= nd not SHA-1 for ECDSA-256 cert and then proceed to sign as usual.
Similarly use SHA-384 and SHA-512 for ECDSA-384 and ECDSA-521 respectiv= ely.
Is that the correct reading of this excerpt?

Hi Gaurav

<= /div>
This is pretty much correct. With ECDSA you first hash with the s= pecified hash function, and then sign the hash with the ECDSA group. Note h= ow the numbers almost match up, so the size of the has is exactly the size = of the buffer to be signed.

This is different from= RSA, where the hash is much shorter than the buffer to be signed. Even the= longest hash anyone uses has only a 512-bit output, while 1024-bit signatu= res are considered too short these days, and 512-bit signatures are apparen= tly grounds for blacklisting a CA. With RSA you use the RSASSA-PKCS1-v1_5 signature= scheme, and that includes an identifier for the hash algorithm, so you can= use any hash you want.

Hope this helps

<= div>Yoav
=


= --_000_933F7325CD75449480D2C3354E0CBB15checkpointcom_-- From gpoothia@microsoft.com Thu Dec 22 14:30:38 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6931F0C4C for ; Thu, 22 Dec 2011 14:30:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3MjlalX0jnw for ; Thu, 22 Dec 2011 14:30:36 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 8770821F84DA for ; Thu, 22 Dec 2011 14:30:36 -0800 (PST) Received: from mail15-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE008.bigfish.com (10.43.70.58) with Microsoft SMTP Server id 14.1.225.23; Thu, 22 Dec 2011 22:30:24 +0000 Received: from mail15-ch1 (localhost [127.0.0.1]) by mail15-ch1-R.bigfish.com (Postfix) with ESMTP id 7BA934A03E5; Thu, 22 Dec 2011 22:31:02 +0000 (UTC) X-SpamScore: -29 X-BigFish: VS-29(zz9371Ic85fh328cM98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail15-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=gpoothia@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail15-ch1 (localhost.localdomain [127.0.0.1]) by mail15-ch1 (MessageSwitch) id 132459306039112_23269; Thu, 22 Dec 2011 22:31:00 +0000 (UTC) Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail15-ch1.bigfish.com (Postfix) with ESMTP id 00C0D480043; Thu, 22 Dec 2011 22:31:00 +0000 (UTC) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 22 Dec 2011 22:30:20 +0000 Received: from TK5EX14MBXC292.redmond.corp.microsoft.com ([169.254.1.251]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0247.005; Thu, 22 Dec 2011 14:30:30 -0800 From: Gaurav Poothia To: Yoav Nir Thread-Topic: [IPsec] Question about ECDSA cert usage for IKEv2 auth Thread-Index: AczA3PWOAFGS65FITcimoorNuDtLjAAV6rQAAA7WDsA= Date: Thu, 22 Dec 2011 22:30:30 +0000 Message-ID: References: <933F7325-CD75-4494-80D2-C3354E0CBB15@checkpoint.com> In-Reply-To: <933F7325-CD75-4494-80D2-C3354E0CBB15@checkpoint.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_CB499891AA34514FA9A903C49361CE4A12EF4765TK5EX14MBXC292r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "ipsec@ietf.org" , Brian Swander Subject: Re: [IPsec] Question about ECDSA cert usage for IKEv2 auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2011 22:30:38 -0000 --_000_CB499891AA34514FA9A903C49361CE4A12EF4765TK5EX14MBXC292r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Yoav! From: Yoav Nir [mailto:ynir@checkpoint.com] Sent: Thursday, December 22, 2011 1:35 PM To: Gaurav Poothia Cc: ipsec@ietf.org; Brian Swander Subject: Re: [IPsec] Question about ECDSA cert usage for IKEv2 auth On Dec 22, 2011, at 9:07 PM, Gaurav Poothia wrote: Hello, The basic IKEv2 cert auth mechanism for RSA (from RFC 5996) seems to be to = hash using SHA-1 before signing. However when using ECDSA certs for IKEv2 I am trying to make sure I am read= ing RFC 4754 correctly when it says the following: "Moreover, ECDSA cannot be specified for IKEv2 independently of an associated hash function since IKEv2 does not have a transform type for hash functions. For this reason, it is necessary to specify the hash function as part of the signature algorithm. Furthermore, the elliptic curve group must be specified since the choice of hash function depends on it as well. As a result, it is necessary to specify three signature algorithms, named ECDSA-256, ECDSA-384, and ECDSA-521. Each of these algorithms represents an instantiation of the ECDSA algorithm using a particular elliptic curve group and hash function. The three hash functions are specified in [SHS]. For reasons of consistency, this document defines the signatures for IKE in the same way. Digital Signature Algorithm Elliptic Curve Group Hash Function ----------- -------------------------- --------------- ECDSA-256 256-bit random ECP group SHA-256 ECDSA-384 384-bit random ECP group SHA-384 ECDSA-521 521-bit random ECP group SHA-512" Does this mean we proceed just like RSA here but hash with SHA-256 and not = SHA-1 for ECDSA-256 cert and then proceed to sign as usual. Similarly use SHA-384 and SHA-512 for ECDSA-384 and ECDSA-521 respectively. Is that the correct reading of this excerpt? Hi Gaurav This is pretty much correct. With ECDSA you first hash with the specified h= ash function, and then sign the hash with the ECDSA group. Note how the num= bers almost match up, so the size of the has is exactly the size of the buf= fer to be signed. This is different from RSA, where the hash is much shorter than the buffer = to be signed. Even the longest hash anyone uses has only a 512-bit output, = while 1024-bit signatures are considered too short these days, and 512-bit = signatures are apparently grounds for blacklisting a CA. With RSA you use t= he RSASSA-PKCS1-v1_5 signature scheme, and that includes an identifier for = the hash algorithm, so you can use any hash you want. Hope this helps Yoav --_000_CB499891AA34514FA9A903C49361CE4A12EF4765TK5EX14MBXC292r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Yoav!

 <= /p>

From: Yoav Nir= [mailto:ynir@checkpoint.com]
Sent: Thursday, December 22, 2011 1:35 PM
To: Gaurav Poothia
Cc: ipsec@ietf.org; Brian Swander
Subject: Re: [IPsec] Question about ECDSA cert usage for IKEv2 auth<= o:p>

 

 

On Dec 22, 2011, at 9:07 PM, Gaurav Poothia wrote:



Hello,

The basic IKEv2 cert auth mechanism for= RSA (from RFC 5996) seems to be to hash using SHA-1 before signing.

 

However when using ECDSA certs for IKEv= 2 I am trying to make sure I am reading RFC 4754 correctly when it says the= following:

“Moreover= , ECDSA cannot be specified for IKEv2=

   independently of an as= sociated hash function since IKEv2 does not<= /span>

   have a transform type = for hash functions.  For this reason, it is

   necessary to specify t= he hash function as part of the signature

   algorithm.  Furth= ermore, the elliptic curve group must be specified=

   since the choice of ha= sh function depends on it as well.  As a

   result, it is necessar= y to specify three signature algorithms, named

   ECDSA-256, ECDSA-384, = and ECDSA-521.  Each of these algorithms

   represents an instanti= ation of the ECDSA algorithm using a particular

   elliptic curve group a= nd hash function.  The three hash functions are

   specified in [SHS].&nb= sp; For reasons of consistency, this document

   defines the signatures= for IKE in the same way.

 

      = ;  Digital

      = ; Signature

      = ; Algorithm          &nbs= p; Elliptic Curve Group        Hash Func= tion

      ----= -------        -------------------------= -    ---------------

      = ; ECDSA-256          256-bit r= andom ECP group        SHA-256

      = ; ECDSA-384          384-bit r= andom ECP group        SHA-384

      = ; ECDSA-521          521-bit r= andom ECP group        SHA-512”

 

Does this mean we proceed just like RSA= here but hash with SHA-256 and not SHA-1 for ECDSA-256 cert and then proce= ed to sign as usual.

Similarly use SHA-384 and SHA-512 for E= CDSA-384 and ECDSA-521 respectively.

Is that the correct reading of this exc= erpt?

 

Hi Gaurav

 

This is pretty much correct. With ECDSA you first ha= sh with the specified hash function, and then sign the hash with the ECDSA = group. Note how the numbers almost match up, so the size of the has is exac= tly the size of the buffer to be signed.

 

This is different from RSA, where the hash is much s= horter than the buffer to be signed. Even the longest hash anyone uses has = only a 512-bit output, while 1024-bit signatures are considered too short t= hese days, and 512-bit signatures are apparently grounds for blacklisting a CA. With RSA you use the RSASSA-PKCS1-v1_5 signature scheme, and that= includes an identifier for the hash algorithm, so you can use any hash you= want.

 

Hope this helps

 

Yoav

 

 

 

--_000_CB499891AA34514FA9A903C49361CE4A12EF4765TK5EX14MBXC292r_-- From manav.bhatia@alcatel-lucent.com Thu Dec 29 10:51:46 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC6F21F8B18 for ; Thu, 29 Dec 2011 10:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.544 X-Spam-Level: X-Spam-Status: No, score=-6.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AI4KSrvCoOuX for ; Thu, 29 Dec 2011 10:51:46 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 56C1221F8AF8 for ; Thu, 29 Dec 2011 10:51:43 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pBTIpdi5014308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 29 Dec 2011 12:51:42 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBTIpb1C003516 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 30 Dec 2011 00:21:38 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 30 Dec 2011 00:21:37 +0530 From: "Bhatia, Manav (Manav)" To: "IPsec@ietf.org" Date: Fri, 30 Dec 2011 00:21:34 +0530 Thread-Topic: Moving Authentication Header (AH) to Historic Thread-Index: AczGWuNIu0K1AGG7T86TG4O9aPf5yg== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.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-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: [IPsec] Moving Authentication Header (AH) to Historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 18:51:47 -0000 Hi, We have had several discussions in the past about the utility of AH when ES= P with NULL encryption offers everything that AH has to offer. I have writt= en a very small draft that recommends moving AH to the Historic status. Thi= s document does NOT deprecate AH and it does NOT mean that people should st= op using AH now. All it means is that other WGs should use ESP-NULL wheneve= r defining integrity verification mechanisms and should only use AH when au= thentication cannot be achieved with ESP-NULL. I also discuss a few points = that people usually put in favor of AH over ESP and why I think that those = are not very relevant. I would love to hear feedback from the WG. The URL for the draft is: http://www.ietf.org/internet-drafts/draft-bhatia-moving-ah-to-historic-00.t= xt=20 Happy New Year in advance! Cheers, Manav From: internet-drafts@ietf.org=20 To: i-d-announce@ietf.org=20 Reply-to: internet-drafts@ietf.org=20 Subject: I-D Action: draft-bhatia-moving-ah-to-historic-00.txt=20 X-RSN: 1/0/935/40711/44097=20 =20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=20 =20 Title : Moving Authentication Header (AH) to Historic=20 Author(s) : Manav Bhatia=20 Filename : draft-bhatia-moving-ah-to-historic-00.txt=20 Pages : 5=20 Date : 2011-12-29=20 =20 This document recommends retiring Authentication Header (AH) and=20 discusses the reasons for doing so. It recommends moving RFC 4302 to=20 Historic status.=20 =20 =20 =20 A URL for this Internet-Draft is:=20 http://www.ietf.org/internet-drafts/draft-bhatia-moving-ah-to-historic-00.t= xt=20 =20 Internet-Drafts are also available by anonymous FTP at:=20 ftp://ftp.ietf.org/internet-drafts/=20 =20 This Internet-Draft can be retrieved at:=20 ftp://ftp.ietf.org/internet-drafts/draft-bhatia-moving-ah-to-historic-00.tx= t=20 = From melinda.shore@gmail.com Thu Dec 29 11:25:15 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B705B21F8B68 for ; Thu, 29 Dec 2011 11:25:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUlgNwOCiznD for ; Thu, 29 Dec 2011 11:25:15 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3814321F8AFB for ; Thu, 29 Dec 2011 11:25:15 -0800 (PST) Received: by iabz21 with SMTP id z21so2220616iab.31 for ; Thu, 29 Dec 2011 11:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ABZeiXVSs9MXlRF8Q7qyJE9cGPmLWUjUw8qKKP35t3A=; b=NZN8yJSn9UIVMKFqGVhVskb2CvQwyRYzR1tvK3PH7i7V3G+cLuPnQvSwq0pxlEhBvb HFxjVQAejHyJo2qTXOCoSOpyfUF3z8OHH3ypKd3hub2EZ8g0Sqz0nxpfYcWofQNjI7Cc Vo49/+wK38kmq+ZbRE3cDUtAGuN0lo33cyvDE= Received: by 10.42.155.136 with SMTP id u8mr25666541icw.12.1325186712731; Thu, 29 Dec 2011 11:25:12 -0800 (PST) Received: from polypro.local (66-230-87-15-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.87.15]) by mx.google.com with ESMTPS id r5sm45311673igl.3.2011.12.29.11.25.11 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Dec 2011 11:25:11 -0800 (PST) Message-ID: <4EFCBE95.8040408@gmail.com> Date: Thu, 29 Dec 2011 10:25:09 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.25) Gecko/20111213 Lightning/1.0b2 Thunderbird/3.1.17 MIME-Version: 1.0 To: ipsec@ietf.org References: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 19:25:15 -0000 It seems to me that the NAT problem is a *NAT* problem, not an AH problem. I'd want to hear from the wireless guys that they think ESP NULL is a reasonable substitute for AH, too. More generally the only reason I can see for moving something to historic is if it's not implemented and the environment has changed sufficiently so that it probably shouldn't be implemented. Don't think AH is there yet and I don't think it's a win to push more stuff into the publication queue. I'm not really against this but I'm definitely not in support of it. Melinda From ynir@checkpoint.com Thu Dec 29 13:38:06 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938FF21F8BAA for ; Thu, 29 Dec 2011 13:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 988E5iEmzuRY for ; Thu, 29 Dec 2011 13:38:06 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id AAB0621F8BA7 for ; Thu, 29 Dec 2011 13:38:05 -0800 (PST) X-CheckPoint: {4EFCDBBA-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pBTLc2PB007316; Thu, 29 Dec 2011 23:38:02 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 29 Dec 2011 23:38:02 +0200 From: Yoav Nir To: Melinda Shore Date: Thu, 29 Dec 2011 23:37:49 +0200 Thread-Topic: [IPsec] Moving Authentication Header (AH) to Historic Thread-Index: AczGciOGhkv7//K6TAa6adFuIsKZeQ== Message-ID: <8521357F-B4E3-4D14-9D1E-996713C2F027@checkpoint.com> References: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.com> <4EFCBE95.8040408@gmail.com> In-Reply-To: <4EFCBE95.8040408@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 21:38:06 -0000 On Dec 29, 2011, at 9:25 PM, Melinda Shore wrote: > It seems to me that the NAT problem is a *NAT* problem, not an AH > problem. I disagree with this. Section 3.3.3.1.1.1 of RFC 4302 lists source IP addre= ss and destination IP address as immutable fields. This may be true in some= idealized Internet where the end-to-end principle applies. It is definitel= y not true in our Internet, where NATs are everywhere. > I'd want to hear from the wireless guys that they think > ESP NULL is a reasonable substitute for AH, too. I'd like to hear that as well. My company removed AH from our (non wireless= ) product in 2003. We have yet to hear a complaint about this. > More generally the only reason I can see for moving something to > historic is if it's not implemented and the environment has changed > sufficiently so that it probably shouldn't be implemented. The environment has changed since 1995. NATs are ubiquitous now.=20 > Don't think > AH is there yet and I don't think it's a win to push more stuff into > the publication queue. I'm not really against this but I'm definitely > not in support of it. I think it is a win to reduce the number of ways to accomplish the same goa= l. That is why I was opposed to the publication of RFC 6467. It encourages = having multiple password methods. That is why the scep draft has an intende= d status of "historic", even though I would guess that SCEP is more widely = implemented and deployed than both the standards-track protocols combined. Moving AH to historic can point implementers and other working groups in a = single direction. Yoav= From kohn.jack@gmail.com Thu Dec 29 17:48:48 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1DF1F0C5D for ; Thu, 29 Dec 2011 17:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KrIKkcE7mflz for ; Thu, 29 Dec 2011 17:48:47 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D59E31F0C5A for ; Thu, 29 Dec 2011 17:48:40 -0800 (PST) Received: by qcsf15 with SMTP id f15so9845097qcs.31 for ; Thu, 29 Dec 2011 17:48:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=y+wzMSd5FbAtoVHbq5tooYZ9/+PcI+HKOB/1Sn/vXDc=; b=cloOZ90VCdgN1Irsl3wX/dz+2+krNZ01kWiFOLy9MUYxzZFYgLCCWXNxvr1iAKqGg4 GC7LAG7tVDWDGN7EnKZXOVQ9p6kHPgbooZbCF/9kXPHlr9gu38wPvJA/5FNDLPP5pYOi FSgOjqocR0mftyb1jZbUKQAy7j/fE9HOYMU58= MIME-Version: 1.0 Received: by 10.224.10.19 with SMTP id n19mr44747604qan.68.1325209720349; Thu, 29 Dec 2011 17:48:40 -0800 (PST) Received: by 10.229.39.139 with HTTP; Thu, 29 Dec 2011 17:48:40 -0800 (PST) In-Reply-To: <8521357F-B4E3-4D14-9D1E-996713C2F027@checkpoint.com> References: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.com> <4EFCBE95.8040408@gmail.com> <8521357F-B4E3-4D14-9D1E-996713C2F027@checkpoint.com> Date: Fri, 30 Dec 2011 07:18:40 +0530 Message-ID: From: Jack Kohn To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" , Melinda Shore Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 01:48:48 -0000 > I think it is a win to reduce the number of ways to accomplish the same g= oal. That is why I was opposed to the publication of RFC 6467. It encourage= s having multiple password methods. That is why the scep draft has an inten= ded status of "historic", even though I would guess that SCEP is more widel= y implemented and deployed than both the standards-track protocols combined= . > > Moving AH to historic can point implementers and other working groups in = a single direction. It will also help ending repeated "ESP-NULL versus AH" discussions on various mailing lists. I have not seen a single use case where ESP-NULL cannnot be substituted for AH. Even if there are some scenarios where ESP-NULL will not work, then those folks can continue using AH and I dont see how marking AH as Historic would really affect them. I support this work and i think its time that IETF took a stand on AH (which i personally find quite useless). Ever since 4301 moved AH to a MAY, i know a few vendors that have completely stopped supporting AH. Once again, if there are environments where ESP-NULL will not work (and i guess it probably has to do with the additional header that it inserts) then those environments can continue using AH. If folks dont want to move AH to historic then perhaps this document could be modified to say something in the lines of - "AH should not be preferred when designing new protocols and all attempts must be made to use ESP-NULL" Jack From melinda.shore@gmail.com Thu Dec 29 21:57:42 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2444821F8B12 for ; Thu, 29 Dec 2011 21:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcHEu4ALKrHB for ; Thu, 29 Dec 2011 21:57:41 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7530021F8B0F for ; Thu, 29 Dec 2011 21:57:41 -0800 (PST) Received: by ghbg18 with SMTP id g18so5262421ghb.31 for ; Thu, 29 Dec 2011 21:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MGMa1Od+9kXnKSCuMno3+YZo2dmO0gJ7RZXdFwaBTjQ=; b=Xcno/5Dp3Yu4rBtQYuiGIm1VcFpPdUlTeoN07oyn2nKqK5ztCyOu25Undsr7VCT8tE KLi1LN7KgL+3o/Oj1FErHnz6puxN/EDpyYhh8Q/1LocZ8ZpsLCNErJiREFyenIR9NPjl VyQ16XCywrzRo5B9HF0E+3JO2Er/dVQcLvmEU= Received: by 10.236.138.98 with SMTP id z62mr13884362yhi.24.1325224660982; Thu, 29 Dec 2011 21:57:40 -0800 (PST) Received: from polypro.local (66-230-87-15-rb1.fai.dsl.dynamic.acsalaska.net. [66.230.87.15]) by mx.google.com with ESMTPS id j21sm90299245ann.0.2011.12.29.21.57.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Dec 2011 21:57:39 -0800 (PST) Message-ID: <4EFD52D0.5040409@gmail.com> Date: Thu, 29 Dec 2011 20:57:36 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.25) Gecko/20111213 Lightning/1.0b2 Thunderbird/3.1.17 MIME-Version: 1.0 To: Jack Kohn References: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.com> <4EFCBE95.8040408@gmail.com> <8521357F-B4E3-4D14-9D1E-996713C2F027@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 05:57:42 -0000 On 12/29/11 4:48 PM, Jack Kohn wrote: > It will also help ending repeated "ESP-NULL versus AH" discussions on > various mailing lists. That is, I think, the first truly compelling argument I've come across. This has been something of an energy sink. Melinda From vnktshsriram@gmail.com Fri Dec 30 08:47:04 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A91621F845A for ; Fri, 30 Dec 2011 08:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk4KALBC8Z7F for ; Fri, 30 Dec 2011 08:47:03 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 80B3C21F843E for ; Fri, 30 Dec 2011 08:47:03 -0800 (PST) Received: by yenm7 with SMTP id m7so8935629yen.31 for ; Fri, 30 Dec 2011 08:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lCxN7g0186BcmUCVEyzomfv0MjQVWnqZ2uxZGYrJInM=; b=Gs5m9CshcZC//f++evnPKoScgwdGDwlujJPkM0coQFE2l9Uu/a9/PTX4rjOWCouDBu 8lwEv4o3lUahy1rhd0qIbgkVnKzPjCaI/4Fw1r6eLIMWJJCjwziOSN5n3sD//RYzaa3y 4r04pAl7RZ1y9YBYkHpzM+W/rMF/DYs9DLFFY= MIME-Version: 1.0 Received: by 10.236.77.170 with SMTP id d30mr34767169yhe.67.1325263622813; Fri, 30 Dec 2011 08:47:02 -0800 (PST) Received: by 10.236.183.228 with HTTP; Fri, 30 Dec 2011 08:47:02 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Fri, 30 Dec 2011 22:17:02 +0530 Message-ID: From: Venkatesh Sriram To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "IPsec@ietf.org" Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2011 16:47:04 -0000 AH and ESP can theoretically be applied in combination with each other to exploit the strengths of both protocols but, in most real-world scenarios, ESP alone is enough. When used together, AH authentication and ESP encryption results in a higher=A0percentage increase in network load for small files when compared to ESP encryption and=A0authentication. If the percentage of small files sent over a network is significant and the network has limited bandwidth (wireless?), then its always better to use ESP instead of AH to provide authentication. I am yet to come across a really compelling argument in favor of AH. A small nit - You should also mention RFC 5879 - "Heuristics for Detecting ESP-NULL Packets" along side RFC 5840 - WESP when you discuss deep inspecting ESP-NULL packets. Sriram On Fri, Dec 30, 2011 at 12:21 AM, Bhatia, Manav (Manav) wrote: > Hi, > > We have had several discussions in the past about the utility of AH when = ESP with NULL encryption offers everything that AH has to offer. I have wri= tten a very small draft that recommends moving AH to the Historic status. T= his document does NOT deprecate AH and it does NOT mean that people should = stop using AH now. All it means is that other WGs should use ESP-NULL whene= ver defining integrity verification mechanisms and should only use AH when = authentication cannot be achieved with ESP-NULL. I also discuss a few point= s that people usually put in favor of AH over ESP and why I think that thos= e are not very relevant. > > I would love to hear feedback from the WG. > > The URL for the draft is: > http://www.ietf.org/internet-drafts/draft-bhatia-moving-ah-to-historic-00= .txt > > Happy New Year in advance! > > Cheers, Manav > > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Reply-to: internet-drafts@ietf.org > Subject: I-D Action: draft-bhatia-moving-ah-to-historic-00.txt > X-RSN: 1/0/935/40711/44097 > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > Title : Moving Authentication Header (AH) to Historic > Author(s) : Manav Bhatia > Filename : draft-bhatia-moving-ah-to-historic-00.txt > Pages : 5 > Date : 2011-12-29 > > This document recommends retiring Authentication Header (AH) and > discusses the reasons for doing so. It recommends moving RFC 4302 to > Historic status. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bhatia-moving-ah-to-historic-00= .txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-bhatia-moving-ah-to-historic-00.= txt > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From zhangdacheng@huawei.com Fri Dec 30 19:58:57 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6D221F8513 for ; Fri, 30 Dec 2011 19:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.605 X-Spam-Level: X-Spam-Status: No, score=-0.605 tagged_above=-999 required=5 tests=[AWL=-1.301, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l72fMWfiKsYR for ; Fri, 30 Dec 2011 19:58:56 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id A3A5021F8508 for ; Fri, 30 Dec 2011 19:58:56 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LX1006X3V2791@szxga04-in.huawei.com> for ipsec@ietf.org; Sat, 31 Dec 2011 11:58:56 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LX100J3AV27BR@szxga04-in.huawei.com> for ipsec@ietf.org; Sat, 31 Dec 2011 11:58:55 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGC99686; Sat, 31 Dec 2011 11:58:55 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 31 Dec 2011 11:58:45 +0800 Received: from SZXEML528-MBX.china.huawei.com ([169.254.4.248]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Sat, 31 Dec 2011 11:58:44 +0800 Date: Sat, 31 Dec 2011 03:58:45 +0000 From: "Dacheng Zhang(Dacheng)" In-reply-to: X-Originating-IP: [10.108.4.62] To: Jack Kohn , Yoav Nir Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [IPsec] Moving Authentication Header (AH) to Historic Thread-index: AczGWuNIu0K1AGG7T86TG4O9aPf5yv//g0SAgAAlEYCAAEYWAP/9w6bA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.com> <4EFCBE95.8040408@gmail.com> <8521357F-B4E3-4D14-9D1E-996713C2F027@checkpoint.com> Cc: "ipsec@ietf.org" , Melinda Shore Subject: [IPsec] =?gb2312?b?tPC4tDogIE1vdmluZyBBdXRoZW50aWNhdGlvbiBIZWFk?= =?gb2312?b?ZXIgKEFIKSB0byBIaXN0b3JpYw==?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 03:58:57 -0000 >> If folks dont want to move AH to historic then perhaps this document >> could be modified to say something in the lines of - "AH should not be >> preferred when designing new protocols and all attempts must be made >> to use ESP-NULL" [Dacheng Zhang] Really like this suggestion. +1 >> >> Jack From yaronf.ietf@gmail.com Sat Dec 31 11:25:51 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB8021F845B for ; Sat, 31 Dec 2011 11:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.147 X-Spam-Level: X-Spam-Status: No, score=-103.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BzPho2snR7J for ; Sat, 31 Dec 2011 11:25:51 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D06D621F8448 for ; Sat, 31 Dec 2011 11:25:50 -0800 (PST) Received: by eekc14 with SMTP id c14so13330199eek.31 for ; Sat, 31 Dec 2011 11:25:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yA4uaH/bgFampBuEqN9D7OIcrWuRMyA+vdh0dk4A5sU=; b=QFBUn8HLZHSv9AJYMq1aHCUpvC1OvIFAJyWF8hx4rFrxawZRqESae0JFVUZW5BZg0T wggDly83N2i20bgfZEABZ+dMyDUJe165CIMgdncyt7FEx4bngvUYNOITlS/YqZxbUGaO QihkVG1gjD8pwaFK7CCrxq0v5oYy4idOgaPnc= Received: by 10.213.113.209 with SMTP id b17mr1747200ebq.141.1325359548385; Sat, 31 Dec 2011 11:25:48 -0800 (PST) Received: from [10.0.0.3] ([109.67.152.169]) by mx.google.com with ESMTPS id t1sm166552104eeb.3.2011.12.31.11.25.44 (version=SSLv3 cipher=OTHER); Sat, 31 Dec 2011 11:25:47 -0800 (PST) Message-ID: <4EFF61B5.2030604@gmail.com> Date: Sat, 31 Dec 2011 21:25:41 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: "Dacheng Zhang(Dacheng)" References: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.com> <4EFCBE95.8040408@gmail.com> <8521357F-B4E3-4D14-9D1E-996713C2F027@checkpoint.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Melinda Shore , Yoav Nir , Jack Kohn Subject: Re: [IPsec] =?utf-8?b?562U5aSNOiAgTW92aW5nIEF1dGhlbnRpY2F0aW9uIEhl?= =?utf-8?q?ader_=28AH=29_to_Historic?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2011 19:25:51 -0000 I agree that people should prefer ESP-null for all new uses. I spent a few minutes trying to look up the precise definition of "Historic Documents" in the IETF standards process. Since the definition appears to be extremely vague and may not clearly apply in this case, I strongly suggest that we avoid this rathole (and move to the next one), by adopting the proposed wording below. Manav's I-D is an Independent document and so its content is completely up to its author; OTOH, I'd rather not waste the group's energy on not-very-important process matters. What does matter is that implementers and standards bodies understand the strengths and weaknesses of our protocols. Wishing us all a Happy New Year 2012! Yaron On 12/31/2011 05:58 AM, Dacheng Zhang(Dacheng) wrote: >>> If folks dont want to move AH to historic then perhaps this document >>> could be modified to say something in the lines of - "AH should not be >>> preferred when designing new protocols and all attempts must be made >>> to use ESP-NULL" > [Dacheng Zhang] > Really like this suggestion. +1 >>> Jack > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From david.black@emc.com Sat Dec 31 17:29:29 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED5221F849E for ; Sat, 31 Dec 2011 17:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.581 X-Spam-Level: X-Spam-Status: No, score=-106.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gozKg6cM+SMH for ; Sat, 31 Dec 2011 17:29:28 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9AE21F84A5 for ; Sat, 31 Dec 2011 17:29:28 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q011TMBP031610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Dec 2011 20:29:25 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 31 Dec 2011 20:29:09 -0500 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q011T7A9024793; Sat, 31 Dec 2011 20:29:07 -0500 Received: from mx14a.corp.emc.com ([169.254.1.216]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Sat, 31 Dec 2011 20:29:07 -0500 From: To: Date: Sat, 31 Dec 2011 20:29:06 -0500 Thread-Topic: Moving Authentication Header (AH) to Historic Thread-Index: AczH8heAaINAR3eDS6aYauHUusiYOAAMDvMg Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B26@MX14A.corp.emc.com> References: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.com> <4EFCBE95.8040408@gmail.com> <8521357F-B4E3-4D14-9D1E-996713C2F027@checkpoint.com> <4EFF61B5.2030604@gmail.com> In-Reply-To: <4EFF61B5.2030604@gmail.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: ipsec@ietf.org Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 01:29:29 -0000 PiBJIHNwZW50IGEgZmV3IG1pbnV0ZXMgdHJ5aW5nIHRvIGxvb2sgdXAgdGhlIHByZWNpc2UgZGVm aW5pdGlvbiBvZg0KPiAiSGlzdG9yaWMgRG9jdW1lbnRzIiBpbiB0aGUgSUVURiBzdGFuZGFyZHMg cHJvY2Vzcy4gU2luY2UgdGhlIGRlZmluaXRpb24NCj4gYXBwZWFycyB0byBiZSBleHRyZW1lbHkg dmFndWUgYW5kIG1heSBub3QgY2xlYXJseSBhcHBseSBpbiB0aGlzIGNhc2UsDQoNCkZXSVcsIHRo ZSBkZWZpbml0aW9uIG9mICJIaXN0b3JpYyIgaXMgaW4gUkZDIDIwMjYsIGFuZCBJIGFncmVlIHdp dGggWWFyb24gdGhhdA0KaXQncyBub3QgZXhhY3RseSBwcmVjaXNlOg0KDQogICBBIHNwZWNpZmlj YXRpb24gdGhhdCBoYXMgYmVlbiBzdXBlcnNlZGVkIGJ5IGEgbW9yZSByZWNlbnQNCiAgIHNwZWNp ZmljYXRpb24gb3IgaXMgZm9yIGFueSBvdGhlciByZWFzb24gY29uc2lkZXJlZCB0byBiZSBvYnNv bGV0ZSBpcw0KICAgYXNzaWduZWQgdG8gdGhlICJIaXN0b3JpYyIgbGV2ZWwuICAoUHVyaXN0cyBo YXZlIHN1Z2dlc3RlZCB0aGF0IHRoZQ0KICAgd29yZCBzaG91bGQgYmUgIkhpc3RvcmljYWwiOyBo b3dldmVyLCBhdCB0aGlzIHBvaW50IHRoZSB1c2Ugb2YNCiAgICJIaXN0b3JpYyIgaXMgaGlzdG9y aWNhbC4pDQoNClRoZXJlIGlzIGEgc3VidGxlIGRpc3RpbmN0aW9uIGJldHdlZW4gT2Jzb2xldGUg YW5kIEhpc3RvcmljIC0gYW4gSGlzdG9yaWMgUkZDDQppcyBhbHdheXMgT2Jzb2xldGUsIGJ1dCBh biBPYnNvbGV0ZSBSRkMgbWF5IG5vdCBiZSBIaXN0b3JpYy4gIEJlZm9yZSBnb2luZyBhbnkNCmZ1 cnRoZXIsICBsZXQgbWUgc2F5IHRoYXQgSSBzdHJvbmdseSBhZ3JlZSB3aXRoIFlhcm9uIG9uIHBy aW9yaXRpZXM6DQoNCj4gSSBzdHJvbmdseSBzdWdnZXN0IHRoYXQgd2UgYXZvaWQgdGhpcyByYXRo b2xlIChhbmQgbW92ZSB0byB0aGUgbmV4dCBvbmUpLA0KPiBieSBhZG9wdGluZyB0aGUgcHJvcG9z ZWQgd29yZGluZyBiZWxvdy4gTWFuYXYncyBJLUQgaXMgYW4gSW5kZXBlbmRlbnQNCj4gZG9jdW1l bnQgYW5kIHNvIGl0cyBjb250ZW50IGlzIGNvbXBsZXRlbHkgdXAgdG8gaXRzIGF1dGhvcjsgT1RP SCwgSSdkDQo+IHJhdGhlciBub3Qgd2FzdGUgdGhlIGdyb3VwJ3MgZW5lcmd5IG9uIG5vdC12ZXJ5 LWltcG9ydGFudCBwcm9jZXNzDQo+IG1hdHRlcnMuIFdoYXQgZG9lcyBtYXR0ZXIgaXMgdGhhdCBp bXBsZW1lbnRlcnMgYW5kIHN0YW5kYXJkcyBib2RpZXMNCj4gdW5kZXJzdGFuZCB0aGUgc3RyZW5n dGhzIGFuZCB3ZWFrbmVzc2VzIG9mIG91ciBwcm90b2NvbHMuICANCg0KSW4gb3JkZXIgdG8gb2Jz b2xldGUgQUgsIHRoZSBkcmFmdCBoZWFkZXIgbmVlZHMgdG8gc2F5ICJPYnNvbGV0ZXM6IDQzMDIi LCBpbg0KYWRkaXRpb24gdG8gaXRzIGRpc2N1c3Npb24gb2YgbWFraW5nIFJGQyA0MzAyIEhpc3Rv cmljLiAgQm90aCBvZiB0aGUgZm9yZWdvaW5nDQpyZXF1aXJlIHRoYXQgdGhlIGRyYWZ0IG5vdCBi ZSBJbmZvcm1hdGlvbmFsOyBJJ2QgZ28gZnVydGhlciBhbmQgc3VnZ2VzdCB0aGF0IHdpdGgNCnN1 aXRhYmxlIGVkaXRpbmcgYW5kIHJldmlldywgdGhpcyBjb3VsZCBiZSBhIEJlc3QgQ3VycmVudCBQ cmFjdGljZSAoQkNQKSBSRkMsDQphcyB0aGUgcHJpbWFyeSBnb2FsIGlzIHRvIGRvY3VtZW50IHRo ZSBmb2xsb3dpbmcgYXMgY3VycmVudCBkZXNpZ24gcHJhY3RpY2U6DQoNCj4gPiAiQUggc2hvdWxk IG5vdCBiZQ0KPiA+IHByZWZlcnJlZCB3aGVuIGRlc2lnbmluZyBuZXcgcHJvdG9jb2xzIGFuZCBh bGwgYXR0ZW1wdHMgbXVzdCBiZSBtYWRlDQo+ID4gdG8gdXNlIEVTUC1OVUxMIg0KDQpJIGJlbGll dmUgdGhhdCBhIEJDUCBjYW4gYmUgdXNlZCB0byBjYXVzZSBhIHN0YW5kYXJkcyB0cmFjayBSRkMg dG8gYmVjb21lDQpvYnNvbGV0ZS4NCg0KVGhhbmtzLA0KLS1EYXZpZA0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRGF2aWQgTC4gQmxhY2ssIERp c3Rpbmd1aXNoZWQgRW5naW5lZXINCkVNQyBDb3Jwb3JhdGlvbiwgMTc2IFNvdXRoIFN0LiwgSG9w a2ludG9uLCBNQcKgIDAxNzQ4DQorMSAoNTA4KSAyOTMtNzk1M8KgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCBGQVg6ICsxICg1MDgpIDI5My03Nzg2DQpkYXZpZC5ibGFja0BlbWMuY29twqDCoMKgwqDC oMKgwqAgTW9iaWxlOiArMSAoOTc4KSAzOTQtNzc1NA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHNlYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWWFyb24gU2hlZmZlcg0KPiBTZW50OiBTYXR1cmRheSwg RGVjZW1iZXIgMzEsIDIwMTEgMjoyNiBQTQ0KPiBUbzogRGFjaGVuZyBaaGFuZyhEYWNoZW5nKQ0K PiBDYzogaXBzZWNAaWV0Zi5vcmc7IE1lbGluZGEgU2hvcmU7IFlvYXYgTmlyOyBKYWNrIEtvaG4N Cj4gU3ViamVjdDogUmU6IFtJUHNlY10g562U5aSNOiBNb3ZpbmcgQXV0aGVudGljYXRpb24gSGVh ZGVyIChBSCkgdG8gSGlzdG9yaWMNCj4gDQo+IEkgYWdyZWUgdGhhdCBwZW9wbGUgc2hvdWxkIHBy ZWZlciBFU1AtbnVsbCBmb3IgYWxsIG5ldyB1c2VzLg0KPiANCj4gSSBzcGVudCBhIGZldyBtaW51 dGVzIHRyeWluZyB0byBsb29rIHVwIHRoZSBwcmVjaXNlIGRlZmluaXRpb24gb2YNCj4gIkhpc3Rv cmljIERvY3VtZW50cyIgaW4gdGhlIElFVEYgc3RhbmRhcmRzIHByb2Nlc3MuIFNpbmNlIHRoZSBk ZWZpbml0aW9uDQo+IGFwcGVhcnMgdG8gYmUgZXh0cmVtZWx5IHZhZ3VlIGFuZCBtYXkgbm90IGNs ZWFybHkgYXBwbHkgaW4gdGhpcyBjYXNlLCBJDQo+IHN0cm9uZ2x5IHN1Z2dlc3QgdGhhdCB3ZSBh dm9pZCB0aGlzIHJhdGhvbGUgKGFuZCBtb3ZlIHRvIHRoZSBuZXh0IG9uZSksDQo+IGJ5IGFkb3B0 aW5nIHRoZSBwcm9wb3NlZCB3b3JkaW5nIGJlbG93LiBNYW5hdidzIEktRCBpcyBhbiBJbmRlcGVu ZGVudA0KPiBkb2N1bWVudCBhbmQgc28gaXRzIGNvbnRlbnQgaXMgY29tcGxldGVseSB1cCB0byBp dHMgYXV0aG9yOyBPVE9ILCBJJ2QNCj4gcmF0aGVyIG5vdCB3YXN0ZSB0aGUgZ3JvdXAncyBlbmVy Z3kgb24gbm90LXZlcnktaW1wb3J0YW50IHByb2Nlc3MNCj4gbWF0dGVycy4gV2hhdCBkb2VzIG1h dHRlciBpcyB0aGF0IGltcGxlbWVudGVycyBhbmQgc3RhbmRhcmRzIGJvZGllcw0KPiB1bmRlcnN0 YW5kIHRoZSBzdHJlbmd0aHMgYW5kIHdlYWtuZXNzZXMgb2Ygb3VyIHByb3RvY29scy4NCj4gDQo+ IFdpc2hpbmcgdXMgYWxsIGEgSGFwcHkgTmV3IFllYXIgMjAxMiENCj4gDQo+ICAgICAgWWFyb24N Cj4gDQo+IE9uIDEyLzMxLzIwMTEgMDU6NTggQU0sIERhY2hlbmcgWmhhbmcoRGFjaGVuZykgd3Jv dGU6DQo+ID4+PiBJZiBmb2xrcyBkb250IHdhbnQgdG8gbW92ZSBBSCB0byBoaXN0b3JpYyB0aGVu IHBlcmhhcHMgdGhpcyBkb2N1bWVudA0KPiA+Pj4gY291bGQgYmUgbW9kaWZpZWQgdG8gc2F5IHNv bWV0aGluZyBpbiB0aGUgbGluZXMgb2YgLSAiQUggc2hvdWxkIG5vdCBiZQ0KPiA+Pj4gcHJlZmVy cmVkIHdoZW4gZGVzaWduaW5nIG5ldyBwcm90b2NvbHMgYW5kIGFsbCBhdHRlbXB0cyBtdXN0IGJl IG1hZGUNCj4gPj4+IHRvIHVzZSBFU1AtTlVMTCINCj4gPiBbRGFjaGVuZyBaaGFuZ10NCj4gPiBS ZWFsbHkgbGlrZSB0aGlzIHN1Z2dlc3Rpb24uICsxDQo+ID4+PiBKYWNrDQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBJUHNlYyBtYWlsaW5n IGxpc3QNCj4gPiBJUHNlY0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXBzZWMNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IElQc2VjIG1haWxpbmcgbGlzdA0KPiBJUHNlY0BpZXRmLm9yZw0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQoNCg== From manav.bhatia@alcatel-lucent.com Sat Dec 31 17:53:22 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A6821F8479 for ; Sat, 31 Dec 2011 17:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNLNcldqbbKC for ; Sat, 31 Dec 2011 17:53:21 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE0E21F846B for ; Sat, 31 Dec 2011 17:53:21 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q011rDXn019684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 31 Dec 2011 19:53:17 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q011rC5f014564 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 1 Jan 2012 07:23:13 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Sun, 1 Jan 2012 07:23:12 +0530 From: "Bhatia, Manav (Manav)" To: "david.black@emc.com" , "yaronf.ietf@gmail.com" Date: Sun, 1 Jan 2012 07:23:11 +0530 Thread-Topic: Moving Authentication Header (AH) to Historic Thread-Index: AczH8heAaINAR3eDS6aYauHUusiYOAAMDvMgAAEStYA= Message-ID: <7C362EEF9C7896468B36C9B79200D8350D027BB264@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.com> <4EFCBE95.8040408@gmail.com> <8521357F-B4E3-4D14-9D1E-996713C2F027@checkpoint.com> <4EFF61B5.2030604@gmail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B26@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B26@MX14A.corp.emc.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 01:53:22 -0000 SGkgRGF2aWQgYW5kIFlhcm9uLA0KDQpJIHRoaW5rIGl0cyBwb3NzaWJsZSB0byBlZGl0IHRoZSBk cmFmdCBoZWFkZXJzIGFuZCB0aGUgdGV4dCBzbyB0aGF0IHdlIGJhc2ljYWxseSBzYXkgdGhhdCBB SCBzaG91bGQgTk9UIGJlIHVzZWQgZm9yIG5ld2VyIHByb3Bvc2FscyB1bmxlc3MgdGhlcmUgaXMg YSBidXJuaW5nIHJlYXNvbiB0byBkbyBzby4gQW5kIGlmIHNvbWVvbmUgd2FudHMgdG8gdXNlIEFI LCB0aGVuIHRoZXkgc2hvdWxkIGhhdmUgYSBwcmV0dHkgZ29vZCByZWFzb24gZm9yIGRvaW5nIHRo YXQuIEluIG15IGRyYWZ0IEkgY2xlYXJseSBzYXkgdGhhdCBBSCBkb2VzIGEgZ29vZCBqb2Igd2l0 aCB3aGF0cyBpdHMgc3VwcG9zZWQgdG8gZG8gLSBpbnRlZ3JpdHkgdmVyaWZpY2F0aW9uLiBIb3dl dmVyLCBFU1AtTlVMTCBkb2VzIHRoYXQgZXF1YWxseSBnb29kIGFuZCB0aGVyZSBpcyBubyBnb29k IHJlYXNvbiB0byB1c2UgQUggYW55IG1vcmUuIEkgd3JvdGUgdGhpcyBkcmFmdCBiZWNhdXNlIEkg d2FzIGhhdmluZyBhIHByaXZhdGUgZGlzY3Vzc2lvbiBvbiBQSU0gc2VjdXJpdHkgd2l0aCBhIGZl dyBmb2xrcyBhbmQgdGhlIGRpc2N1c3Npb24gc3RhcnRlZCB2ZWVyaW5nIHRvd2FyZHMgIkhleSBs ZXRzIHVzZSBBSCBzaW5jZSB3ZSB3YW50IHRvIHNub29wIGNlcnRhaW4gUElNIHBhY2tldHMgYW5k IEVTUC1OVUxMIHdvdWxkbuKAmXQgbGV0IHVzIGRvIHRoYXQiLiANCg0KU28sIHdoaWxlIHBlb3Bs ZSB3b3JraW5nIG9uIHNlY3VyaXR5IHVuZGVyc3RhbmQgdGhhdCBBSCBzaG91bGQgbm90IGJlIHVz ZWQgZm9yIG5ld2VyIHByb3RvY29scywgdGhlcmUgYXJlIGxvdHMgb2Ygb3RoZXJzIHdobyBkb27i gJl0Lg0KDQpJIGp1c3Qgd2FudGVkIHRoYXQgdG8gYmUgcG9pbnRlZCBvdXQgZXhwbGljaXRseS4g DQoNCkkgZG9u4oCZdCByZWFsbHkgY2FyZSB3aGV0aGVyIGl0cyB0aHJvdWdoIGFuIGluZm9ybWF0 aW9uYWwgUkZDLCBCQ1AsIHN0YW5kYXJkcyB0cmFjayBvciBzb21lIG90aGVyIHR5cGUgYXMgbG9u ZyBhcyB0aGUgbWVzc2FnZSBpcyBvdXQgbG91ZCBhbmQgY2xlYXIuIEhvd2V2ZXIsIGJlZm9yZSBz cGVuZGluZyBhbnkgbW9yZSBjeWNsZXMgb24gaXQgSSB3b3VsZCBmaXJzdCBsaWtlIHRvIGdhdWdl IHRoZSBpbnRlcmVzdCBsZXZlbCBpbiB0aGUgV0cgdG8gc2VlIGlmIHBlb3BsZSB0aGluayBpdOKA mXMgYW4gaWRlYSB3b3J0aCBzcGVuZGluZyB0aW1lIG9uLiBBbmQgaWYgbm90LCB0aGVuIHdoeS4N Cg0KQ2hlZXJzLCBNYW5hdg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaXBz ZWMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBkYXZpZC5ibGFja0BlbWMuY29tDQpTZW50OiBTdW5kYXksIEphbnVhcnkgMDEsIDIw MTIgNjo1OSBBTQ0KVG86IHlhcm9uZi5pZXRmQGdtYWlsLmNvbQ0KQ2M6IGlwc2VjQGlldGYub3Jn DQpTdWJqZWN0OiBSZTogW0lQc2VjXSBNb3ZpbmcgQXV0aGVudGljYXRpb24gSGVhZGVyIChBSCkg dG8gSGlzdG9yaWMNCg0KPiBJIHNwZW50IGEgZmV3IG1pbnV0ZXMgdHJ5aW5nIHRvIGxvb2sgdXAg dGhlIHByZWNpc2UgZGVmaW5pdGlvbiBvZiANCj4gIkhpc3RvcmljIERvY3VtZW50cyIgaW4gdGhl IElFVEYgc3RhbmRhcmRzIHByb2Nlc3MuIFNpbmNlIHRoZSANCj4gZGVmaW5pdGlvbiBhcHBlYXJz IHRvIGJlIGV4dHJlbWVseSB2YWd1ZSBhbmQgbWF5IG5vdCBjbGVhcmx5IGFwcGx5IGluIA0KPiB0 aGlzIGNhc2UsDQoNCkZXSVcsIHRoZSBkZWZpbml0aW9uIG9mICJIaXN0b3JpYyIgaXMgaW4gUkZD IDIwMjYsIGFuZCBJIGFncmVlIHdpdGggWWFyb24gdGhhdCBpdCdzIG5vdCBleGFjdGx5IHByZWNp c2U6DQoNCiAgIEEgc3BlY2lmaWNhdGlvbiB0aGF0IGhhcyBiZWVuIHN1cGVyc2VkZWQgYnkgYSBt b3JlIHJlY2VudA0KICAgc3BlY2lmaWNhdGlvbiBvciBpcyBmb3IgYW55IG90aGVyIHJlYXNvbiBj b25zaWRlcmVkIHRvIGJlIG9ic29sZXRlIGlzDQogICBhc3NpZ25lZCB0byB0aGUgIkhpc3Rvcmlj IiBsZXZlbC4gIChQdXJpc3RzIGhhdmUgc3VnZ2VzdGVkIHRoYXQgdGhlDQogICB3b3JkIHNob3Vs ZCBiZSAiSGlzdG9yaWNhbCI7IGhvd2V2ZXIsIGF0IHRoaXMgcG9pbnQgdGhlIHVzZSBvZg0KICAg Ikhpc3RvcmljIiBpcyBoaXN0b3JpY2FsLikNCg0KVGhlcmUgaXMgYSBzdWJ0bGUgZGlzdGluY3Rp b24gYmV0d2VlbiBPYnNvbGV0ZSBhbmQgSGlzdG9yaWMgLSBhbiBIaXN0b3JpYyBSRkMgaXMgYWx3 YXlzIE9ic29sZXRlLCBidXQgYW4gT2Jzb2xldGUgUkZDIG1heSBub3QgYmUgSGlzdG9yaWMuICBC ZWZvcmUgZ29pbmcgYW55IGZ1cnRoZXIsICBsZXQgbWUgc2F5IHRoYXQgSSBzdHJvbmdseSBhZ3Jl ZSB3aXRoIFlhcm9uIG9uIHByaW9yaXRpZXM6DQoNCj4gSSBzdHJvbmdseSBzdWdnZXN0IHRoYXQg d2UgYXZvaWQgdGhpcyByYXRob2xlIChhbmQgbW92ZSB0byB0aGUgbmV4dCANCj4gb25lKSwgYnkg YWRvcHRpbmcgdGhlIHByb3Bvc2VkIHdvcmRpbmcgYmVsb3cuIE1hbmF2J3MgSS1EIGlzIGFuIA0K PiBJbmRlcGVuZGVudCBkb2N1bWVudCBhbmQgc28gaXRzIGNvbnRlbnQgaXMgY29tcGxldGVseSB1 cCB0byBpdHMgDQo+IGF1dGhvcjsgT1RPSCwgSSdkIHJhdGhlciBub3Qgd2FzdGUgdGhlIGdyb3Vw J3MgZW5lcmd5IG9uIA0KPiBub3QtdmVyeS1pbXBvcnRhbnQgcHJvY2VzcyBtYXR0ZXJzLiBXaGF0 IGRvZXMgbWF0dGVyIGlzIHRoYXQgDQo+IGltcGxlbWVudGVycyBhbmQgc3RhbmRhcmRzIGJvZGll cyB1bmRlcnN0YW5kIHRoZSBzdHJlbmd0aHMgYW5kIHdlYWtuZXNzZXMgb2Ygb3VyIHByb3RvY29s cy4NCg0KSW4gb3JkZXIgdG8gb2Jzb2xldGUgQUgsIHRoZSBkcmFmdCBoZWFkZXIgbmVlZHMgdG8g c2F5ICJPYnNvbGV0ZXM6IDQzMDIiLCBpbiBhZGRpdGlvbiB0byBpdHMgZGlzY3Vzc2lvbiBvZiBt YWtpbmcgUkZDIDQzMDIgSGlzdG9yaWMuICBCb3RoIG9mIHRoZSBmb3JlZ29pbmcgcmVxdWlyZSB0 aGF0IHRoZSBkcmFmdCBub3QgYmUgSW5mb3JtYXRpb25hbDsgSSdkIGdvIGZ1cnRoZXIgYW5kIHN1 Z2dlc3QgdGhhdCB3aXRoIHN1aXRhYmxlIGVkaXRpbmcgYW5kIHJldmlldywgdGhpcyBjb3VsZCBi ZSBhIEJlc3QgQ3VycmVudCBQcmFjdGljZSAoQkNQKSBSRkMsIGFzIHRoZSBwcmltYXJ5IGdvYWwg aXMgdG8gZG9jdW1lbnQgdGhlIGZvbGxvd2luZyBhcyBjdXJyZW50IGRlc2lnbiBwcmFjdGljZToN Cg0KPiA+ICJBSCBzaG91bGQgbm90IGJlDQo+ID4gcHJlZmVycmVkIHdoZW4gZGVzaWduaW5nIG5l dyBwcm90b2NvbHMgYW5kIGFsbCBhdHRlbXB0cyBtdXN0IGJlIG1hZGUgDQo+ID4gdG8gdXNlIEVT UC1OVUxMIg0KDQpJIGJlbGlldmUgdGhhdCBhIEJDUCBjYW4gYmUgdXNlZCB0byBjYXVzZSBhIHN0 YW5kYXJkcyB0cmFjayBSRkMgdG8gYmVjb21lIG9ic29sZXRlLg0KDQpUaGFua3MsDQotLURhdmlk DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpE YXZpZCBMLiBCbGFjaywgRGlzdGluZ3Vpc2hlZCBFbmdpbmVlcg0KRU1DIENvcnBvcmF0aW9uLCAx NzYgU291dGggU3QuLCBIb3BraW50b24sIE1BwqAgMDE3NDgNCisxICg1MDgpIDI5My03OTUzwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIEZBWDogKzEgKDUwOCkgMjkzLTc3ODYNCmRhdmlkLmJsYWNr QGVtYy5jb23CoMKgwqDCoMKgwqDCoCBNb2JpbGU6ICsxICg5NzgpIDM5NC03NzU0DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaXBzZWMtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiANCj4gT2YgWWFyb24gU2hlZmZl cg0KPiBTZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMzEsIDIwMTEgMjoyNiBQTQ0KPiBUbzogRGFj aGVuZyBaaGFuZyhEYWNoZW5nKQ0KPiBDYzogaXBzZWNAaWV0Zi5vcmc7IE1lbGluZGEgU2hvcmU7 IFlvYXYgTmlyOyBKYWNrIEtvaG4NCj4gU3ViamVjdDogUmU6IFtJUHNlY10g562U5aSNOiBNb3Zp bmcgQXV0aGVudGljYXRpb24gSGVhZGVyIChBSCkgdG8gSGlzdG9yaWMNCj4gDQo+IEkgYWdyZWUg dGhhdCBwZW9wbGUgc2hvdWxkIHByZWZlciBFU1AtbnVsbCBmb3IgYWxsIG5ldyB1c2VzLg0KPiAN Cj4gSSBzcGVudCBhIGZldyBtaW51dGVzIHRyeWluZyB0byBsb29rIHVwIHRoZSBwcmVjaXNlIGRl ZmluaXRpb24gb2YgDQo+ICJIaXN0b3JpYyBEb2N1bWVudHMiIGluIHRoZSBJRVRGIHN0YW5kYXJk cyBwcm9jZXNzLiBTaW5jZSB0aGUgDQo+IGRlZmluaXRpb24gYXBwZWFycyB0byBiZSBleHRyZW1l bHkgdmFndWUgYW5kIG1heSBub3QgY2xlYXJseSBhcHBseSBpbiANCj4gdGhpcyBjYXNlLCBJIHN0 cm9uZ2x5IHN1Z2dlc3QgdGhhdCB3ZSBhdm9pZCB0aGlzIHJhdGhvbGUgKGFuZCBtb3ZlIHRvIA0K PiB0aGUgbmV4dCBvbmUpLCBieSBhZG9wdGluZyB0aGUgcHJvcG9zZWQgd29yZGluZyBiZWxvdy4g TWFuYXYncyBJLUQgaXMgDQo+IGFuIEluZGVwZW5kZW50IGRvY3VtZW50IGFuZCBzbyBpdHMgY29u dGVudCBpcyBjb21wbGV0ZWx5IHVwIHRvIGl0cyANCj4gYXV0aG9yOyBPVE9ILCBJJ2QgcmF0aGVy IG5vdCB3YXN0ZSB0aGUgZ3JvdXAncyBlbmVyZ3kgb24gDQo+IG5vdC12ZXJ5LWltcG9ydGFudCBw cm9jZXNzIG1hdHRlcnMuIFdoYXQgZG9lcyBtYXR0ZXIgaXMgdGhhdCANCj4gaW1wbGVtZW50ZXJz IGFuZCBzdGFuZGFyZHMgYm9kaWVzIHVuZGVyc3RhbmQgdGhlIHN0cmVuZ3RocyBhbmQgd2Vha25l c3NlcyBvZiBvdXIgcHJvdG9jb2xzLg0KPiANCj4gV2lzaGluZyB1cyBhbGwgYSBIYXBweSBOZXcg WWVhciAyMDEyIQ0KPiANCj4gICAgICBZYXJvbg0KPiANCj4gT24gMTIvMzEvMjAxMSAwNTo1OCBB TSwgRGFjaGVuZyBaaGFuZyhEYWNoZW5nKSB3cm90ZToNCj4gPj4+IElmIGZvbGtzIGRvbnQgd2Fu dCB0byBtb3ZlIEFIIHRvIGhpc3RvcmljIHRoZW4gcGVyaGFwcyB0aGlzIA0KPiA+Pj4gZG9jdW1l bnQgY291bGQgYmUgbW9kaWZpZWQgdG8gc2F5IHNvbWV0aGluZyBpbiB0aGUgbGluZXMgb2YgLSAi QUggDQo+ID4+PiBzaG91bGQgbm90IGJlIHByZWZlcnJlZCB3aGVuIGRlc2lnbmluZyBuZXcgcHJv dG9jb2xzIGFuZCBhbGwgDQo+ID4+PiBhdHRlbXB0cyBtdXN0IGJlIG1hZGUgdG8gdXNlIEVTUC1O VUxMIg0KPiA+IFtEYWNoZW5nIFpoYW5nXQ0KPiA+IFJlYWxseSBsaWtlIHRoaXMgc3VnZ2VzdGlv bi4gKzENCj4gPj4+IEphY2sNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IElQc2VjIG1haWxpbmcgbGlzdA0KPiA+IElQc2VjQGlldGYub3Jn DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSVBzZWMg bWFpbGluZyBsaXN0DQo+IElQc2VjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg== From nico@cryptonector.com Sat Dec 31 18:01:39 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F6A21F84BC for ; Sat, 31 Dec 2011 18:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qi5S-y96asuy for ; Sat, 31 Dec 2011 18:01:38 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 67C2921F84BA for ; Sat, 31 Dec 2011 18:01:38 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 03146674059 for ; Sat, 31 Dec 2011 18:01:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=m7CTKjnGLxeJ9h6B7OWhd9cYuAwjJWB0Uo9KUwXO4SYv moLzWfdliDsj32fkig9Q+WN2cNlHkWrXzAxlP737ozQ+jxPnF0N2wLT7l6lAK548 s5o+wvh6Si6OU6/vav1B6Uurvv62syKXaPnaWiSjvtmD6iwlcNvz0s5RvRNOMJg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=p/Uq44FFXpWNHjN5p8gGXYeuU8k=; b=BNXFebhbPwD UIBSdP+USMn3lhoXHnVuJhyUTMQHEpLrz5sl+hQn0DVpSgjrDpba6tqtSbbs9Duq v4Fah0qq7phN+8/OW3b5SiOCO6iR3yU1x+8KbMmpImFFMnglzhcbjaWUodG0HSoQ 8+bFTjGV9m+NYMdjduEl2xZXvtupF3aM= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id E2E70674058 for ; Sat, 31 Dec 2011 18:01:37 -0800 (PST) Received: by dajz8 with SMTP id z8so14124982daj.31 for ; Sat, 31 Dec 2011 18:01:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.72.73 with SMTP id b9mr82143218pbv.67.1325383297492; Sat, 31 Dec 2011 18:01:37 -0800 (PST) Received: by 10.68.10.234 with HTTP; Sat, 31 Dec 2011 18:01:37 -0800 (PST) In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B26@MX14A.corp.emc.com> References: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.com> <4EFCBE95.8040408@gmail.com> <8521357F-B4E3-4D14-9D1E-996713C2F027@checkpoint.com> <4EFF61B5.2030604@gmail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B26@MX14A.corp.emc.com> Date: Sat, 31 Dec 2011 20:01:37 -0600 Message-ID: From: Nico Williams To: david.black@emc.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 02:01:39 -0000 On Sat, Dec 31, 2011 at 7:29 PM, wrote: > FWIW, the definition of "Historic" is in RFC 2026, and I agree with Yaron= that > it's not exactly precise: > > =C2=A0 A specification that has been superseded by a more recent > =C2=A0 specification or is for any other reason considered to be obsolete= is > =C2=A0 assigned to the "Historic" level. =C2=A0(Purists have suggested th= at the > =C2=A0 word should be "Historical"; however, at this point the use of > =C2=A0 "Historic" is historical.) The question, for me, is: do "Historic", "retired", and "obsolete" refer strictly to the ability of new standards to depend on the old ones, or does it go further to requiring implementors to also obsolete (i.e., declare intention to remove) the feature from their products? Section 6.4 is a bit more specific: As the technology changes and matures, it is possible for a new Standard specification to be so clearly superior technically that one or more existing standards track specifications for the same function should be retired. In this case, or when it is felt for some other reason that an existing standards track specification should be retired, the IESG shall approve a change of status of the old specification(s) to Historic. [...] Elsewhere we have a requirement that normative references of standards-track documents not be to non-stantards-track documents. That helps me interpret RFC2026 as limiting the effect of "Historic" to forbidding the dependence of new standards on old ones. Do we have any reason to imagine that AH will ever be sufficiently more appropriate than ESP for any protocol that we are not yet ready to retire AH? I don't, but maybe I'm not imaginative enough. For the record, and with the above understanding of the meaning of "Historic", I'm firmly in support of the proposal that we move AH to Historic. Nico -- From david.black@emc.com Sat Dec 31 19:06:35 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48B521F84AC for ; Sat, 31 Dec 2011 19:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.582 X-Spam-Level: X-Spam-Status: No, score=-106.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw5jQ65mNFtK for ; Sat, 31 Dec 2011 19:06:35 -0800 (PST) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id AF5FE21F84A9 for ; Sat, 31 Dec 2011 19:06:34 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0136VhU006682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 31 Dec 2011 22:06:31 -0500 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 31 Dec 2011 22:06:13 -0500 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q0136BF2019376; Sat, 31 Dec 2011 22:06:11 -0500 Received: from mx14a.corp.emc.com ([169.254.1.216]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Sat, 31 Dec 2011 22:06:11 -0500 From: To: Date: Sat, 31 Dec 2011 22:06:10 -0500 Thread-Topic: Moving Authentication Header (AH) to Historic Thread-Index: AczH8heAaINAR3eDS6aYauHUusiYOAAMDvMgAAEStYAAAuyC4g== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5D81F2F@MX14A.corp.emc.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D027BB264@INBANSXCHMBSA1.in.alcatel-lucent.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: ipsec@ietf.org Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 03:06:36 -0000 SGkgTWFuYXYsDQoNCkkgdGhpbmsgaXQncyBtb3JlIGltcG9ydGFudCB0byBjbGVhcmx5IHN0YXRl IHdoYXQgd2Ugd2FudCBwcm90b2NvbCBkZXNpZ25lcnMgdG8gZG8vbm90IGRvIGFuZCB3aHkgKGRp dHRvIGZvciBJUHNlYyBpbXBsZW1lbnRlcnMpLiAgV2UgY2FuIGZpZ3VyZSBvdXQgdGhlIHByb2Nl c3Mgc3R1ZmYgbGF0ZXIuICBJIGRlZmluaXRlbHkgdGhpbmsgdGhhdCBpdCdzIHdvcnRoIHNwZW5k aW5nIHRpbWUgb24gZHJhZnRpbmcgZ3VpZGFuY2UgYWJvdXQgd2hlbiAoaWYgZXZlcikgdXNlIG9m IEFIIGluIG5ldyBwcm90b2NvbHMgaXMgYXBwcm9wcmlhdGUuDQoNClRoYW5rcywgLS1EYXZpZCAr KysgU2VudCBmcm9tIEJsYWNrQmVycnkgKysrDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0t LS0NCkZyb206IEJoYXRpYSwgTWFuYXYgKE1hbmF2KSBbbWFpbHRvOm1hbmF2LmJoYXRpYUBhbGNh dGVsLWx1Y2VudC5jb21dDQpTZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMzEsIDIwMTEgMDg6NTMg UE0KVG86IEJsYWNrLCBEYXZpZDsgeWFyb25mLmlldGZAZ21haWwuY29tIDx5YXJvbmYuaWV0ZkBn bWFpbC5jb20+DQpDYzogaXBzZWNAaWV0Zi5vcmcgPGlwc2VjQGlldGYub3JnPg0KU3ViamVjdDog UkU6IE1vdmluZyBBdXRoZW50aWNhdGlvbiBIZWFkZXIgKEFIKSB0byBIaXN0b3JpYw0KDQpIaSBE YXZpZCBhbmQgWWFyb24sDQoNCkkgdGhpbmsgaXRzIHBvc3NpYmxlIHRvIGVkaXQgdGhlIGRyYWZ0 IGhlYWRlcnMgYW5kIHRoZSB0ZXh0IHNvIHRoYXQgd2UgYmFzaWNhbGx5IHNheSB0aGF0IEFIIHNo b3VsZCBOT1QgYmUgdXNlZCBmb3IgbmV3ZXIgcHJvcG9zYWxzIHVubGVzcyB0aGVyZSBpcyBhIGJ1 cm5pbmcgcmVhc29uIHRvIGRvIHNvLiBBbmQgaWYgc29tZW9uZSB3YW50cyB0byB1c2UgQUgsIHRo ZW4gdGhleSBzaG91bGQgaGF2ZSBhIHByZXR0eSBnb29kIHJlYXNvbiBmb3IgZG9pbmcgdGhhdC4g SW4gbXkgZHJhZnQgSSBjbGVhcmx5IHNheSB0aGF0IEFIIGRvZXMgYSBnb29kIGpvYiB3aXRoIHdo YXRzIGl0cyBzdXBwb3NlZCB0byBkbyAtIGludGVncml0eSB2ZXJpZmljYXRpb24uIEhvd2V2ZXIs IEVTUC1OVUxMIGRvZXMgdGhhdCBlcXVhbGx5IGdvb2QgYW5kIHRoZXJlIGlzIG5vIGdvb2QgcmVh c29uIHRvIHVzZSBBSCBhbnkgbW9yZS4gSSB3cm90ZSB0aGlzIGRyYWZ0IGJlY2F1c2UgSSB3YXMg aGF2aW5nIGEgcHJpdmF0ZSBkaXNjdXNzaW9uIG9uIFBJTSBzZWN1cml0eSB3aXRoIGEgZmV3IGZv bGtzIGFuZCB0aGUgZGlzY3Vzc2lvbiBzdGFydGVkIHZlZXJpbmcgdG93YXJkcyAiSGV5IGxldHMg dXNlIEFIIHNpbmNlIHdlIHdhbnQgdG8gc25vb3AgY2VydGFpbiBQSU0gcGFja2V0cyBhbmQgRVNQ LU5VTEwgd291bGRu4oCZdCBsZXQgdXMgZG8gdGhhdCIuIA0KDQpTbywgd2hpbGUgcGVvcGxlIHdv cmtpbmcgb24gc2VjdXJpdHkgdW5kZXJzdGFuZCB0aGF0IEFIIHNob3VsZCBub3QgYmUgdXNlZCBm b3IgbmV3ZXIgcHJvdG9jb2xzLCB0aGVyZSBhcmUgbG90cyBvZiBvdGhlcnMgd2hvIGRvbuKAmXQu DQoNCkkganVzdCB3YW50ZWQgdGhhdCB0byBiZSBwb2ludGVkIG91dCBleHBsaWNpdGx5LiANCg0K SSBkb27igJl0IHJlYWxseSBjYXJlIHdoZXRoZXIgaXRzIHRocm91Z2ggYW4gaW5mb3JtYXRpb25h bCBSRkMsIEJDUCwgc3RhbmRhcmRzIHRyYWNrIG9yIHNvbWUgb3RoZXIgdHlwZSBhcyBsb25nIGFz IHRoZSBtZXNzYWdlIGlzIG91dCBsb3VkIGFuZCBjbGVhci4gSG93ZXZlciwgYmVmb3JlIHNwZW5k aW5nIGFueSBtb3JlIGN5Y2xlcyBvbiBpdCBJIHdvdWxkIGZpcnN0IGxpa2UgdG8gZ2F1Z2UgdGhl IGludGVyZXN0IGxldmVsIGluIHRoZSBXRyB0byBzZWUgaWYgcGVvcGxlIHRoaW5rIGl04oCZcyBh biBpZGVhIHdvcnRoIHNwZW5kaW5nIHRpbWUgb24uIEFuZCBpZiBub3QsIHRoZW4gd2h5Lg0KDQpD aGVlcnMsIE1hbmF2DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpcHNlYy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86aXBzZWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIGRhdmlkLmJsYWNrQGVtYy5jb20NClNlbnQ6IFN1bmRheSwgSmFudWFyeSAwMSwgMjAxMiA2 OjU5IEFNDQpUbzogeWFyb25mLmlldGZAZ21haWwuY29tDQpDYzogaXBzZWNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbSVBzZWNdIE1vdmluZyBBdXRoZW50aWNhdGlvbiBIZWFkZXIgKEFIKSB0byBI aXN0b3JpYw0KDQo+IEkgc3BlbnQgYSBmZXcgbWludXRlcyB0cnlpbmcgdG8gbG9vayB1cCB0aGUg cHJlY2lzZSBkZWZpbml0aW9uIG9mIA0KPiAiSGlzdG9yaWMgRG9jdW1lbnRzIiBpbiB0aGUgSUVU RiBzdGFuZGFyZHMgcHJvY2Vzcy4gU2luY2UgdGhlIA0KPiBkZWZpbml0aW9uIGFwcGVhcnMgdG8g YmUgZXh0cmVtZWx5IHZhZ3VlIGFuZCBtYXkgbm90IGNsZWFybHkgYXBwbHkgaW4gDQo+IHRoaXMg Y2FzZSwNCg0KRldJVywgdGhlIGRlZmluaXRpb24gb2YgIkhpc3RvcmljIiBpcyBpbiBSRkMgMjAy NiwgYW5kIEkgYWdyZWUgd2l0aCBZYXJvbiB0aGF0IGl0J3Mgbm90IGV4YWN0bHkgcHJlY2lzZToN Cg0KICAgQSBzcGVjaWZpY2F0aW9uIHRoYXQgaGFzIGJlZW4gc3VwZXJzZWRlZCBieSBhIG1vcmUg cmVjZW50DQogICBzcGVjaWZpY2F0aW9uIG9yIGlzIGZvciBhbnkgb3RoZXIgcmVhc29uIGNvbnNp ZGVyZWQgdG8gYmUgb2Jzb2xldGUgaXMNCiAgIGFzc2lnbmVkIHRvIHRoZSAiSGlzdG9yaWMiIGxl dmVsLiAgKFB1cmlzdHMgaGF2ZSBzdWdnZXN0ZWQgdGhhdCB0aGUNCiAgIHdvcmQgc2hvdWxkIGJl ICJIaXN0b3JpY2FsIjsgaG93ZXZlciwgYXQgdGhpcyBwb2ludCB0aGUgdXNlIG9mDQogICAiSGlz dG9yaWMiIGlzIGhpc3RvcmljYWwuKQ0KDQpUaGVyZSBpcyBhIHN1YnRsZSBkaXN0aW5jdGlvbiBi ZXR3ZWVuIE9ic29sZXRlIGFuZCBIaXN0b3JpYyAtIGFuIEhpc3RvcmljIFJGQyBpcyBhbHdheXMg T2Jzb2xldGUsIGJ1dCBhbiBPYnNvbGV0ZSBSRkMgbWF5IG5vdCBiZSBIaXN0b3JpYy4gIEJlZm9y ZSBnb2luZyBhbnkgZnVydGhlciwgIGxldCBtZSBzYXkgdGhhdCBJIHN0cm9uZ2x5IGFncmVlIHdp dGggWWFyb24gb24gcHJpb3JpdGllczoNCg0KPiBJIHN0cm9uZ2x5IHN1Z2dlc3QgdGhhdCB3ZSBh dm9pZCB0aGlzIHJhdGhvbGUgKGFuZCBtb3ZlIHRvIHRoZSBuZXh0IA0KPiBvbmUpLCBieSBhZG9w dGluZyB0aGUgcHJvcG9zZWQgd29yZGluZyBiZWxvdy4gTWFuYXYncyBJLUQgaXMgYW4gDQo+IElu ZGVwZW5kZW50IGRvY3VtZW50IGFuZCBzbyBpdHMgY29udGVudCBpcyBjb21wbGV0ZWx5IHVwIHRv IGl0cyANCj4gYXV0aG9yOyBPVE9ILCBJJ2QgcmF0aGVyIG5vdCB3YXN0ZSB0aGUgZ3JvdXAncyBl bmVyZ3kgb24gDQo+IG5vdC12ZXJ5LWltcG9ydGFudCBwcm9jZXNzIG1hdHRlcnMuIFdoYXQgZG9l cyBtYXR0ZXIgaXMgdGhhdCANCj4gaW1wbGVtZW50ZXJzIGFuZCBzdGFuZGFyZHMgYm9kaWVzIHVu ZGVyc3RhbmQgdGhlIHN0cmVuZ3RocyBhbmQgd2Vha25lc3NlcyBvZiBvdXIgcHJvdG9jb2xzLg0K DQpJbiBvcmRlciB0byBvYnNvbGV0ZSBBSCwgdGhlIGRyYWZ0IGhlYWRlciBuZWVkcyB0byBzYXkg Ik9ic29sZXRlczogNDMwMiIsIGluIGFkZGl0aW9uIHRvIGl0cyBkaXNjdXNzaW9uIG9mIG1ha2lu ZyBSRkMgNDMwMiBIaXN0b3JpYy4gIEJvdGggb2YgdGhlIGZvcmVnb2luZyByZXF1aXJlIHRoYXQg dGhlIGRyYWZ0IG5vdCBiZSBJbmZvcm1hdGlvbmFsOyBJJ2QgZ28gZnVydGhlciBhbmQgc3VnZ2Vz dCB0aGF0IHdpdGggc3VpdGFibGUgZWRpdGluZyBhbmQgcmV2aWV3LCB0aGlzIGNvdWxkIGJlIGEg QmVzdCBDdXJyZW50IFByYWN0aWNlIChCQ1ApIFJGQywgYXMgdGhlIHByaW1hcnkgZ29hbCBpcyB0 byBkb2N1bWVudCB0aGUgZm9sbG93aW5nIGFzIGN1cnJlbnQgZGVzaWduIHByYWN0aWNlOg0KDQo+ ID4gIkFIIHNob3VsZCBub3QgYmUNCj4gPiBwcmVmZXJyZWQgd2hlbiBkZXNpZ25pbmcgbmV3IHBy b3RvY29scyBhbmQgYWxsIGF0dGVtcHRzIG11c3QgYmUgbWFkZSANCj4gPiB0byB1c2UgRVNQLU5V TEwiDQoNCkkgYmVsaWV2ZSB0aGF0IGEgQkNQIGNhbiBiZSB1c2VkIHRvIGNhdXNlIGEgc3RhbmRh cmRzIHRyYWNrIFJGQyB0byBiZWNvbWUgb2Jzb2xldGUuDQoNClRoYW5rcywNCi0tRGF2aWQNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRhdmlk IEwuIEJsYWNrLCBEaXN0aW5ndWlzaGVkIEVuZ2luZWVyDQpFTUMgQ29ycG9yYXRpb24sIDE3NiBT b3V0aCBTdC4sIEhvcGtpbnRvbiwgTUHCoCAwMTc0OA0KKzEgKDUwOCkgMjkzLTc5NTPCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgRkFYOiArMSAoNTA4KSAyOTMtNzc4Ng0KZGF2aWQuYmxhY2tAZW1j LmNvbcKgwqDCoMKgwqDCoMKgIE1vYmlsZTogKzEgKDk3OCkgMzk0LTc3NTQNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHNlYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 aXBzZWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIA0KPiBPZiBZYXJvbiBTaGVmZmVyDQo+ IFNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAzMSwgMjAxMSAyOjI2IFBNDQo+IFRvOiBEYWNoZW5n IFpoYW5nKERhY2hlbmcpDQo+IENjOiBpcHNlY0BpZXRmLm9yZzsgTWVsaW5kYSBTaG9yZTsgWW9h diBOaXI7IEphY2sgS29obg0KPiBTdWJqZWN0OiBSZTogW0lQc2VjXSDnrZTlpI06IE1vdmluZyBB dXRoZW50aWNhdGlvbiBIZWFkZXIgKEFIKSB0byBIaXN0b3JpYw0KPiANCj4gSSBhZ3JlZSB0aGF0 IHBlb3BsZSBzaG91bGQgcHJlZmVyIEVTUC1udWxsIGZvciBhbGwgbmV3IHVzZXMuDQo+IA0KPiBJ IHNwZW50IGEgZmV3IG1pbnV0ZXMgdHJ5aW5nIHRvIGxvb2sgdXAgdGhlIHByZWNpc2UgZGVmaW5p dGlvbiBvZiANCj4gIkhpc3RvcmljIERvY3VtZW50cyIgaW4gdGhlIElFVEYgc3RhbmRhcmRzIHBy b2Nlc3MuIFNpbmNlIHRoZSANCj4gZGVmaW5pdGlvbiBhcHBlYXJzIHRvIGJlIGV4dHJlbWVseSB2 YWd1ZSBhbmQgbWF5IG5vdCBjbGVhcmx5IGFwcGx5IGluIA0KPiB0aGlzIGNhc2UsIEkgc3Ryb25n bHkgc3VnZ2VzdCB0aGF0IHdlIGF2b2lkIHRoaXMgcmF0aG9sZSAoYW5kIG1vdmUgdG8gDQo+IHRo ZSBuZXh0IG9uZSksIGJ5IGFkb3B0aW5nIHRoZSBwcm9wb3NlZCB3b3JkaW5nIGJlbG93LiBNYW5h didzIEktRCBpcyANCj4gYW4gSW5kZXBlbmRlbnQgZG9jdW1lbnQgYW5kIHNvIGl0cyBjb250ZW50 IGlzIGNvbXBsZXRlbHkgdXAgdG8gaXRzIA0KPiBhdXRob3I7IE9UT0gsIEknZCByYXRoZXIgbm90 IHdhc3RlIHRoZSBncm91cCdzIGVuZXJneSBvbiANCj4gbm90LXZlcnktaW1wb3J0YW50IHByb2Nl c3MgbWF0dGVycy4gV2hhdCBkb2VzIG1hdHRlciBpcyB0aGF0IA0KPiBpbXBsZW1lbnRlcnMgYW5k IHN0YW5kYXJkcyBib2RpZXMgdW5kZXJzdGFuZCB0aGUgc3RyZW5ndGhzIGFuZCB3ZWFrbmVzc2Vz IG9mIG91ciBwcm90b2NvbHMuDQo+IA0KPiBXaXNoaW5nIHVzIGFsbCBhIEhhcHB5IE5ldyBZZWFy IDIwMTIhDQo+IA0KPiAgICAgIFlhcm9uDQo+IA0KPiBPbiAxMi8zMS8yMDExIDA1OjU4IEFNLCBE YWNoZW5nIFpoYW5nKERhY2hlbmcpIHdyb3RlOg0KPiA+Pj4gSWYgZm9sa3MgZG9udCB3YW50IHRv IG1vdmUgQUggdG8gaGlzdG9yaWMgdGhlbiBwZXJoYXBzIHRoaXMgDQo+ID4+PiBkb2N1bWVudCBj b3VsZCBiZSBtb2RpZmllZCB0byBzYXkgc29tZXRoaW5nIGluIHRoZSBsaW5lcyBvZiAtICJBSCAN Cj4gPj4+IHNob3VsZCBub3QgYmUgcHJlZmVycmVkIHdoZW4gZGVzaWduaW5nIG5ldyBwcm90b2Nv bHMgYW5kIGFsbCANCj4gPj4+IGF0dGVtcHRzIG11c3QgYmUgbWFkZSB0byB1c2UgRVNQLU5VTEwi DQo+ID4gW0RhY2hlbmcgWmhhbmddDQo+ID4gUmVhbGx5IGxpa2UgdGhpcyBzdWdnZXN0aW9uLiAr MQ0KPiA+Pj4gSmFjaw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gSVBzZWMgbWFpbGluZyBsaXN0DQo+ID4gSVBzZWNAaWV0Zi5vcmcNCj4g PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwc2VjDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJUHNlYyBtYWls aW5nIGxpc3QNCj4gSVBzZWNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9pcHNlYw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KSVBzZWMgbWFpbGluZyBsaXN0DQpJUHNlY0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0K From vnktshsriram@gmail.com Sat Dec 31 19:41:31 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5077521F84C3 for ; Sat, 31 Dec 2011 19:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl9-8ssbO5oI for ; Sat, 31 Dec 2011 19:41:30 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA1921F84BA for ; Sat, 31 Dec 2011 19:41:30 -0800 (PST) Received: by yhjj72 with SMTP id j72so10040259yhj.31 for ; Sat, 31 Dec 2011 19:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eX1TPp9fUxNnTvLt1VwaPdXYj8XhEu5tV/HlhNpxsB4=; b=sJMm9eh3FS6ZL3g8nIzGKYadPNyD62+QDoXtvFhtAfRuKUKFLYbrwUmxCjxpNQELaH dhgjniRbs1T80XGk3zvY7+pYGJ7ozb+FWfwGTxcNw8kWxvLfTpPSSTDXSbAzdQWDc0Yn 66b5+9aKbYXd7TFe6F5+zsG//amdtqP5oGfQ4= MIME-Version: 1.0 Received: by 10.236.127.144 with SMTP id d16mr60148100yhi.51.1325389289905; Sat, 31 Dec 2011 19:41:29 -0800 (PST) Received: by 10.236.183.228 with HTTP; Sat, 31 Dec 2011 19:41:29 -0800 (PST) In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5D81F2F@MX14A.corp.emc.com> References: <7C362EEF9C7896468B36C9B79200D8350D027BB264@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5D81F2F@MX14A.corp.emc.com> Date: Sun, 1 Jan 2012 09:11:29 +0530 Message-ID: From: Venkatesh Sriram To: david.black@emc.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, manav.bhatia@alcatel-lucent.com Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 03:41:31 -0000 I think this draft pretty much does the same. It says why AH should not be used. For most cases, this should work. However, if there are protocols that for some reason need AH then they should justify its use. I think the intent is captured here in this paragraph: Moving AH to historic doesn't mean that people have to stop using AH right now. It only means that in the opinion of the community there are now better alternatives. Moving AH to historic will discourage new protocols to mandate the use of AH. It however, does not preclude the possibility of new work to IETF that will require or enhance AH. It just means that the authors will have to explain why that solution is really needed and why ESP-NULL cant be used instead. I strongly agree with David, Manav and Nico that we must not worry about the process stuff here. Once we have an understanding of how this needs to be done, taking care of the process stuff should be easy. Sriram On Sun, Jan 1, 2012 at 8:36 AM, wrote: > Hi Manav, > > I think it's more important to clearly state what we want protocol design= ers to do/not do and why (ditto for IPsec implementers). =C2=A0We can figur= e out the process stuff later. =C2=A0I definitely think that it's worth spe= nding time on drafting guidance about when (if ever) use of AH in new proto= cols is appropriate. > > Thanks, --David +++ Sent from BlackBerry +++ > > ----- Original Message ----- > From: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] > Sent: Saturday, December 31, 2011 08:53 PM > To: Black, David; yaronf.ietf@gmail.com > Cc: ipsec@ietf.org > Subject: RE: Moving Authentication Header (AH) to Historic > > Hi David and Yaron, > > I think its possible to edit the draft headers and the text so that we ba= sically say that AH should NOT be used for newer proposals unless there is = a burning reason to do so. And if someone wants to use AH, then they should= have a pretty good reason for doing that. In my draft I clearly say that A= H does a good job with whats its supposed to do - integrity verification. H= owever, ESP-NULL does that equally good and there is no good reason to use = AH any more. I wrote this draft because I was having a private discussion o= n PIM security with a few folks and the discussion started veering towards = "Hey lets use AH since we want to snoop certain PIM packets and ESP-NULL wo= uldn=E2=80=99t let us do that". > > So, while people working on security understand that AH should not be use= d for newer protocols, there are lots of others who don=E2=80=99t. > > I just wanted that to be pointed out explicitly. > > I don=E2=80=99t really care whether its through an informational RFC, BCP= , standards track or some other type as long as the message is out loud and= clear. However, before spending any more cycles on it I would first like t= o gauge the interest level in the WG to see if people think it=E2=80=99s an= idea worth spending time on. And if not, then why. > > Cheers, Manav > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of= david.black@emc.com > Sent: Sunday, January 01, 2012 6:59 AM > To: yaronf.ietf@gmail.com > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic > >> I spent a few minutes trying to look up the precise definition of >> "Historic Documents" in the IETF standards process. Since the >> definition appears to be extremely vague and may not clearly apply in >> this case, > > FWIW, the definition of "Historic" is in RFC 2026, and I agree with Yaron= that it's not exactly precise: > > =C2=A0 A specification that has been superseded by a more recent > =C2=A0 specification or is for any other reason considered to be obsolete= is > =C2=A0 assigned to the "Historic" level. =C2=A0(Purists have suggested th= at the > =C2=A0 word should be "Historical"; however, at this point the use of > =C2=A0 "Historic" is historical.) > > There is a subtle distinction between Obsolete and Historic - an Historic= RFC is always Obsolete, but an Obsolete RFC may not be Historic. =C2=A0Bef= ore going any further, =C2=A0let me say that I strongly agree with Yaron on= priorities: > >> I strongly suggest that we avoid this rathole (and move to the next >> one), by adopting the proposed wording below. Manav's I-D is an >> Independent document and so its content is completely up to its >> author; OTOH, I'd rather not waste the group's energy on >> not-very-important process matters. What does matter is that >> implementers and standards bodies understand the strengths and weaknesse= s of our protocols. > > In order to obsolete AH, the draft header needs to say "Obsoletes: 4302",= in addition to its discussion of making RFC 4302 Historic. =C2=A0Both of t= he foregoing require that the draft not be Informational; I'd go further an= d suggest that with suitable editing and review, this could be a Best Curre= nt Practice (BCP) RFC, as the primary goal is to document the following as = current design practice: > >> > "AH should not be >> > preferred when designing new protocols and all attempts must be made >> > to use ESP-NULL" > > I believe that a BCP can be used to cause a standards track RFC to become= obsolete. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=C2=A0 01748 > +1 (508) 293-7953=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 FAX: +1 (508) 293-7786 > david.black@emc.com=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mobile: +1 = (978) 394-7754 > ---------------------------------------------------- > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Yaron Sheffer >> Sent: Saturday, December 31, 2011 2:26 PM >> To: Dacheng Zhang(Dacheng) >> Cc: ipsec@ietf.org; Melinda Shore; Yoav Nir; Jack Kohn >> Subject: Re: [IPsec] =E7=AD=94=E5=A4=8D: Moving Authentication Header (A= H) to Historic >> >> I agree that people should prefer ESP-null for all new uses. >> >> I spent a few minutes trying to look up the precise definition of >> "Historic Documents" in the IETF standards process. Since the >> definition appears to be extremely vague and may not clearly apply in >> this case, I strongly suggest that we avoid this rathole (and move to >> the next one), by adopting the proposed wording below. Manav's I-D is >> an Independent document and so its content is completely up to its >> author; OTOH, I'd rather not waste the group's energy on >> not-very-important process matters. What does matter is that >> implementers and standards bodies understand the strengths and weaknesse= s of our protocols. >> >> Wishing us all a Happy New Year 2012! >> >> =C2=A0 =C2=A0 =C2=A0Yaron >> >> On 12/31/2011 05:58 AM, Dacheng Zhang(Dacheng) wrote: >> >>> If folks dont want to move AH to historic then perhaps this >> >>> document could be modified to say something in the lines of - "AH >> >>> should not be preferred when designing new protocols and all >> >>> attempts must be made to use ESP-NULL" >> > [Dacheng Zhang] >> > Really like this suggestion. +1 >> >>> Jack >> > _______________________________________________ >> > IPsec mailing list >> > IPsec@ietf.org >> > https://www.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec