From paul.hoffman@vpnc.org Sun Jan 1 07:55:25 2012 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 52FCC21F953A for ; Sun, 1 Jan 2012 07:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 apfmJaDAC9vk for ; Sun, 1 Jan 2012 07:55:24 -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 CE95721F9538 for ; Sun, 1 Jan 2012 07:55:24 -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 q01FtK3v082238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Jan 2012 08:55:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B26@MX14A.corp.emc.com> Date: Sun, 1 Jan 2012 07:55:22 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6E38F4E9-8335-43F9-BA7A-9BB1E209E987@vpnc.org> 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> To: "" X-Mailer: Apple Mail (2.1251.1) Cc: IPsecme WG 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 15:55:25 -0000 On Dec 31, 2011, at 5:29 PM, = wrote: > FWIW, the definition of "Historic" is in RFC 2026, That is *a* definition of "Historic", but it has been modified = informally since RFC 2026 has been written. The IESG is quite aware of = this problem and has steadfastly refused to update 2026 to bring it up = to the current understanding of "Historic". Doing so would open many = large cans of worms. Proposal: ignore the "historic" label altogether and simply go to = "should not be used in new applications and protocols". That way, you = can word it as strongly as you want. Such a document can be a BCP, which = has the same effect as a standard. --Paul Hoffman From manav.bhatia@alcatel-lucent.com Sun Jan 1 08:17:18 2012 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 D0A8B11E808A for ; Sun, 1 Jan 2012 08:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 5e2c2vwtW7Iy for ; Sun, 1 Jan 2012 08:17:18 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 49AB711E8089 for ; Sun, 1 Jan 2012 08:17:18 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q01GHCgK006973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 1 Jan 2012 10:17:15 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q01GH6ge028679 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 1 Jan 2012 21:47:11 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Sun, 1 Jan 2012 21:47:06 +0530 From: "Bhatia, Manav (Manav)" To: Paul Hoffman , "" Date: Sun, 1 Jan 2012 21:47:06 +0530 Thread-Topic: [IPsec] Moving Authentication Header (AH) to Historic Thread-Index: AczIncqyRHq8o0XdRO6b4jPpfafuYAAAmKOQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350D027BB274@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> <6E38F4E9-8335-43F9-BA7A-9BB1E209E987@vpnc.org> In-Reply-To: <6E38F4E9-8335-43F9-BA7A-9BB1E209E987@vpnc.org> 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.37 Cc: IPsecme WG 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 16:17:18 -0000 Hi Paul, To get around this process problem do you suggest that I publish a new draf= t - "Avoiding Authentication Header (AH)" that's mostly a copy-paste of my = current draft? Cheers, Manav -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Sunday, January 01, 2012 9:25 PM To: Cc: IPsecme WG Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic On Dec 31, 2011, at 5:29 PM, wr= ote: > FWIW, the definition of "Historic" is in RFC 2026, That is *a* definition of "Historic", but it has been modified informally s= ince RFC 2026 has been written. The IESG is quite aware of this problem and= has steadfastly refused to update 2026 to bring it up to the current under= standing of "Historic". Doing so would open many large cans of worms. Proposal: ignore the "historic" label altogether and simply go to "should n= ot be used in new applications and protocols". That way, you can word it as= strongly as you want. Such a document can be a BCP, which has the same eff= ect as a standard. --Paul Hoffman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Sun Jan 1 08:33:25 2012 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 D75D011E8097 for ; Sun, 1 Jan 2012 08:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 QRYswEk0SIID for ; Sun, 1 Jan 2012 08:33:25 -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 5914C11E8073 for ; Sun, 1 Jan 2012 08:33:25 -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 q01GXK62084453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 1 Jan 2012 09:33:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D027BB274@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Sun, 1 Jan 2012 08:33:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <24EFE65B-86E0-4473-AF48-98B0C50F7041@vpnc.org> 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> <6E38F4E9-8335-43F9-BA7A-9BB1E209E987@vpnc.org> <7C362EEF9C7896468B36C9B79200D8350D027BB274@INBANSXCHMBSA1.in.alcatel-lucent.com> To: "Bhatia, Manav (Manav)" X-Mailer: Apple Mail (2.1251.1) Cc: IPsecme WG , "" 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 16:33:25 -0000 On Jan 1, 2012, at 8:17 AM, Bhatia, Manav (Manav) wrote: > To get around this process problem do you suggest that I publish a new = draft - "Avoiding Authentication Header (AH)" that's mostly a copy-paste = of my current draft? Yep, that would work. It would also cut off the chin-scratching about = "what does Historic really mean" and let us focus on what you actually = want, which is people not using AH. --Paul Hoffman From manav.bhatia@alcatel-lucent.com Sun Jan 1 15:51:11 2012 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 D529E21F8CCC for ; Sun, 1 Jan 2012 15:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 qYVfXJcEc1-g for ; Sun, 1 Jan 2012 15:51:11 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3804921F8CCB for ; Sun, 1 Jan 2012 15:51:10 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q01Np6KA024854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 1 Jan 2012 17:51:09 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q01Np4hH015799 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jan 2012 05:21:05 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Mon, 2 Jan 2012 05:21:04 +0530 From: "Bhatia, Manav (Manav)" To: Paul Hoffman Date: Mon, 2 Jan 2012 05:21:04 +0530 Thread-Topic: Avoiding Authentication Header (AH) (was Moving Authentication Header (AH) to Historic) Thread-Index: AczIoxWYmfaGMNY5TzyGbU55fXGYRAAO6J6w Message-ID: <7C362EEF9C7896468B36C9B79200D8350D027BB27B@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> <6E38F4E9-8335-43F9-BA7A-9BB1E209E987@vpnc.org> <7C362EEF9C7896468B36C9B79200D8350D027BB274@INBANSXCHMBSA1.in.alcatel-lucent.com> <24EFE65B-86E0-4473-AF48-98B0C50F7041@vpnc.org> In-Reply-To: <24EFE65B-86E0-4473-AF48-98B0C50F7041@vpnc.org> 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.37 Cc: IPsecme WG , "" Subject: [IPsec] Avoiding Authentication Header (AH) (was 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 23:51:11 -0000 Hi, I have posted a new draft "Avoiding Authentication Header (AH)" http://www.ietf.org/id/draft-bhatia-ipsecme-avoiding-ah-00.txt=20 Hopefully this will help us focus on the technical, rather than the process= related contents in the draft. The message remains the same, which is that we should NOT use AH for any ne= wer applications and protocols since ESP with NULL encryption algorithm is = a better alternative. Looking forward to hearing from the WG. Cheers, Manav -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 Sent: Sunday, January 01, 2012 10:03 PM To: Bhatia, Manav (Manav) Cc: ; IPsecme WG Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic On Jan 1, 2012, at 8:17 AM, Bhatia, Manav (Manav) wrote: > To get around this process problem do you suggest that I publish a new dr= aft - "Avoiding Authentication Header (AH)" that's mostly a copy-paste of m= y current draft? Yep, that would work. It would also cut off the chin-scratching about "what= does Historic really mean" and let us focus on what you actually want, whi= ch is people not using AH. --Paul Hoffman From mcr@sandelman.ca Sun Jan 1 16:11:20 2012 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 7C20E21F8D5B for ; Sun, 1 Jan 2012 16:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.46 X-Spam-Level: X-Spam-Status: No, score=0.46 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 sO1jwSPqX6ju for ; Sun, 1 Jan 2012 16:11:20 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0920821F8D5A for ; Sun, 1 Jan 2012 16:11:18 -0800 (PST) Received: from marajade.sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id 0A51334449 for ; Sun, 1 Jan 2012 19:09:24 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 7026A98147; Sun, 1 Jan 2012 19:11:14 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 66B369812A for ; Sun, 1 Jan 2012 19:11:14 -0500 (EST) From: Michael Richardson To: IPsecme WG In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D027BB27B@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> <6E38F4E9-8335-43F9-BA7A-9BB1E209E987@vpnc.org> <7C362EEF9C7896468B36C9B79200D8350D027BB274@INBANSXCHMBSA1.in.alcatel-lucent.com> <24EFE65B-86E0-4473-AF48-98B0C50F7041@vpnc.org> <7C362EEF9C7896468B36C9B79200D8350D027BB27B@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Sun, 01 Jan 2012 19:11:14 -0500 Message-ID: <20536.1325463074@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] Avoiding Authentication Header (AH) (was 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: Mon, 02 Jan 2012 00:11:20 -0000 >>>>> "Manav" == Manav Bhatia writes: Manav> Hopefully this will help us focus on the technical, rather Manav> than the process related contents in the draft. Manav> The message remains the same, which is that we should NOT use Manav> AH for any newer applications and protocols since ESP with Manav> NULL encryption algorithm is a better alternative. Manav> Looking forward to hearing from the WG. okay, I've read the draft, but your blanket statement that it is never justified it wrong. Your draft might ring truer if you limited your analysis to IPv4 only. I've maintained for a long time that we will need AH functionality in the future, but we haven't gotten there yet. SEND almost used it, and the reason why we didn't, was because we had wrongly specified what to do when we see an AH SPI# a host did not understand. This was sad. I do not agree that WESP provides the service desired. WESP requires cooperation (and therefore upgrade) of the end points. What AH does that ESP NULL does not, is that it guarantees that the things after the AH header are in fact in the clear. One can in fact, ignore the AH header completely (even on the receiving node!), and still process the entire packet. Not so with ESP! AH is just another extension header in IPv6. This property is simply undesireable for many security systems, including all VPNs. Having said all of this, I agree that for 99% of "Use IPsec" statements, ESP-NULL is likely the correct choice. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From manav.bhatia@alcatel-lucent.com Sun Jan 1 17:45:07 2012 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 9649311E8096 for ; Sun, 1 Jan 2012 17:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 cgCaquNn6IrQ for ; Sun, 1 Jan 2012 17:45:07 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 91FAB11E808C for ; Sun, 1 Jan 2012 17:45:02 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q021iwcq022411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 1 Jan 2012 19:45:01 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q021ivwW018305 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jan 2012 07:14:57 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Mon, 2 Jan 2012 07:14:57 +0530 From: "Bhatia, Manav (Manav)" To: Michael Richardson , IPsecme WG Date: Mon, 2 Jan 2012 07:14:58 +0530 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) (was Moving Authentication Header (AH) to Historic) Thread-Index: AczI4xMatJFKFbHGQRe9i6xoeGZt+QADIObw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D027BB27C@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> <6E38F4E9-8335-43F9-BA7A-9BB1E209E987@vpnc.org> <7C362EEF9C7896468B36C9B79200D8350D027BB274@INBANSXCHMBSA1.in.alcatel-lucent.com> <24EFE65B-86E0-4473-AF48-98B0C50F7041@vpnc.org> <7C362EEF9C7896468B36C9B79200D8350D027BB27B@INBANSXCHMBSA1.in.alcatel-lucent.com> <20536.1325463074@marajade.sandelman.ca> In-Reply-To: <20536.1325463074@marajade.sandelman.ca> 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.35 Subject: Re: [IPsec] Avoiding Authentication Header (AH) (was 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: Mon, 02 Jan 2012 01:45:07 -0000 Hi Michael, > I do not agree that WESP provides the service desired.=20 > WESP requires cooperation (and therefore upgrade) of the end points. >=20 > What AH does that ESP NULL does not, is that it guarantees that the thing= s after the AH header are in fact in the clear. One can in fact, ignore th= e AH > header completely (even on the receiving node!), and still process t= he entire packet. Not so with ESP! =20 You have this information with WESP as well. You definitely know that the p= acket is sent in clear with WESP. Just as you can use ESP with manual keyin= g, you can use WESP too. Obviously the end nodes need to implement WESP, but then they also need to = implement AH if that's what they want to use. Cheers, Manav= From ynir@checkpoint.com Sun Jan 1 23:31:11 2012 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 8282021F8EC2 for ; Sun, 1 Jan 2012 23:31:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 th6j0AaASs-C for ; Sun, 1 Jan 2012 23:31:11 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 10D9121F84DD for ; Sun, 1 Jan 2012 23:31:09 -0800 (PST) X-CheckPoint: {4F015B18-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 q027V7FL020939; Mon, 2 Jan 2012 09:31:07 +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, 2 Jan 2012 09:31:06 +0200 From: Yoav Nir To: Michael Richardson Date: Mon, 2 Jan 2012 09:31:02 +0200 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) (was Moving Authentication Header (AH) to Historic) Thread-Index: AczJIH0WWGdiUPZRTuGRm+KIZMKP4Q== Message-ID: <4FD9C90A-13E1-478A-B21B-EBB41DE9A704@checkpoint.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> <6E38F4E9-8335-43F9-BA7A-9BB1E209E987@vpnc.org> <7C362EEF9C7896468B36C9B79200D8350D027BB274@INBANSXCHMBSA1.in.alcatel-lucent.com> <24EFE65B-86E0-4473-AF48-98B0C50F7041@vpnc.org> <7C362EEF9C7896468B36C9B79200D8350D027BB27B@INBANSXCHMBSA1.in.alcatel-lucent.com> <20536.1325463074@marajade.sandelman.ca> In-Reply-To: <20536.1325463074@marajade.sandelman.ca> 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] Avoiding Authentication Header (AH) (was 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: Mon, 02 Jan 2012 07:31:11 -0000 On Jan 2, 2012, at 2:11 AM, Michael Richardson wrote: >=20 > This property is simply undesireable for many security systems, > including all VPNs. =20 >=20 > Having said all of this, I agree that for 99% of "Use IPsec" > statements, ESP-NULL is likely the correct choice. I don't think you actually meant to say that, right? Most of the "Use IPsec" statements are followed by "and you'd better have 1= 28 bits of security in the encryption". Having said that, there was a thread some months ago about making a modifie= d AH that does not MAC the stuff in previous headers - only its own fields = and what follows. That would solve the "AH does not work through NAT" probl= em, but would make it even more indistinguishable from ESP-NULL. Except wha= t you said about it being just another header. Yoav From rja.lists@gmail.com Mon Jan 2 06:34:26 2012 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 EA9A321F84ED for ; Mon, 2 Jan 2012 06:34:26 -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 kQJAH1Z1bbYc for ; Mon, 2 Jan 2012 06:34:26 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E671A21F84DD for ; Mon, 2 Jan 2012 06:34:25 -0800 (PST) Received: by qadb15 with SMTP id b15so9103334qad.10 for ; Mon, 02 Jan 2012 06:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer; bh=EA3oI1odZmGvfSu4PqGE3dAJ6WiU8/b/IC+GpaS5K1o=; b=hQc+TBm7Aiag9qd52j//nfdSU0H5ecy59tbTQfFZwxBs6yeIbi9jlc9ze9Qv3ok0mo okGT9Q6z9Y14ZuiZ9bBtAXzF3K97DxzQO5dc7s2PClL4SCNpt3fD40vRz/SeyIFW/y0n 7C9zf2gz/X0zKmIweoc/jYlX2C/ngR5xyui0E= Received: by 10.224.193.7 with SMTP id ds7mr15623617qab.66.1325514864240; Mon, 02 Jan 2012 06:34:24 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id ev2sm45180455qab.15.2012.01.02.06.34.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 06:34:23 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 2 Jan 2012 09:34:21 -0500 To: IPsec ME WG List Message-Id: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 02 Jan 2012 14:34:27 -0000 Folks, I mostly entirely agree with Michael Richardson's analysis at the URL just below, namely that AH continues to have utility -- but that utility is not VPN deployments. Michael Richardson's note: HISTORY Important history is that both ESP and AH were originally products of the IPv6 Working Group. They moved into the IPsec WG because the IPsec WG had not made significant progress at that time (early 1990s). AH was created and exists primarily to enable authentication, including intermediate authentication, of IPv4 and IPv6 options, extension headers, and so forth. BACKGROUND & AVAILABILITY: Many modern silicon-based routers and firewalls, from multiple router vendors, can parse or parse-past options and optional headers at wire speed, so existence of an IP-layer option or extension does not today automatically push the IP packet on to what folks historically called the "slow path" for packet forwarding. This makes it much more practical to deploy IP options and IP optional headers now than in the past. Virtually all IPv6 hosts, and most IPv4 hosts, support AH in shipping product, and have done for ~15 years now. This includes both commercial products and open-source implementations. Most major IPv6 routers, for example multiple product lines from both Cisco and Juniper, also support AH in shipping product and have done for some while now. So AH remains a very widely available protocol. CURRENTLY DEPLOYED USES: While AH uses are limited today, just as the use of IP options/extensions are limited today, current active uses of AH in real-world deployments today include at least these -- built using commercial off-the-shelf products: - AH with IPv4 to authenticate sensitivity label options (e.g. FIPS-188, RFC-1108). - AH with IPv4 to prevent options-based attacks, primarily in certain high-threat environments. - AH with IPv6 to authenticate certain IPv6 extension headers and options, primarily in certain high-threat environments. - AH with IPv6 to prevent extension-header-based and options-based attacks, primarily in certain high-threat environments. - Many IPv6 deployments using OSPFv3 have enabled OSPFv3 protection using AH. Most router vendors, including (for example) multiple product lines from both Cisco and Juniper, shipped this capability long ago -- and this use of AH is both interoperable and widespread, largely within IPv6 enterprise deployments. OSPFv3 itself is largely deployed in enterprises today, as I/IS-IS is more popular with ISPs. [NOTE WELL: AH for OSPFv3 has NOT been deprecated, and remains on the IETF standards track. It is interesting, however, that author of this AH draft is trying to kill off the use of AH to protect routing information -- apparently because his employer does not offer this AH for OSPFv3 capability in its released products.] - Some IPv6 profiles, including the US Government profile for IPv6, require AH support either generally or in certain situations (example: to protect OSPFv3, to authenticate certain IP options or IP extension headers). This WG ought not make existing legitimate uses of AH invalid or not recommended. There is no available alternative for authenticating IP-layer options, extension headers, and so forth. AH is the only available way to do such authentication at present. FIREWALLS & MIDDLEBOXES: While this WG has produced some documents with guidance on how to approach parsing past an ESP header when NULL encryption is used, we still do not have a completely reliable way to parse past an ESP header when NULL encryption is used. By contrast, it is easy and quick to parse past an AH header -- either in the end system or in a firewall/router/middlebox. Several deployed firewall products in fact can and do parse past AH headers, either to perform deep packet inspection or simply to examine the transport protocol and port information. IETF PROCESS RULES: Last, on an IETF Process note, the IPsec WG Charter posted online is quite strict and is narrowly defined, with an enumerated list of allowed work items. To quote from the charter: "The scope of the WG is restricted to the work items listed above." Neither changes to AH status nor Applicability Statements for AH are listed in the WG Charter. So it is not obvious that this document is within the charter for the IPsec ME WG. If the IPsec ME WG Chairs believe this work is within charter, they ought to post a note to the IPsec ME WG mailing list citing the specific charter text authorising this topic. IPsec ME Charter: A draft outside the Charter of an IETF WG ought not be developed by or within that WG. So I don't see how this document properly can be considered by this WG. Yours, Ran From paul.hoffman@vpnc.org Mon Jan 2 06:43:46 2012 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 17CA321F8500 for ; Mon, 2 Jan 2012 06:43:46 -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.072, 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 Wck6aEEo0sIT for ; Mon, 2 Jan 2012 06:43:45 -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 8D10521F84F8 for ; Mon, 2 Jan 2012 06:43:45 -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 q02EhW8F024840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 2 Jan 2012 07:43:33 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> Date: Mon, 2 Jan 2012 06:43:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1251.1) Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 02 Jan 2012 14:43:46 -0000 On Jan 2, 2012, at 6:34 AM, RJ Atkinson wrote: > So it is not obvious that this document is within the charter=20 > for the IPsec ME WG. =20 It is obvious that it is not. > If the IPsec ME WG Chairs believe this work is within charter,=20 We do not. This mailing list is also used for anyone with drafts that = deal with modern IPsec usage, such as the documents in this thread. Are = you saying that such documents should not be discussed on this mailing = list? --Paul Hoffman From manav.bhatia@alcatel-lucent.com Mon Jan 2 07:16:18 2012 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 1271821F889A for ; Mon, 2 Jan 2012 07:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.567 X-Spam-Level: X-Spam-Status: No, score=-6.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 w2e6AeFOOA8p for ; Mon, 2 Jan 2012 07:16:17 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 697FC21F888A for ; Mon, 2 Jan 2012 07:16:17 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q02FGDHN021463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jan 2012 09:16:15 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q02FGBgV030642 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jan 2012 20:46:12 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Mon, 2 Jan 2012 20:46:11 +0530 From: "Bhatia, Manav (Manav)" To: RJ Atkinson , IPsec ME WG List Date: Mon, 2 Jan 2012 20:46:10 +0530 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) Thread-Index: AczJW6T+2hHNazq9RyqDMuiFB0e25AAA+hbw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> In-Reply-To: <12533D04-6B3F-490F-935B-4F1FA612C938@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 02 Jan 2012 15:16:18 -0000 [clipped] > Most major IPv6 routers, for example multiple product lines from both Cis= co=20 > and Juniper, also support AH in shipping product and have done for some w= hile now. =20 > So AH remains a very widely available protocol. It may be widely available, but clearly it isnt as widely used. Are you suggesting that newer protocols should mandate AH or they should be= proposing extensions to AH? I think all we're saying is that newer protoco= ls should suggest extensions to ESP-NULL wherever possible. They must have = a good reason to suggest mandating AH. What is the problem with this? > - Many IPv6 deployments using OSPFv3 have enabled > OSPFv3 protection using AH. Most router vendors, > including (for example) multiple product lines=20 > from both Cisco and Juniper, shipped this capability=20 > long ago -- and this use of AH is both interoperable=20 > and widespread, largely within IPv6 enterprise > deployments. OSPFv3 itself is largely deployed in > enterprises today, as I/IS-IS is more popular with > ISPs. The RFC that describes OSPFv3 authentication has the following line: In order to provide authentication to OSPFv3, implementations MUST support = ESP and MAY support AH. You might also be interested in the following draft which will be published= as RFC any time now: http://tools.ietf.org/html/draft-ietf-ospf-auth-trailer-ospfv3-11 > > [NOTE WELL: AH for OSPFv3 has NOT been deprecated, and > remains on the IETF standards track. It is interesting, > however, that author of this AH draft is trying to kill=20 > off the use of AH to protect routing information --=20 > apparently because his employer does not offer this=20 > AH for OSPFv3 capability in its released products.] Really? I would like to try whatever you've been smoking. > - Some IPv6 profiles, including the US Government > profile for IPv6, require AH support either generally > or in certain situations (example: to protect OSPFv3, > to authenticate certain IP options or IP extension > headers). Just trying to understand. Is there a reason why ESP-NULL cant be used? > This WG ought not make existing legitimate uses of AH invalid or not reco= mmended. =20 What makes you think that this draft is trying to do that? > There is no available alternative for authenticating IP-layer options, ex= tension headers, and so forth. =20 > AH is the only available way to do such authentication at present. If you include the ESP header before the extension headers can you not use = it to authenticate the extension headers? > FIREWALLS & MIDDLEBOXES: > > While this WG has produced some documents with guidance on how to approac= h parsing=20 > past an ESP header when NULL encryption is used, we still do not have a c= ompletely=20 > reliable way to parse past an ESP header when NULL encryption is used. =20 And pray why is that? Manav From vnktshsriram@gmail.com Mon Jan 2 07:43:43 2012 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 C426921F891D for ; Mon, 2 Jan 2012 07:43:43 -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 pzuJMt2TL3As for ; Mon, 2 Jan 2012 07:43:43 -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 2B9BF21F87C9 for ; Mon, 2 Jan 2012 07:43:43 -0800 (PST) Received: by yhjj72 with SMTP id j72so10367282yhj.31 for ; Mon, 02 Jan 2012 07:43:37 -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; bh=enKXgsPUXYKpnLI4F0lnKclXHdlBohIYyFfkC3w0oqk=; b=oRJK7dBqGgC/3X6vC+PP82MQAQHbu3Ma5uQxVm5W9oOPR8YKbVYGnNOj5ucxeONuPJ Ts5JVH/i1wLbrM8aO+2F8vBZYHjywwhxnAW/dq69emyQOUJZTFEDzEzYKvMB74SdXPRp w8Jiedpy8yvegChj6c5RQmBcoiRchfL/q9dAg= MIME-Version: 1.0 Received: by 10.236.175.72 with SMTP id y48mr63988268yhl.17.1325519017003; Mon, 02 Jan 2012 07:43:37 -0800 (PST) Received: by 10.236.183.228 with HTTP; Mon, 2 Jan 2012 07:43:36 -0800 (PST) In-Reply-To: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> Date: Mon, 2 Jan 2012 21:13:36 +0530 Message-ID: From: Venkatesh Sriram To: RJ Atkinson Content-Type: text/plain; charset=ISO-8859-1 Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 02 Jan 2012 15:43:43 -0000 If ESP and AH continue to co-exist then I see the following happening: (i) standard for feature foo1 using ESP-NULL + SW effort + QA effort + interop effort(ii) standard for feature foo1 using AH + SW effort + QA effort + interop effort(iii) standard for feature foo2 using ESP-NULL + SW effort + QA effort + interop effort(iv) standard for feature foo2 using AH + SW effort + QA effort + interop effort..(iii) standard for feature foo'n' using ESP-NULL + SW effort + QA effort + interop effort(iv) standard for feature foo'n' using AH + SW effort + QA effort + interop effort Now, i am willing to live with this if the security offered by AH and ESP-NULL is significantly different. I dont see why we should have this complication if ESP-NULL can do everything that AH has to offer. Why should the operators learn managing ESP and AH when both do the same? RFC 4301, by declaring ESP as a MUST and AH as a MAY has already set the context. I dont see why vendors and everybody else in the food chain should spend cycles on AH, if its not bringing anything substantial on the table? I dont think the draft in question says that AH is bad and should be deprecated. It merely says that WGs should be circumspect when mandating AH since its likely that most people are using ESP-NULL and you dont want to unnecessarily add complexity in people's lives for no good reason. Sriram From nico@cryptonector.com Mon Jan 2 08:04:23 2012 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 0593A11E809A for ; Mon, 2 Jan 2012 08:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.074, 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 PqVrkWF+9Mb0 for ; Mon, 2 Jan 2012 08:04:22 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 838DA11E8098 for ; Mon, 2 Jan 2012 08:04:22 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 3291E2AC073 for ; Mon, 2 Jan 2012 08:04:22 -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; q=dns; s=cryptonector.com; b=TOTFktkxAlDCFhOg98RJF slhtKb3mMtLi2BIv7a3EikuBYfGiub4utpqM3h4GrkcRKsPiwiVu66nWajDaprpQ NYU8SxkJNL3EGJjF2vKBcMnRuicx28iK0qKDZi/ZDzSr5L4bFwCQqSm1w5TcJ6p3 lYA9OMyK6y838WEdlhg78s= 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; s=cryptonector.com; bh=QOw3yqV3FDbh/uECwTS4 I+gj0NM=; b=gW0J/Rw3s5DDpV33ZjEOZQ80WE6a29JMkRnx7rNVcf7Kx11wmSzM 1/DxFj9Ay+hdqgISkRTjxeZ4jsUDpY3lwYcl2rIIJP7uRgeN3OI0OCCnTdjAuZc/ 5i6YxCZgn8CVofigvdlZcUFD/m1OoyT6LfNE7AghyOMwAUrwzkZecgo= 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-a90.g.dreamhost.com (Postfix) with ESMTPSA id 181C42AC06E for ; Mon, 2 Jan 2012 08:04:22 -0800 (PST) Received: by dajz8 with SMTP id z8so14971303daj.31 for ; Mon, 02 Jan 2012 08:04:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.234 with SMTP id o10mr124296452pbv.90.1325520261618; Mon, 02 Jan 2012 08:04:21 -0800 (PST) Received: by 10.68.10.234 with HTTP; Mon, 2 Jan 2012 08:04:21 -0800 (PST) In-Reply-To: References: <7C362EEF9C7896468B36C9B79200D8350D027BB264@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5D81F2F@MX14A.corp.emc.com> Date: Mon, 2 Jan 2012 10:04:21 -0600 Message-ID: From: Nico Williams To: Venkatesh Sriram Content-Type: text/plain; charset=UTF-8 Cc: ipsec@ietf.org, david.black@emc.com, 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: Mon, 02 Jan 2012 16:04:23 -0000 On Sat, Dec 31, 2011 at 9:41 PM, Venkatesh Sriram wrote: > 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. Hmmm, that wasn't my point. I believe it's fair to say that "Historic" here means "not to be used in new Standards-Track RFCs", and nothing more. Questions about the meaning of "Historic" and "deprecated" do need settling, because they are affecting how much effort we put into this as well as [potentially] the actual outcome. So, I am worried about process: the standardization process being affected by confusion about an important aspect of it. Nico -- From kohn.jack@gmail.com Mon Jan 2 11:15:38 2012 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 1808021F84B7 for ; Mon, 2 Jan 2012 11:15:38 -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 KAbmI7fVNF7K for ; Mon, 2 Jan 2012 11:15:37 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5D621F84AE for ; Mon, 2 Jan 2012 11:15:37 -0800 (PST) Received: by qadz3 with SMTP id z3so10271908qad.10 for ; Mon, 02 Jan 2012 11:15:36 -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=yJJW4K3whmQXAQMuoxcnHkEiHSAsPfgrDjyNj95jUcc=; b=WCjPQqyv700txMh4BXKGRIRQ3zP9/DlO9sJnUS2ztgqVW37h8I4lUStGLWpget8Izf E6pjP2ry/CNg1sKUjuaboq7mMnYaxcsA4xFdNfvwAY6va1JPfBuToYECeetsbv1faH4z 40poXutgRrDOyYwz5mJd6h/IfXpSwkYRP/Vjo= MIME-Version: 1.0 Received: by 10.224.183.65 with SMTP id cf1mr58171975qab.55.1325531736435; Mon, 02 Jan 2012 11:15:36 -0800 (PST) Received: by 10.229.39.139 with HTTP; Mon, 2 Jan 2012 11:15:36 -0800 (PST) In-Reply-To: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> Date: Tue, 3 Jan 2012 00:45:36 +0530 Message-ID: From: Jack Kohn To: RJ Atkinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 02 Jan 2012 19:15:38 -0000 > > =A0 =A0 =A0 =A0- AH with IPv6 to authenticate certain IPv6 > =A0 =A0 =A0 =A0 =A0extension headers and options, primarily in > =A0 =A0 =A0 =A0 =A0certain high-threat environments. > > =A0 =A0 =A0 =A0- AH with IPv6 to prevent extension-header-based > =A0 =A0 =A0 =A0 =A0and options-based attacks, primarily in certain > =A0 =A0 =A0 =A0 =A0high-threat environments. This piqued my interest. Which "extension header" does AH specifically protect in these "high-threat environments"? In case of IPv4, which field in the IP header are you most interested in protecting? Jack From kohn.jack@gmail.com Mon Jan 2 11:24:45 2012 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 0B7C21F0C48 for ; Mon, 2 Jan 2012 11:24:45 -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 6CGMeeyTmyir for ; Mon, 2 Jan 2012 11:24:44 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 444FD1F0C3F for ; Mon, 2 Jan 2012 11:24:44 -0800 (PST) Received: by qadb15 with SMTP id b15so9218063qad.10 for ; Mon, 02 Jan 2012 11:24:43 -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=xER+IDHrK0dpnu1mWAPzpwjQX0ZjNh/FBMgT4uEw8VI=; b=FKpfyHf8WPNp3jrU+JPWBjK/ncFvEClqTavyV0UniJPV5iKThZQnvtzoBYj1jScEZY EeoMQFup3Bj5SV28/nODKqjHDsM26v6UV6XNYt+vzM6ZSkMeDd4arR3Bqs9gOaEJ5D2C Tu/Cf929EjNBt0rx82DadGotDq1MPBef1e5/Q= MIME-Version: 1.0 Received: by 10.224.10.19 with SMTP id n19mr58054802qan.68.1325532282597; Mon, 02 Jan 2012 11:24:42 -0800 (PST) Received: by 10.229.39.139 with HTTP; Mon, 2 Jan 2012 11:24:42 -0800 (PST) In-Reply-To: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> Date: Tue, 3 Jan 2012 00:54:42 +0530 Message-ID: From: Jack Kohn To: RJ Atkinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 02 Jan 2012 19:24:45 -0000 > > While AH uses are limited today, just as the use of > IP options/extensions are limited today, current active > uses of AH in real-world deployments today include at least > these -- built using commercial off-the-shelf products: BTW, there is a discussion going on in NANOG on who uses AH and nobody seems to be raising their hands. Obviously, one cant take draw to much from that, but it just gives you a data point. Jack. > > =A0 =A0 =A0 =A0- AH with IPv4 to authenticate sensitivity label > =A0 =A0 =A0 =A0 =A0options (e.g. FIPS-188, RFC-1108). > > =A0 =A0 =A0 =A0- AH with IPv4 to prevent options-based attacks, > =A0 =A0 =A0 =A0 =A0primarily in certain high-threat environments. > > =A0 =A0 =A0 =A0- AH with IPv6 to authenticate certain IPv6 > =A0 =A0 =A0 =A0 =A0extension headers and options, primarily in > =A0 =A0 =A0 =A0 =A0certain high-threat environments. > > =A0 =A0 =A0 =A0- AH with IPv6 to prevent extension-header-based > =A0 =A0 =A0 =A0 =A0and options-based attacks, primarily in certain > =A0 =A0 =A0 =A0 =A0high-threat environments. > > =A0 =A0 =A0 =A0- Many IPv6 deployments using OSPFv3 have enabled > =A0 =A0 =A0 =A0 =A0OSPFv3 protection using AH. =A0Most router vendors, > =A0 =A0 =A0 =A0 =A0including (for example) multiple product lines > =A0 =A0 =A0 =A0 =A0from both Cisco and Juniper, shipped this capability > =A0 =A0 =A0 =A0 =A0long ago -- and this use of AH is both interoperable > =A0 =A0 =A0 =A0 =A0and widespread, largely within IPv6 enterprise > =A0 =A0 =A0 =A0 =A0deployments. =A0OSPFv3 itself is largely deployed in > =A0 =A0 =A0 =A0 =A0enterprises today, as I/IS-IS is more popular with > =A0 =A0 =A0 =A0 =A0ISPs. > > =A0 =A0 =A0 =A0 =A0[NOTE WELL: =A0AH for OSPFv3 has NOT been deprecated, = and > =A0 =A0 =A0 =A0 =A0remains on the IETF standards track. =A0It is interest= ing, > =A0 =A0 =A0 =A0 =A0however, that author of this AH draft is trying to kil= l > =A0 =A0 =A0 =A0 =A0off the use of AH to protect routing information -- > =A0 =A0 =A0 =A0 =A0apparently because his employer does not offer this > =A0 =A0 =A0 =A0 =A0AH for OSPFv3 capability in its released products.] > > =A0 =A0 =A0 =A0- Some IPv6 profiles, including the US Government > =A0 =A0 =A0 =A0 =A0profile for IPv6, require AH support either generally > =A0 =A0 =A0 =A0 =A0or in certain situations (example: to protect OSPFv3, > =A0 =A0 =A0 =A0 =A0to authenticate certain IP options or IP extension > =A0 =A0 =A0 =A0 =A0headers). > > This WG ought not make existing legitimate uses of AH > invalid or not recommended. =A0There is no available alternative > for authenticating IP-layer options, extension headers, > and so forth. =A0AH is the only available way to do such > authentication at present. > > > FIREWALLS & MIDDLEBOXES: > > While this WG has produced some documents with guidance > on how to approach parsing past an ESP header when NULL > encryption is used, we still do not have a completely > reliable way to parse past an ESP header when NULL > encryption is used. > > By contrast, it is easy and quick to parse past an AH header > -- either in the end system or in a firewall/router/middlebox. > Several deployed firewall products in fact can and do > parse past AH headers, either to perform deep packet inspection > or simply to examine the transport protocol and port information. > > > IETF PROCESS RULES: > > Last, on an IETF Process note, the IPsec WG Charter posted > online is quite strict and is narrowly defined, with an > enumerated list of allowed work items. =A0To quote from > the charter: > > =A0 =A0 =A0 =A0"The scope of the WG is restricted to the > =A0 =A0 =A0 =A0work items listed above." > > Neither changes to AH status nor Applicability Statements > for AH are listed in the WG Charter. > > So it is not obvious that this document is within the charter > for the IPsec ME WG. > > If the IPsec ME WG Chairs believe this work is within charter, > they ought to post a note to the IPsec ME WG mailing list > citing the specific charter text authorising this topic. > > IPsec ME Charter: > =A0 =A0 =A0 =A0 > > A draft outside the Charter of an IETF WG ought not > be developed by or within that WG. =A0So I don't see > how this document properly can be considered by this WG. > > > Yours, > > Ran > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From rja.lists@gmail.com Mon Jan 2 13:11:11 2012 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 B301721F8AD9 for ; Mon, 2 Jan 2012 13:11:11 -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 wKfiV7EaP2eA for ; Mon, 2 Jan 2012 13:11:11 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id EB8A121F8AD8 for ; Mon, 2 Jan 2012 13:11:10 -0800 (PST) Received: by qadz3 with SMTP id z3so10310266qad.10 for ; Mon, 02 Jan 2012 13:11:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=7dswbG4z9P7TPT7EgTJnV/cbV6F1cnr4YJx/5uKppU8=; b=bV+SXdhhTA8O13co3bBjaz9tgwCtYU5IkC+hsD3Jkdy/11dt7ZcBIBhqcjuUesCAll lWXg5x6xhUwINswmUtBnA+C39fcIeeg75uU2mIdztchduRWuSV6t3d9jY3uOJvPkkSQa p1FdL6GYKUj21slq1hgw2Q298ehaMam7KbI2I= Received: by 10.224.192.3 with SMTP id do3mr58651917qab.58.1325538669300; Mon, 02 Jan 2012 13:11:09 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id dk2sm26722292qab.12.2012.01.02.13.11.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 13:11:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: RJ Atkinson In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 2 Jan 2012 16:11:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 02 Jan 2012 21:11:11 -0000 On 02 Jan 2012, at 10:16 , Bhatia, Manav (Manav) wrote: > [clipped] >=20 >> Most major IPv6 routers, for example multiple product lines from both = Cisco=20 >> and Juniper, also support AH in shipping product and have done for = some while now. =20 >> So AH remains a very widely available protocol. >=20 > It may be widely available, but clearly it isnt as widely used. Use of AH to protect OSPFv3 is not uncommon within the set of sites that deploy OSPFv3. It provides protections that no other mechanism can provide, for example it can be used to detect options-based attacks. > You might also be interested in the following draft which will be = published as RFC any time now: > http://tools.ietf.org/html/draft-ietf-ospf-auth-trailer-ospfv3-11 I am well aware of it. That document does NOT deprecate=20 use of AH with OSPFv3 either. >> - Some IPv6 profiles, including the US Government >> profile for IPv6, require AH support either generally >> or in certain situations (example: to protect OSPFv3, >> to authenticate certain IP options or IP extension >> headers). >=20 > Just trying to understand. Is there a reason why ESP-NULL cant be = used? I gave a list earlier of a number of different scenarios where and reasons why AH is used. A subset of that list: - ESP null does not protect options/optional headers. - ESP null cannot reliably be parsed past. >> This WG ought not make existing legitimate uses of AH invalid or not = recommended. =20 >=20 > What makes you think that this draft is trying to do that? The text in your two drafts on the topic. >> There is no available alternative for authenticating IP-layer = options, extension headers, and so forth. =20 >> AH is the only available way to do such authentication at present. >=20 > If you include the ESP header before the extension headers can you not = use it to authenticate the extension headers? That isn't possible, for various reasons. =20 For IPv4, options always appear before the ESP header. For IPv6, there are multiple reasons, including but not limited to: - There still is no 100% reliable way to parse past an ESP NULL header=20 -- IPv6 has strict rules on the order of headers and an ESP NULL header can't appear before either=20 a Routing Header or a Hop-by-Hop Options Header=20 because those two header types need to be 100% readable=20 by routers handling the IPv6 packet. >> FIREWALLS & MIDDLEBOXES: >>=20 >> While this WG has produced some documents with guidance on how to = approach parsing=20 >> past an ESP header when NULL encryption is used, we still do not have = a completely=20 >> reliable way to parse past an ESP header when NULL encryption is = used. =20 >=20 > And pray why is that? The existing documents' methods aren't 100% reliable. I wish they were, but they aren't. Yours, Ran From rja.lists@gmail.com Mon Jan 2 13:28:56 2012 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 1CBAF1F0C36 for ; Mon, 2 Jan 2012 13:28:56 -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 d1kY-Ml+eg31 for ; Mon, 2 Jan 2012 13:28:55 -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 88BFE1F0C35 for ; Mon, 2 Jan 2012 13:28:55 -0800 (PST) Received: by qcsf15 with SMTP id f15so11360198qcs.31 for ; Mon, 02 Jan 2012 13:28:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=Pi8CkoNlnth/N4X6iPBDIs5nRnLSzjh0BWsq3mjBYEY=; b=fAjffnfxdyw6kYqCe8mP0MHDFYvVG32EIU4TTYpRAWXNR0uEA7icr1yfOGx8ZS8IPX cnpFXmIvouFlmcqvdHPvQt62BtLo+NXmNNHP90fvR+JghnXeg6PWhzDZbClyzccgY5FH /mkQWdjHsXx/5GzEOhspioIofsi5k1Di+mNhk= Received: by 10.229.111.89 with SMTP id r25mr7656761qcp.106.1325539734080; Mon, 02 Jan 2012 13:28:54 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id t4sm16759535qal.17.2012.01.02.13.28.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 13:28:53 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) From: RJ Atkinson In-Reply-To: Date: Mon, 2 Jan 2012 16:28:53 -0500 Content-Transfer-Encoding: 7bit Message-Id: <75E7DE71-65E0-40E9-8F7D-4EE5317F908C@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 02 Jan 2012 21:28:56 -0000 On 02 Jan 2012, at 14:24 , Jack Kohn wrote: >> While AH uses are limited today, just as the use of >> IP options/extensions are limited today, current active >> uses of AH in real-world deployments today include at least >> these -- built using commercial off-the-shelf products: > > BTW, there is a discussion going on in NANOG on who uses AH > and nobody seems to be raising their hands. > > Obviously, one cant take draw to much from that, > but it just gives you a data point. I absolutely believe that. It is not a surprise. More data is almost always better than less data. NANOG list membership is mostly, not entirely, but mostly, ISP folks and content providers. Threat models for ISPs tend to focus on protecting the transit infrastructure and their provisioning/management platforms. Many ISPs seem to share similar threat models. Threat models for end users tend to be different -- and vary pretty widely. I haven't been at an ISP for a decade, but I'd be surprised to see an ISP put a firewall in their transit network, whereas many enterprise deployments have multiple firewalls (and also IDSs and other boxes) throughout their network. Threat models vary between ISPs and enterprises and other users. Common deployment models vary also by type of user. ISPs tend to deploy I/IS-IS as their IGP for a range of reasons, while other users more commonly deploy OSPF as their IGP. No doubt there are exceptions to those trends. Financial institutions are obvious examples of high-threat environments. A compromise at a large financial institution could have a very high monetary cost to the victim institution. Often this means large financial institutions find it worthwhile to deploy security measures that other sites do not find worthwhile. Cheers, Ran From dharkins@lounge.org Mon Jan 2 13:53:36 2012 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 B85411F0C4F for ; Mon, 2 Jan 2012 13:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, 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 QTLJeGk0oACO for ; Mon, 2 Jan 2012 13:53:36 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 32D6E1F0C35 for ; Mon, 2 Jan 2012 13:53:36 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C46B6A88810C; Mon, 2 Jan 2012 13:53:35 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 2 Jan 2012 13:53:35 -0800 (PST) Message-ID: In-Reply-To: References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> Date: Mon, 2 Jan 2012 13:53:35 -0800 (PST) From: "Dan Harkins" To: "Venkatesh Sriram" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IPsec ME WG List , RJ Atkinson Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 02 Jan 2012 21:53:37 -0000 Hello, On Mon, January 2, 2012 7:43 am, Venkatesh Sriram wrote: > If ESP and AH continue to co-exist then I see the following happening: > (i) standard for feature foo1 using ESP-NULL + SW effort + QA effort + > interop effort(ii) standard for feature foo1 using AH + SW effort + QA > effort + interop effort(iii) standard for feature foo2 using ESP-NULL > + SW effort + QA effort + interop effort(iv) standard for feature foo2 > using AH + SW effort + QA effort + interop effort..(iii) standard for > feature foo'n' using ESP-NULL + SW effort + QA effort + interop > effort(iv) standard for feature foo'n' using AH + SW effort + QA > effort + interop effort If much of the above is not duplicative then you have bigger problems that AH. > Now, i am willing to live with this if the security offered by AH and > ESP-NULL is significantly different. I dont see why we should have > this complication if ESP-NULL can do everything that AH has to offer. Ran has provided a good list of things that AH can do that ESP-NULL cannot. > Why should the operators learn managing ESP and AH when both do the > same? > RFC 4301, by declaring ESP as a MUST and AH as a MAY has already set > the context. I dont see why vendors and everybody else in the food > chain should spend cycles on AH, if its not bringing anything > substantial on the table? If it's a MAY then don't spend any cycles on it. Implementations that support it MUST be prepared to interoperate with implementations that do not. > I dont think the draft in question says that AH is bad and should be > deprecated. It merely says that WGs should be circumspect when > mandating AH since its likely that most people are using ESP-NULL and > you dont want to unnecessarily add complexity in people's lives for no > good reason. If you want to direct WGs to be circumspect when specifying AH then why don't you go sit in those WGs and instruct them in what they should be doing? Or at the very least comment during LC. Honestly, if a WG is not paying attention to RFC 4301 then what makes you think they're gonna pay attention to a random individual submission? I don't have any particular love for AH but this effort is really lacking in one thing: a problem to solve. On the one hand, we're being told that the effort is necessary because WGs developing a "standard for protocol fool" need to be instructed on how to obtain integrity protection but we're also being told that discouraging AH is OK because no one (in NANOG) is using it and it's a MAY anyway. These seem to be somewhat contradictory to me-- either no one's using it and we have a solution in search of a problem; or, someone's using it and it would probably be a problem to restrict its use in the future. I detect the strong arm of a weak product management department at work here. If the engineers are complaining about implementing a protocol that isn't being used then grow a backbone and tell your customers that they're not gonna get support for a protocol they don't use. regards, Dan. From rja.lists@gmail.com Mon Jan 2 13:58:07 2012 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 3C44C11E80AD for ; Mon, 2 Jan 2012 13:58:07 -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 80WNtEWH18pM for ; Mon, 2 Jan 2012 13:58:06 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 992F211E8083 for ; Mon, 2 Jan 2012 13:58:04 -0800 (PST) Received: by qadb15 with SMTP id b15so9269272qad.10 for ; Mon, 02 Jan 2012 13:58:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=DefwebdYN8RWwhyIlsYTFUv30mxOzqspW54UQy21k9g=; b=f1OMQaUyn5fp3VTSFjRq/QGDDRQhbHeYsoGarLeImkxTFPo/2/UPj/Lu97ErPemdhe nd9GBL9bJxAZU4X4QUXiedV/Ngo/+ZCHxqbyDvvVOqNiJ88CdzNIkSLEFeHxn9X6iYOf hU+o89sRfwr2grQAz7Ma2K23QAXmCxstXZbXE= Received: by 10.224.203.67 with SMTP id fh3mr56994273qab.13.1325541483171; Mon, 02 Jan 2012 13:58:03 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id ev2sm47376344qab.15.2012.01.02.13.58.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 13:58:02 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) From: RJ Atkinson In-Reply-To: Date: Mon, 2 Jan 2012 16:58:01 -0500 Content-Transfer-Encoding: 7bit Message-Id: <639319E3-7725-4F23-9F78-46BB49FCF172@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 02 Jan 2012 21:58:07 -0000 On 02 Jan 2012, at 14:15 , Jack Kohn wrote: > In case of IPv4, which field in the IP header > are you most interested in protecting? An IPv4 example would be validating the [FIPS-188] IPv4 option, which can't be protected any other way. That option is supported by a range of operating systems, both commercial and open-source. I'm told by a a major computer vendor that Linux supports this for both IPv4 and IPv6. The option reportedly is deployed in environments ranging from certain large financial institutions to governments. Some devices that perform IP routing also perform security checks that ensure the label on a given packet is in range for the output interface; end systems also separately need to trust the label integrity. Similar IPv6 examples exist. Yours, Ran From kohn.jack@gmail.com Mon Jan 2 15:25:21 2012 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 355AC1F0C59 for ; Mon, 2 Jan 2012 15:25:21 -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 gdlTGm32slZt for ; Mon, 2 Jan 2012 15:25:20 -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 9C9CE1F0C35 for ; Mon, 2 Jan 2012 15:25:20 -0800 (PST) Received: by qcsf15 with SMTP id f15so11397011qcs.31 for ; Mon, 02 Jan 2012 15:25:20 -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=Mef/f7x6TaxdyNvqgxrnt9rl6BHCSpK6O0z/zA9qyPw=; b=DpBETBZEAUoginLQykSJRlcs4pONkI0T43MwCgGXDYESM49/4plQeQRLPU1gfsTD+6 yY3RLmPJixN8o1eA6BUdNR+7ccWEKXwtic8CPJXpCLu9LKTGp8BCCl3iItDwKCGRd3al sYVGjtIMDb6emkeP4D2WAf6da+ymJeCYfOgNE= MIME-Version: 1.0 Received: by 10.229.78.225 with SMTP id m33mr17456083qck.59.1325546720195; Mon, 02 Jan 2012 15:25:20 -0800 (PST) Received: by 10.229.39.139 with HTTP; Mon, 2 Jan 2012 15:25:20 -0800 (PST) In-Reply-To: <639319E3-7725-4F23-9F78-46BB49FCF172@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <639319E3-7725-4F23-9F78-46BB49FCF172@gmail.com> Date: Tue, 3 Jan 2012 04:55:20 +0530 Message-ID: From: Jack Kohn To: RJ Atkinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 02 Jan 2012 23:25:21 -0000 > An IPv4 example would be validating the [FIPS-188] > IPv4 option, which can't be protected any other way. > > That option is supported by a range of operating systems, > both commercial and open-source. =A0I'm told by a > a major computer vendor that Linux supports this > for both IPv4 and IPv6. =A0The option reportedly > is deployed in environments ranging from certain > large financial institutions to governments. > Some devices that perform IP routing also perform > security checks that ensure the label on a given > packet is in range for the output interface; > end systems also separately need to trust > the label integrity. > > Similar IPv6 examples exist. And i would like to know what those are. So you suggest that AH should be retained and encouraged since it supports FIPS-188 IP option. Great. What about IPv6? I am curious to know if you can come up with yet another esoteric extension header or application that only a handful of people know and have used - the way you have come up with IPv4. Jack From rja.lists@gmail.com Mon Jan 2 15:55:08 2012 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 E8F3C11E8095 for ; Mon, 2 Jan 2012 15:55:08 -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 uuppi-T8SPDN for ; Mon, 2 Jan 2012 15:55:08 -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 4895011E8083 for ; Mon, 2 Jan 2012 15:55:08 -0800 (PST) Received: by qcsf15 with SMTP id f15so11405162qcs.31 for ; Mon, 02 Jan 2012 15:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=gc6ebNemRuU6upfYwS95/rZH3cZk9lu7sFvSBfnhrjY=; b=TMbw/QDLCPgwmL2aLmPLM2wcOcGm5DMUPYkbXUhiInB8dQD6VN0jzcpR4W6yhqoKY/ d821Pa8Cci0t0tyuOroyvVX0ickCaibt39yxj46H9i4weM7xzYw+vlVIe/I22rCuqsCf +9iVKZt0wuiGR1GFD4T6AhzS0BXRxgyo3UqwA= Received: by 10.229.136.84 with SMTP id q20mr18254065qct.152.1325548506926; Mon, 02 Jan 2012 15:55:06 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id el7sm96054932qab.16.2012.01.02.15.55.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 15:55:06 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) From: RJ Atkinson In-Reply-To: Date: Mon, 2 Jan 2012 18:55:04 -0500 Content-Transfer-Encoding: 7bit Message-Id: <065A8A60-0342-47AC-84EE-8A312F60BB5F@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <639319E3-7725-4F23-9F78-46BB49FCF172@gmail.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 02 Jan 2012 23:55:09 -0000 On 02 Jan 2012, at 18:25 , Jack Kohn wrote: >> Similar IPv6 examples exist. > > And i would like to know what those are. > > What about IPv6? As I noted, a range of examples exist for IPv6, and another range of examples exist for IPv4. If one is inclined to study further, one possible starting place is the IANA registries of IP options and optional headers. Most, but sadly not all, currently defined IPv4 and IPv6 options are listed by IANA in various registries: Yours, Ran From rja.lists@gmail.com Mon Jan 2 16:04:41 2012 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 0E12311E8094 for ; Mon, 2 Jan 2012 16:04:41 -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 02lye+2wQD5r for ; Mon, 2 Jan 2012 16:04:40 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6D65B11E8073 for ; Mon, 2 Jan 2012 16:04:40 -0800 (PST) Received: by qadz3 with SMTP id z3so10360385qad.10 for ; Mon, 02 Jan 2012 16:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=PTnhroQwhrnThl3bBxrwm4bXjkM0/HOUULhGe9O0Jdw=; b=AJbRHBD628F/KQQknq8GFEEwXeloeeo/8BjbGDiWogHdIsJB5qSyoLjnorpa9DPhwx qAgGMLNZTozE+S+xSSNVyGkKLo/v34ijPmp8vFouZ3BthzoiQVamujXw3oOligQTxYKR Tegy9GtDLmbX9S/lZ0xZxytKl6hi16CLYW9FY= Received: by 10.224.205.4 with SMTP id fo4mr1373589qab.35.1325549079962; Mon, 02 Jan 2012 16:04:39 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id el7sm96103852qab.16.2012.01.02.16.04.38 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 16:04:39 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 2 Jan 2012 19:04:37 -0500 Message-Id: <51F52A9C-C160-4E5A-A250-1805B96411C0@gmail.com> To: IPsec ME WG List Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 00:04:41 -0000 Earlier, Dan Harkins wrote, in part: > Honestly, if a WG is not paying attention to RFC 4301, > then what makes you think they're gonna pay attention > to a random individual submission ? > > I don't have any particular love for AH but this effort > is really lacking in one thing: a problem to solve. > > On the one hand, we're being told that the effort is > necessary because WGs developing a "standard for protocol foo" > need to be instructed on how to obtain integrity protection, > but we're also being told that discouraging AH is OK > because no one (in NANOG) is using it and it's a MAY anyway. > > These seem to be somewhat contradictory to me -- > either no one's using it and we have a solution > in search of a problem; > or, someone's using it and it would probably be a problem > to restrict its use in the future. +1 From kohn.jack@gmail.com Mon Jan 2 16:15:38 2012 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 3A6F021F84A7 for ; Mon, 2 Jan 2012 16:15:38 -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 FfVe+Iybwkjm for ; Mon, 2 Jan 2012 16:15:37 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6F22A21F8450 for ; Mon, 2 Jan 2012 16:15:37 -0800 (PST) Received: by qadz3 with SMTP id z3so10363073qad.10 for ; Mon, 02 Jan 2012 16:15:34 -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=KtrrABJidV8gzDqvHK66c/8BM5wgwEqNRgTxdvvQZQ8=; b=LFbSNQ3l2Bg1boO9xBKiiC4RGkt8K/t2kiCt2uXRRo10oqerZK2Jvo9491m69JI+vi dFvliq4vshYJUlY3/NPH9EOEchfT8MF9YPzeHWHK3sPoT4BrRNKmdPrnlB5alV2aDupl 8heofs6KoCKO1si4VCirF2dpD+NMwTyI8uneE= MIME-Version: 1.0 Received: by 10.224.198.65 with SMTP id en1mr36767370qab.81.1325549734089; Mon, 02 Jan 2012 16:15:34 -0800 (PST) Received: by 10.229.39.139 with HTTP; Mon, 2 Jan 2012 16:15:34 -0800 (PST) In-Reply-To: <065A8A60-0342-47AC-84EE-8A312F60BB5F@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <639319E3-7725-4F23-9F78-46BB49FCF172@gmail.com> <065A8A60-0342-47AC-84EE-8A312F60BB5F@gmail.com> Date: Tue, 3 Jan 2012 05:45:34 +0530 Message-ID: From: Jack Kohn To: RJ Atkinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 00:15:38 -0000 We all know the different extension headers that exist in IPv6. You said AH helps in securing IPv6 extension headers. I want to understand which extension header did you specifically have in mind. You cant protect fragmentation header, since fragmentation is done after IPsec processing and the reassembly is done before IPsec processing. In case of Hop-by-Hop and Destination Options Header, its only the Option Type and the Option Length thats included in the AH ICV calculation. The data may or may not be included depending upon whether it can be modified in transit or not. ESP does not include the Option Type nad the Length. So, whats the *real* operational risk that youre looking at? AH covers the destination IP and the source IP. If somebody changes them, IPsec processing will fail at the SPD checks. So what do you gain by doing this? Again, whats the *real* gain that we get by AH? Jack On Tue, Jan 3, 2012 at 5:25 AM, RJ Atkinson wrote: > > On 02 =A0Jan 2012, at 18:25 , Jack Kohn wrote: >>> Similar IPv6 examples exist. >> >> And i would like to know what those are. >> >> What about IPv6? > > As I noted, a range of examples exist for IPv6, > and another range of examples exist for IPv4. > > If one is inclined to study further, one possible > starting place is the IANA registries of IP options > and optional headers. =A0Most, but sadly not all, > currently defined IPv4 and IPv6 options are listed > by IANA in various registries: > > =A0 =A0 =A0 =A0 > > Yours, > > Ran > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kohn.jack@gmail.com Mon Jan 2 16:21:51 2012 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 C1A6E21F8454 for ; Mon, 2 Jan 2012 16:21:51 -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 SmECJ0Izlsx9 for ; Mon, 2 Jan 2012 16:21:51 -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 EC91421F8452 for ; Mon, 2 Jan 2012 16:21:50 -0800 (PST) Received: by qcsf15 with SMTP id f15so11412774qcs.31 for ; Mon, 02 Jan 2012 16:21:48 -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=ibK2nIQN4WT9KZ1GM+6PHHS+z2QNs4Ot695j+DXViGU=; b=o8zvxpte1XlgsP7vh7JRrWyN3hDko5c3I8m3Isf52Zv5FdbK4Xjj5UvuE4U0NUczg9 FqYYLTaZxmDFCPvAe3H6Mhuw2haWV5JowxbVMUZqXcw9jDjdNvqwLMxJ4IPX5lrfkbrk 5ZGvEaU/qdGMHIBwnKiDgyuf1ea+PtleChIsU= MIME-Version: 1.0 Received: by 10.229.78.225 with SMTP id m33mr17492410qck.59.1325550108465; Mon, 02 Jan 2012 16:21:48 -0800 (PST) Received: by 10.229.39.139 with HTTP; Mon, 2 Jan 2012 16:21:48 -0800 (PST) In-Reply-To: <065A8A60-0342-47AC-84EE-8A312F60BB5F@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <639319E3-7725-4F23-9F78-46BB49FCF172@gmail.com> <065A8A60-0342-47AC-84EE-8A312F60BB5F@gmail.com> Date: Tue, 3 Jan 2012 05:51:48 +0530 Message-ID: From: Jack Kohn To: RJ Atkinson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 00:21:51 -0000 And last but certainly not the least, why cant somebody use ESP-NULL in the tunnel mode to protect the IP headers (including FIPS-188 IP option that i have never seen anyone ever using). Yours, Jack On Tue, Jan 3, 2012 at 5:25 AM, RJ Atkinson wrote: > > On 02 =A0Jan 2012, at 18:25 , Jack Kohn wrote: >>> Similar IPv6 examples exist. >> >> And i would like to know what those are. >> >> What about IPv6? > > As I noted, a range of examples exist for IPv6, > and another range of examples exist for IPv4. > > If one is inclined to study further, one possible > starting place is the IANA registries of IP options > and optional headers. =A0Most, but sadly not all, > currently defined IPv4 and IPv6 options are listed > by IANA in various registries: > > =A0 =A0 =A0 =A0 > > Yours, > > Ran > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nico@cryptonector.com Mon Jan 2 16:28:45 2012 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 D3D0B21F84C0 for ; Mon, 2 Jan 2012 16:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.068, 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 n4s8xWM1dh8P for ; Mon, 2 Jan 2012 16:28:45 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB3021F8486 for ; Mon, 2 Jan 2012 16:28:45 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 62B782C8058 for ; Mon, 2 Jan 2012 16:28:43 -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=NVOJHAesFdWdGBYxu7V5q/QEKQL/C2ESUeKNOBcue+7h qupaLQy7KYeFcmvu7NYpAKGPqnJyleKGAvXrvjujPqmNeDqhvtpQf2ZrMHWtmwu9 gNrtkpWqQdcpIfNsEQOEMSan7S69lW9UACFznmNgp8tyn4nflJYwCz1tkjyRJ3Q= 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=fWT0fVzdAARdeZzb+MFu/SW/JqU=; b=TB+Mp1MaRbD JY5oSK/b1fmTdFHqmHnxxJ/k99P+A3tYqjZuf7nb57kt7OEkToKWrvdLSxyvVSGw j5Zu8deW/VQfvbWaKZwgi1lkQ5DkJfXJhCHLjPGjSa98bvKayhd7J/FgyeLN9MTe s9EkOhEx95qrpM8Q31sgoS7dbG40eKP4= 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-a24.g.dreamhost.com (Postfix) with ESMTPSA id 40B6C2C8057 for ; Mon, 2 Jan 2012 16:28:43 -0800 (PST) Received: by dajz8 with SMTP id z8so15191979daj.31 for ; Mon, 02 Jan 2012 16:28:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.234 with SMTP id o10mr127394022pbv.90.1325550522569; Mon, 02 Jan 2012 16:28:42 -0800 (PST) Received: by 10.68.10.234 with HTTP; Mon, 2 Jan 2012 16:28:42 -0800 (PST) In-Reply-To: References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 2 Jan 2012 18:28:42 -0600 Message-ID: From: Nico Williams To: RJ Atkinson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 00:28:46 -0000 On Mon, Jan 2, 2012 at 3:11 PM, RJ Atkinson wrote: > I gave a list earlier of a number of different scenarios where > and reasons why AH is used. =C2=A0A subset of that list: > =C2=A0 =C2=A0 =C2=A0 =C2=A0- ESP null does not protect options/optional h= eaders. ESP in tunnel mode is supposed to be the replacement for AH, and gets you t= his. > =C2=A0 =C2=A0 =C2=A0 =C2=A0- ESP null cannot reliably be parsed past. WESP is supposed to provide this. Would tunnel mode be too expensive for new protocols that need integrity protection of outer headers? In any case, if there's no way to remove AH support from existing implementations any time soon, then there's not much benefit to moving AH to Historic either. And it's clear that the controversy that has arisen will take a fair bit of energy to resolve. It may be best to simply publish an Informational RFC providing advice on what new protocols that say "use IPsec" should do. Nico -- From manav.bhatia@alcatel-lucent.com Mon Jan 2 16:36:12 2012 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 8730321F8519 for ; Mon, 2 Jan 2012 16:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 OghkzTyw9V71 for ; Mon, 2 Jan 2012 16:36:11 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id AB6ED21F8516 for ; Mon, 2 Jan 2012 16:36:11 -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 q030a4cH027141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jan 2012 18:36:07 -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 q030a3eA010443 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Jan 2012 06:06:03 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Tue, 3 Jan 2012 06:06:02 +0530 From: "Bhatia, Manav (Manav)" To: Nico Williams , RJ Atkinson Date: Tue, 3 Jan 2012 06:06:05 +0530 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) Thread-Index: AczJrq1PhS5hZxfKQc2AIei//7clVQAAEZzQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350D027BB483@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 00:36:12 -0000 Hi Nico, http://tools.ietf.org/html/draft-bhatia-ipsecme-avoiding-ah-00 is NOT tryin= g to move AH to Historic. Its merely trying to discourage newer applications and protocols from manda= ting AH as the same level of security can be achieved with ESP-NULL. The dr= aft also says: 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 the reason why ESP with NULL encryption algorithm cannot be used instead. I had initially published an Informational draft till a few folks pointed o= ut that it could be a BCP. Cheers, Manav -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of N= ico Williams Sent: Tuesday, January 03, 2012 5:59 AM To: RJ Atkinson Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) On Mon, Jan 2, 2012 at 3:11 PM, RJ Atkinson wrote: > I gave a list earlier of a number of different scenarios where and=20 > reasons why AH is used. =A0A subset of that list: > =A0 =A0 =A0 =A0- ESP null does not protect options/optional headers. ESP in tunnel mode is supposed to be the replacement for AH, and gets you t= his. > =A0 =A0 =A0 =A0- ESP null cannot reliably be parsed past. WESP is supposed to provide this. Would tunnel mode be too expensive for new protocols that need integrity pr= otection of outer headers? In any case, if there's no way to remove AH support from existing implement= ations any time soon, then there's not much benefit to moving AH to Histori= c either. And it's clear that the controversy that has arisen will take a = fair bit of energy to resolve. It may be best to simply publish an Informa= tional RFC providing advice on what new protocols that say "use IPsec" shou= ld do. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From rja.lists@gmail.com Mon Jan 2 16:45:52 2012 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 CC67B21F852F for ; Mon, 2 Jan 2012 16:45:52 -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 zIEBgweuJ-MX for ; Mon, 2 Jan 2012 16:45:52 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3997521F852D for ; Mon, 2 Jan 2012 16:45:52 -0800 (PST) Received: by qadz3 with SMTP id z3so10371025qad.10 for ; Mon, 02 Jan 2012 16:45:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=gEecggv4O/Vw3CeLEx+AqWRvzNfFGhBJTrC9Hx2Tn54=; b=qUK4hRq+rXG+bqWc4Cjz5AgpIWV7fKdJBLbLZp5shOHb94dkc1qd7V96J7+Qd0vSHp zZ2dMsTVQ+geZmxat2HULNx5lE10ldxqvHMjy39NAjIJn2U1/zEv2DYfS9DLtVB8FUTA WrAe7Nxqu9wbRIBEh4mng9Ss3MeTPV8Y6lkVM= Received: by 10.224.106.5 with SMTP id v5mr59315155qao.74.1325551551716; Mon, 02 Jan 2012 16:45:51 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id cf18sm45164208qab.9.2012.01.02.16.45.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 16:45:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: RJ Atkinson In-Reply-To: Date: Mon, 2 Jan 2012 19:45:49 -0500 Content-Transfer-Encoding: 7bit Message-Id: <31DFE5C9-2DE0-4A1B-A216-AE8F47E75109@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 00:45:52 -0000 On 02 Jan 2012, at 19:28 , Nico Williams wrote: > On Mon, Jan 2, 2012 at 3:11 PM, RJ Atkinson wrote: >> I gave a list earlier of a number of different scenarios where >> and reasons why AH is used. A subset of that list: >> - ESP null does not protect options/optional headers. > > ESP in tunnel mode is supposed to be the replacement for AH, > and gets you this. Sadly, it cannot do so. Tunnel-mode isn't especially helpful here -- particularly for options or optional headers that are intended to be read/seen and their contents considered when forwarding transit IP packets. In IPv4, ESP can't protect any IPv4 options, because the ESP header always follows the IPv4 options. In IPv6, there are also problems. For example, if one has a Routing Header or Hop-by-Hop header then that would come BEFORE the ESP header -- precisely so that applicable routers or other middle boxes can see those headers in order to use their information during transit packet processing. >> - ESP null cannot reliably be parsed past. > > WESP is supposed to provide this. Sadly, at present there is still no 100% reliable method for parsing past an ESP header with NULL encryption. There are various documents describing methods which have various success probabilities, but none that is 100% reliable. > Would tunnel mode be too expensive for new protocols that need > integrity protection of outer headers? As noted above, tunnel-mode would not solve the technical problem. > In any case, if there's no way to remove AH support from existing > implementations any time soon, then there's not much benefit to moving > AH to Historic either. And it's clear that the controversy that has > arisen will take a fair bit of energy to resolve. It may be best to > simply publish an Informational RFC providing advice on what new > protocols that say "use IPsec" should do. We disagree on that. Existing IPsec RFCs are clear enough. If folks aren't going to read those, then they are not likely to read any new Informational RFC either. Dan Harkins' analysis was spot-on, IMHO. Yours, Ran From rja.lists@gmail.com Mon Jan 2 16:47:54 2012 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 9FF6B21F856A for ; Mon, 2 Jan 2012 16:47:54 -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=[AWL=0.000, 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 5ECLDk4UJtoS for ; Mon, 2 Jan 2012 16:47:54 -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 2293D21F8567 for ; Mon, 2 Jan 2012 16:47:54 -0800 (PST) Received: by qcsf15 with SMTP id f15so11419932qcs.31 for ; Mon, 02 Jan 2012 16:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=3+N2GFlC4RXGqn5rVBdFv7D+AN4lJEh00df7NDTdhwg=; b=fEyjx1027PAbBejaNHBHVtClbmVYu9Gce4uJ4sF7qIKzmQJk4elSRvLCQwFMek5Wc8 cSB04h1YVX8O0dn3Ybo6wtg8+nZl8tyWCUFZQmuV6DSvDp3X+b3GAsR4vn7etH8UjhuY wf17neq4e3KPSx4DPDfOVkQG7JZCr0/dF1ZtQ= Received: by 10.229.136.82 with SMTP id q18mr17394963qct.139.1325551673712; Mon, 02 Jan 2012 16:47:53 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id t4sm17760324qal.17.2012.01.02.16.47.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 16:47:53 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) From: RJ Atkinson In-Reply-To: Date: Mon, 2 Jan 2012 19:47:50 -0500 Content-Transfer-Encoding: 7bit Message-Id: <6E4858B9-F081-4421-9110-87FA35716C21@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <639319E3-7725-4F23-9F78-46BB49FCF172@gmail.com> <065A8A60-0342-47AC-84EE-8A312F60BB5F@gmail.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 00:47:54 -0000 On 02 Jan 2012, at 19:21 , Jack Kohn wrote: > And last but certainly not the least, why cant somebody use ESP-NULL > in the tunnel mode to protect the IP headers (including FIPS-188 IP > option that i have never seen anyone ever using). As noted originally, those options need to be seen and their contents considered by transit devices. Ran From rja.lists@gmail.com Mon Jan 2 16:51:14 2012 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 3C37921F856A for ; Mon, 2 Jan 2012 16:51:14 -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 WWETVI8oxZfi for ; Mon, 2 Jan 2012 16:51:13 -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 AA42C21F8530 for ; Mon, 2 Jan 2012 16:51:13 -0800 (PST) Received: by qcsf15 with SMTP id f15so11420791qcs.31 for ; Mon, 02 Jan 2012 16:51:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=oxBjx7vR+NnwK3yIy0FGyN8EkQGkpC07L0Jevgk87I0=; b=qW9wQQTWPGIXOBA4SSNVdHOywdA6CYiqPgd4U5LOc24DldURaRWkuqJVxVZrQQYyxf LNCWjFkC/dcL97YEMkcHAwZh3xT3Q5FaKp8jRm8f93V6oMSIcw63E23xK0M1hzS0jEdV rSIGt+jVbbPpB0JXhlJef8Lk5UeGZi39y6vv8= Received: by 10.229.135.77 with SMTP id m13mr17388550qct.119.1325551873154; Mon, 02 Jan 2012 16:51:13 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id h9sm96347916qac.13.2012.01.02.16.51.12 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 16:51:12 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) From: RJ Atkinson In-Reply-To: Date: Mon, 2 Jan 2012 19:51:11 -0500 Content-Transfer-Encoding: 7bit Message-Id: <91EAB07D-66A3-417F-A871-70C9FFF75E9F@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <639319E3-7725-4F23-9F78-46BB49FCF172@gmail.com> <065A8A60-0342-47AC-84EE-8A312F60BB5F@gmail.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 00:51:14 -0000 On 02 Jan 2012, at 19:15 , Jack Kohn wrote: > I want to understand which extension header did you > specifically have in mind. It isn't my job to write a document that isn't useful or necessary. I've supplied a subset of examples, which are sufficient to illustrate that ESP with NULL encryption is not equivalent to AH in the protection provided to IP packets. Yours, Ran From manav.bhatia@alcatel-lucent.com Mon Jan 2 16:51:19 2012 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 D215021F8570 for ; Mon, 2 Jan 2012 16:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.57 X-Spam-Level: X-Spam-Status: No, score=-6.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 d8m-aCmJxt60 for ; Mon, 2 Jan 2012 16:51:19 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4511121F8578 for ; Mon, 2 Jan 2012 16:51:18 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q030pENF027047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jan 2012 18:51:16 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q030pDvj025153 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Jan 2012 06:21:13 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 3 Jan 2012 06:21:13 +0530 From: "Bhatia, Manav (Manav)" To: RJ Atkinson , IPsec ME WG List Date: Tue, 3 Jan 2012 06:21:14 +0530 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) Thread-Index: AczJkxInBdO5Vny7TbqD7b3S+vzqEwAHKC/Q Message-ID: <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.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-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 00:51:19 -0000 Ran, > You might also be interested in the following draft which will be publish= ed as RFC any time now: > http://tools.ietf.org/html/draft-ietf-ospf-auth-trailer-ospfv3-11 > I am well aware of it. That document does NOT deprecate use of AH with O= SPFv3 either. It doesn't need to because nobody uses it. The reason the above draft exists is because there were many people (at lea= st service providers) who said that they did NOT want to use IPsec for OSPF= v3. I am sure you have customers who love using IPsec for OSPFv3, but there= is a larger percentage that doesn't. >>> This WG ought not make existing legitimate uses of AH invalid or not re= commended. =20 >=20 >> What makes you think that this draft is trying to do that? > The text in your two drafts on the topic. You did not understand the drafts. Please point to specific text that you think "make existing legitimate uses= of AH invalid or not recommended." The draft only talks about future applications and protocols. [clipped] > For IPv6, there are multiple reasons, including but not limited to: > - There still is no 100% reliable way to parse past an > ESP NULL header=20 Would appreciate if you can explain why you think WESP cannot reliably pars= e past an ESP header? > -- IPv6 has strict rules on the order of headers > and an ESP NULL header can't appear before either=20 > a Routing Header or a Hop-by-Hop Options Header=20 > because those two header types need to be 100% readable=20 > by routers handling the IPv6 packet. Routing Header is a security nightmare. You were probably not aware that it has been recently deprecated by the IET= F. http://tools.ietf.org/html/rfc5095 >From the draft-bhatia-ipsecme-avoiding-ah-00: Hop-by-Hop options are not an issue, as the intermediate hops do not have keys to verify the message authentication code so they cannot really be protected anyways. If you think not having ESP header before a few headers is a concern then w= e should fix that. If fixing this thing can get us rid of one protocol then= its probably a good thing to do. Cheers, Manav= From manav.bhatia@alcatel-lucent.com Mon Jan 2 16:54:04 2012 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 9F7ED21F8582 for ; Mon, 2 Jan 2012 16:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 VQMEGoU5RwZy for ; Mon, 2 Jan 2012 16:54:04 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id F133D21F8578 for ; Mon, 2 Jan 2012 16:54:03 -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 q030s0Iq000935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Jan 2012 18:54:02 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q030rxxx010826 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Jan 2012 06:23:59 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Tue, 3 Jan 2012 06:23:59 +0530 From: "Bhatia, Manav (Manav)" To: RJ Atkinson , IPsec ME WG List Date: Tue, 3 Jan 2012 06:24:00 +0530 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) Thread-Index: AczJsVfxjv8BGY6eSESUFQom0bCJWAAALadQ Message-ID: <7C362EEF9C7896468B36C9B79200D8350D027BB485@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <639319E3-7725-4F23-9F78-46BB49FCF172@gmail.com> <065A8A60-0342-47AC-84EE-8A312F60BB5F@gmail.com> <6E4858B9-F081-4421-9110-87FA35716C21@gmail.com> In-Reply-To: <6E4858B9-F081-4421-9110-87FA35716C21@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 00:54:04 -0000 And most of these are considered dangerous and are generally discouraged. http://tools.ietf.org/html/rfc6398 Cheers, Manav=20 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of R= J Atkinson Sent: Tuesday, January 03, 2012 6:18 AM To: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) On 02 Jan 2012, at 19:21 , Jack Kohn wrote: > And last but certainly not the least, why cant somebody use ESP-NULL=20 > in the tunnel mode to protect the IP headers (including FIPS-188 IP=20 > option that i have never seen anyone ever using). As noted originally, those options need to be seen and their contents consi= dered by transit devices.=20 Ran _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nico@cryptonector.com Mon Jan 2 17:06:20 2012 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 03EA321F8575 for ; Mon, 2 Jan 2012 17:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.064, 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 iGutbEvBBRgY for ; Mon, 2 Jan 2012 17:06:19 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 3A29F21F856E for ; Mon, 2 Jan 2012 17:06:19 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id DE78E26406C for ; Mon, 2 Jan 2012 17:06:18 -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=fIz5SWtec1dm97Y42P6NAsaQB+cPy5ObApfaTgkvOUfk lovygy3Z/iI6FHFLGdhJCxUAJqznmJYvXzaEY6MN9o8S+6ybtV0cKOtNsaWEyYhi jqHmWqzhzhkZzfaqSIGLcHMPkR6MLK/Qr9LxXa4Y/YGTMOxRwBLPtqC0nwKaC/k= 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=w9+ibiG0khUX4v3M3drXIQRv3Ns=; b=pQBquW0cDL3 wceAoQkOhkwQwtoQGIYu4C2AGac0ti5K7NwrZkfRAAVJcsPuswA0O16/If7WPLm8 QsXupNel8H/5bm1SF/g4KQjkOCyMDZL0wGx77xxU2kTZYahC054JDlsYvoWOQ+7I Rqx3fmJ3l/ecMKEtRPgFmYxX7culnH3I= 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-a88.g.dreamhost.com (Postfix) with ESMTPSA id C15CC26406A for ; Mon, 2 Jan 2012 17:06:18 -0800 (PST) Received: by dajz8 with SMTP id z8so15206298daj.31 for ; Mon, 02 Jan 2012 17:06:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.211.161 with SMTP id nd1mr7363537pbc.50.1325552778486; Mon, 02 Jan 2012 17:06:18 -0800 (PST) Received: by 10.68.10.234 with HTTP; Mon, 2 Jan 2012 17:06:18 -0800 (PST) In-Reply-To: <31DFE5C9-2DE0-4A1B-A216-AE8F47E75109@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <31DFE5C9-2DE0-4A1B-A216-AE8F47E75109@gmail.com> Date: Mon, 2 Jan 2012 19:06:18 -0600 Message-ID: From: Nico Williams To: RJ Atkinson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 01:06:20 -0000 On Mon, Jan 2, 2012 at 6:45 PM, RJ Atkinson wrote: > On 02 =C2=A0Jan 2012, at 19:28 , Nico Williams wrote: >> On Mon, Jan 2, 2012 at 3:11 PM, RJ Atkinson wrote: >>> I gave a list earlier of a number of different scenarios where >>> and reasons why AH is used. =C2=A0A subset of that list: >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0- ESP null does not protect options/optional= headers. >> >> ESP in tunnel mode is supposed to be the replacement for AH, >> and gets you this. > > Sadly, it cannot do so. > > Tunnel-mode isn't especially helpful here -- particularly > for options or optional headers that are intended to be > read/seen and their contents considered when forwarding > transit IP packets. With tunnel mode you effectively repeat the options inside and outside the tunnel. Routers can't validate the integrity protection regardless of whether AH or ESP-NULL in tunnel mode is used, but assuming that an attacker can only modify options at one place in the path then the recipient can see that options were modified. This is applies to both, IPv4 and v6. >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0- ESP null cannot reliably be parsed past. >> >> WESP is supposed to provide this. > > Sadly, at present there is still no 100% reliable > method for parsing past an ESP header with NULL encryption. > There are various documents describing methods which > have various success probabilities, but none that is > 100% reliable. Sure, this is necessarily true until any replacement for AH is universally deployed and that indicates that only integrity protection is provided. Nico -- From rja.lists@gmail.com Mon Jan 2 17:22:05 2012 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 AD4BF21F8518 for ; Mon, 2 Jan 2012 17:22:05 -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=[AWL=0.000, 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 uMQaRgF4zQQN for ; Mon, 2 Jan 2012 17:22:04 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id AC29C21F849E for ; Mon, 2 Jan 2012 17:22:04 -0800 (PST) Received: by qadz3 with SMTP id z3so10380223qad.10 for ; Mon, 02 Jan 2012 17:22:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=6UrKhu/8XA5PB/JxMLUAtYvxVCg/amdEs4OzKHJ+dZE=; b=Z9na2yGXTmGNiVJLktiPIggx7XAwHgOBJQKgsay+Pwdwy30Ivuk2vsUi7fCIxNWh6W nmGTqB2WOvkunSQkvEmXsYjrLttXTgawxHK+S04eG4/7ubvXSmYQDn6o9y+Ujn4n84XK t3ZHlONcU+YWjuK9z+2njO6MzLpmMHHtsUelU= Received: by 10.224.183.65 with SMTP id cf1mr59121825qab.55.1325553724243; Mon, 02 Jan 2012 17:22:04 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id el7sm96492525qab.16.2012.01.02.17.22.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 17:22:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: RJ Atkinson In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 2 Jan 2012 20:22:01 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 01:22:05 -0000 On 02 Jan 2012, at 19:51 , Bhatia, Manav (Manav) wrote: > It doesn't need to because nobody uses it. I know of multiple sites who have it deployed today. > The reason the above draft exists is because there were > many people (at least service providers) who said that > they did NOT want to use IPsec for OSPFv3. More precisely, a few service providers and a few vendors=20 said this. Major vendors had already shipped the capability, and numerous users had deployed it. =20 Unfortunately, the IETF has long-standing challenges with=20 getting users/operators, especially enterprise/academic/ government users, to participate in its WGs. Service providers are overwhelmingly using IS-IS for IPv6,=20 not OSPFv3, in any event. > I am sure you have customers who love using IPsec for OSPFv3, > but there is a larger percentage that doesn't. One of my clients operates a multi-continent IP network. I also have non-ISP clients. You acknowledge that you=20 have no contact with the IPsec for OSPFv3 users. So, by your own admission, I have more data than you do. We disagree on the percentages. > Routing Header is a security nightmare. > You were probably not aware that it has been recently deprecated by = the IETF. >=20 > http://tools.ietf.org/html/rfc5095 Actually, the IPv6 Routing Header itself is not deprecated. Only the RH Type 0 was deprecated by RFC-5095. IANA.org reports the Type 2 and Type 3 IPv6 Routing=20 Headers remain valid and are not deprecated (Type 3=20 is work in progress, but allocated already). > =46rom the draft-bhatia-ipsecme-avoiding-ah-00: >=20 > Hop-by-Hop options are not an issue, as the intermediate > hops do not have keys to verify the message authentication > code so they cannot really be protected anyways. That claim isn't true either. =20 Please consider deployments where the intermediate hops=20 DO have those keys, obtained for example from a KDC. =20 The IETF has standardised Kerberos, for example, so a standards-based solution exists in this area. Separately, RFC-4359 specifies how one can use=20 RSA/SHA-1 signatures within AH. So it is entirely possible to give a middle box a verification key -- without also giving the middle box a signing key for the traffic being protected. I'm not going to write the I-D for you, nor am I going to waste my time enumerating every single problem with the draft. There are too many technical flaws and it would take too long. I can't improve upon=20 Dan Harkins' explanation of why trying to fix the=20 I-D is a waste of time and energy. Yours, Ran From rja.lists@gmail.com Mon Jan 2 17:26:55 2012 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 48F5F21F852A for ; Mon, 2 Jan 2012 17:26:55 -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 GKHNNW6pqOQc for ; Mon, 2 Jan 2012 17:26:54 -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 B999C21F851D for ; Mon, 2 Jan 2012 17:26:54 -0800 (PST) Received: by qcsf15 with SMTP id f15so11430621qcs.31 for ; Mon, 02 Jan 2012 17:26:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=USAXOH7UHH3DDPmuy0SPhbT9vtmcN0QN24WIWG0OsXc=; b=Nj4Gt5jdOXx26iP3fmhrofOMVHZk0MxeuEJGG3AK1DbWNHwpfzlxzBZS+iRUoFk0As 6kOs6pXadHytqaEaO2qdJlYQH2U2MoP17HbD1C2uxWtM5KqLGwdHFIQA7T+CPa9ZLylR p8MoQI04AhYuZk1LzoeBR/V7DUvC97k/sZ2R4= Received: by 10.224.52.75 with SMTP id h11mr5972451qag.46.1325554014293; Mon, 02 Jan 2012 17:26:54 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id hv20sm96490581qab.22.2012.01.02.17.26.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 17:26:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: RJ Atkinson In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D027BB485@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Mon, 2 Jan 2012 20:26:52 -0500 Content-Transfer-Encoding: 7bit Message-Id: <7A9BAB01-05F5-4873-98E5-83004940B256@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <639319E3-7725-4F23-9F78-46BB49FCF172@gmail.com> <065A8A60-0342-47AC-84EE-8A312F60BB5F@gmail.com> <6E4858B9-F081-4421-9110-87FA35716C21@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB485@INBANSXCHMBSA1.in.alcatel-lucent.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 01:26:55 -0000 On 02 Jan 2012, at 19:54 , Bhatia, Manav (Manav) wrote: > And most of these are considered dangerous and are generally discouraged. > > http://tools.ietf.org/html/rfc6398 That RFC says the Router Alert Option might be abused by malicious transit traffic in global public transit networks, depending in part upon the quality of one's router implementation(s). It also says that the Router Alert Option can be deployed safely, for example within an Administrative Domain or in an Overlay deployment. It does not say that all hop-by-hop options are always bad. In fact, it says that they are often useful and can be deployed safely. Yours, Ran From rja.lists@gmail.com Mon Jan 2 17:34:49 2012 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 000E121F8534 for ; Mon, 2 Jan 2012 17:34: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=[AWL=0.000, 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 rt+ORTB1Y270 for ; Mon, 2 Jan 2012 17:34:48 -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 5267C21F8578 for ; Mon, 2 Jan 2012 17:34:48 -0800 (PST) Received: by qcsf15 with SMTP id f15so11432879qcs.31 for ; Mon, 02 Jan 2012 17:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=WmJ61atrGExPI+nUl+/pyO7Ju4nM8wh5FY2GQB/8PWc=; b=Ql5uq1tRP9CSCiMkn4nWFVnPYsc/SFHQHOHgZS6P7mMdb/fk+1mZBB36nmm2P+iGbj y96E7wJq3VOA41c5IbFTqk3yVk6MnECgbNEb2Jx08gQU1pckwt2Gr9aiumVvv1wVQci3 pPDP7miLipa2S5RXWt64j1zwWTFoEwSl/7nsg= Received: by 10.224.177.5 with SMTP id bg5mr24492252qab.87.1325554487896; Mon, 02 Jan 2012 17:34:47 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id dk2sm28044310qab.12.2012.01.02.17.34.46 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 Jan 2012 17:34:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: RJ Atkinson In-Reply-To: Date: Mon, 2 Jan 2012 20:34:45 -0500 Content-Transfer-Encoding: 7bit Message-Id: <470A0DC9-FD87-4EE4-8F23-227D86AD2B54@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <31DFE5C9-2DE0-4A1B-A216-AE8F47E75109@gmail.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 01:34:49 -0000 On 02 Jan 2012, at 20:06 , Nico Williams wrote: > On Mon, Jan 2, 2012 at 6:45 PM, RJ Atkinson wrote: > With tunnel mode you effectively repeat the options inside and outside > the tunnel. One could repeat the headers; some implementations don't. It doesn't help transit devices to repeat the headers if they can't validate them before acting upon them. > Routers can't validate the integrity protection > regardless of whether AH or ESP-NULL in tunnel mode is used, Disagree. Intermediate authentication can be performed by routers/firewalls, at least when AH is used. The router/firewall could then act on the options in the packet having reasonable assurance that the option itself, and its contents, were valid for that packet. > but assuming that an attacker can only modify options at one place in the > path then the recipient can see that options were modified. Unfortunately, it is not really a generally valid assumption that there is only 1 potential attack point along a path. >>>> - ESP null cannot reliably be parsed past. >>> >>> WESP is supposed to provide this. >> >> Sadly, at present there is still no 100% reliable >> method for parsing past an ESP header with NULL encryption. >> There are various documents describing methods which >> have various success probabilities, but none that is >> 100% reliable. > > Sure, this is necessarily true until any replacement for AH is > universally deployed and that indicates that only integrity > protection is provided. If some such mechanism exists, and if it provides 100% reliable ability to parse-past/parse-into, and if it is plausibly efficient to parse-into/parse-past in real-time for high-performance switches/routers/firewalls, then this discussion might be more useful than it is at present. That is rather a lot of IFs, however, none of which seem true today. Yours, Ran From mcr@sandelman.ca Mon Jan 2 20:08:52 2012 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 C8A6F21F858F for ; Mon, 2 Jan 2012 20:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[AWL=0.520, 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 IfoNchxncf0U for ; Mon, 2 Jan 2012 20:08:52 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 29CF921F858B for ; Mon, 2 Jan 2012 20:08:52 -0800 (PST) Received: from marajade.sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id 5D0723433A; Mon, 2 Jan 2012 23:06:57 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 9D32998147; Mon, 2 Jan 2012 23:08:49 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 98ACD9812A; Mon, 2 Jan 2012 23:08:49 -0500 (EST) From: Michael Richardson To: Jack Kohn In-Reply-To: References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <639319E3-7725-4F23-9F78-46BB49FCF172@gmail.com> <065A8A60-0342-47AC-84EE-8A312F60BB5F@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 02 Jan 2012 23:08:49 -0500 Message-ID: <27493.1325563729@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: IPsec ME WG List , RJ Atkinson Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 04:08:52 -0000 >>>>> "Jack" == Jack Kohn writes: Jack> We all know the different extension headers that exist in Jack> IPv6. Jack> You said AH helps in securing IPv6 extension headers. I want Jack> to understand which extension header did you specifically have Jack> in mind. let me ask a different question: what's the savings in obsoleting AH, given that RFC4301 already makes it optional, and many vendors have already implemented, tested and deployed the code? Jack> So, whats the *real* operational risk that youre looking at? Jack> AH covers the destination IP and the source IP. If somebody Jack> changes them, IPsec processing will fail at the SPD checks. So Jack> what do you gain by doing this? Jack> Again, whats the *real* gain that we get by AH? AH works for multicast, and could work even when the receiver does not have the key. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Mon Jan 2 20:09:20 2012 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 5543221F859A for ; Mon, 2 Jan 2012 20:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[AWL=0.433, 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 KDlcuIR3iKMS for ; Mon, 2 Jan 2012 20:09:20 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id E456C21F8595 for ; Mon, 2 Jan 2012 20:09:19 -0800 (PST) Received: from marajade.sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id DE13234463; Mon, 2 Jan 2012 23:07:18 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 2DCCB98147; Mon, 2 Jan 2012 23:09:11 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 277D49812A; Mon, 2 Jan 2012 23:09:11 -0500 (EST) From: Michael Richardson To: Jack Kohn In-Reply-To: References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <639319E3-7725-4F23-9F78-46BB49FCF172@gmail.com> <065A8A60-0342-47AC-84EE-8A312F60BB5F@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 02 Jan 2012 23:09:11 -0500 Message-ID: <27575.1325563751@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: IPsec ME WG List , RJ Atkinson Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 04:09:20 -0000 >>>>> "Jack" == Jack Kohn writes: Jack> And last but certainly not the least, why cant somebody use Jack> ESP-NULL in the tunnel mode to protect the IP headers Jack> (including FIPS-188 IP option that i have never seen anyone Jack> ever using). Someone can. Nothing stopping anyone. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Mon Jan 2 20:14:46 2012 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 AB1FE21F8592 for ; Mon, 2 Jan 2012 20:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.583 X-Spam-Level: X-Spam-Status: No, score=-1.583 tagged_above=-999 required=5 tests=[AWL=0.371, 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 Z86xpXEisocG for ; Mon, 2 Jan 2012 20:14:46 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0501C21F8590 for ; Mon, 2 Jan 2012 20:14:46 -0800 (PST) Received: from marajade.sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id 6285F34463 for ; Mon, 2 Jan 2012 23:12:52 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id A79C498147; Mon, 2 Jan 2012 23:14:44 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 9FA869812A for ; Mon, 2 Jan 2012 23:14:44 -0500 (EST) From: Michael Richardson To: IPsec ME WG List In-Reply-To: <470A0DC9-FD87-4EE4-8F23-227D86AD2B54@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <31DFE5C9-2DE0-4A1B-A216-AE8F47E75109@gmail.com> <470A0DC9-FD87-4EE4-8F23-227D86AD2B54@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 02 Jan 2012 23:14:44 -0500 Message-ID: <28498.1325564084@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 04:14:46 -0000 >>>>> "RJ" == RJ Atkinson writes: >> Routers can't validate the integrity protection regardless of >> whether AH or ESP-NULL in tunnel mode is used, RJ> Disagree. Intermediate authentication can be performed by RJ> routers/firewalls, at least when AH is used. The RJ> router/firewall could then act on the options in the packet RJ> having reasonable assurance that the option itself, and its RJ> contents, were valid for that packet. Just to add to this: this intermediate authentiation requires a different key distribution protocol than most VPN vendors are used to. In certain kinds of deployments, manually keyed AH and ESP is actually not that unusual (to many intermediate nodes too), and it makes sense for the small amount of traffic that is anticipated. Ran, as you've been rather inactive in IPsec, I suspect that some people might not know what pieces of code and specification you wrote, and who paid you to write those pieces of code. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From rja.lists@gmail.com Tue Jan 3 04:51:32 2012 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 6F8B821F8554 for ; Tue, 3 Jan 2012 04:51:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 mZiig-aK0C2h for ; Tue, 3 Jan 2012 04:51:32 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id E1E6B21F853F for ; Tue, 3 Jan 2012 04:51:31 -0800 (PST) Received: by qadz3 with SMTP id z3so10588106qad.10 for ; Tue, 03 Jan 2012 04:51:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=XAxTX1vxttdfVTZn1PA2DK6zpeUU3I6u5dcXxuhtHgg=; b=XyxpdRBK7JVjMpiApyI3DhEOikbS1wD+0kiY0WPDFCxOOLg3L2RJCfeLP9XXzIj/Ru iUTmQz8zw4KsbmJLZaal8hGE7MrzGzxT4ZI/kYaWo+u8QNonLOzxCCrOzGFB9yCca2nW pkkk3mKvg6aYp5xRnTgAHjjmLJNyUTRfmjgyw= Received: by 10.224.117.143 with SMTP id r15mr62160513qaq.36.1325595091387; Tue, 03 Jan 2012 04:51:31 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id r10sm99839621qaz.7.2012.01.03.04.51.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 03 Jan 2012 04:51:30 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 3 Jan 2012 07:51:31 -0500 Message-Id: To: IPsec ME WG List Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [IPsec] Aside: IPsec History 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, 03 Jan 2012 12:51:32 -0000 Earlier, Michael Richardson wrote: > Ran, as you've been rather inactive in IPsec, Fair point. I mostly watch without writing notes. IPsec hasn't been paid work for me since 1995, (and isn't paid work now -- just community service). > I suspect that some people might not know what > pieces of code and specification you wrote, > and who paid you to write those pieces of code. People I worked with wrote most of the IPsec code, for example two other folks were responsible for inventing and implementing PF_KEY, but the original specification work was mine -- and was very directly derived from NIST publications describing earlier work done by the SDNS Project to develop the SP3D protocol. If one looks at the original I-D for what became ESP, the packet format there is identical to SP3D. Our funding came from ARPA/CSTO, who were funding rather a lot of Internet R&D at that time, and from the Space & Naval Warfare Systems Command. Since this caused me to look back, I'll also note that the use of AH to authenticate IP options and prevent certain attacks is clearly documented by the 2nd paragraph on Page 10 of RFC-1826. Some other limitations inherent with tunnels are noted in the 3rd paragraph on the same page. Cheers, Ran From praveenys@juniper.net Tue Jan 3 12:35:00 2012 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 3753811E80FC for ; Tue, 3 Jan 2012 12:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 MOfiiwZMxJjo for ; Tue, 3 Jan 2012 12:34:59 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 37D6F11E80C7 for ; Tue, 3 Jan 2012 12:34:59 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTwNmZsWQYSP6H255jLH72/33Y0SSxXLN@postini.com; Tue, 03 Jan 2012 12:34:59 PST Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 3 Jan 2012 12:32:13 -0800 From: Praveen Sathyanarayan To: Mike Sullenberger , "ipsec@ietf.org" Date: Tue, 3 Jan 2012 12:32:11 -0800 Thread-Topic: [IPsec] Large Scale VPN Thread-Index: AczKVsaow14jz2kkS6yLXHHbnsRHzQ== Message-ID: In-Reply-To: <01O9UR5SKAYW96VL1D@Cisco.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 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, 03 Jan 2012 20:35:00 -0000 I would like to re-iterate again. 1.) Juniper solution is not based on GRE. Juniper solution is based on "pure" IPSec in tunnel mode. It works very well. 2.) Juniper implementation has many proprietary messages to solve all scenarios. NHRP is required, but it is not complete. 3.) Authentication method to authenticate spokes can be proprietary. We believe there is a need for standard, so that different vendors can interop. -- Praveen On 12/21/11 5:16 PM, "Mike Sullenberger" wrote: 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 | +------------------------------------------------+ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nico@cryptonector.com Tue Jan 3 15:41:49 2012 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 9D19811E808D for ; Tue, 3 Jan 2012 15:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.059, 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 pglBSSc-VTru for ; Tue, 3 Jan 2012 15:41:49 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 7723411E8097 for ; Tue, 3 Jan 2012 15:41:48 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id BC61C428096 for ; Tue, 3 Jan 2012 15:41:47 -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=CnPg+CjANhmSSrL2p6+6F0ahJiR8l2QYP8w/Aa+1nqRa 2jXGqr4PIbumjMeK6vA3dKBWsVR0UGRu36uK7eaCn6OoyE1j/jB48skVNd6X4o5g HAcXVk0zj1jbkGWPLfDSE6IaOqxqjLctE2AlCHFm5YMLkRk9vcRl2Luw22kkfag= 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=4NeYnHAx3T0HXbUF87R02GEOomw=; b=psLVxjHljID hiGEFKs/y6M4JbJJw3tek12hZErGGSohsLyKpF4rDbJ1sqQntkGFu1vYNNuA4WRR y7H6MU6qqzuowSsWUxqM+/XV+ofEag15vu5cov1mZprG9zeYv6UJ0R/4rOD1kEl8 AmeLB30Vwj+DY79wGFwWR/07XLCAo+j8= 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-a71.g.dreamhost.com (Postfix) with ESMTPSA id A724C428086 for ; Tue, 3 Jan 2012 15:41:47 -0800 (PST) Received: by dajz8 with SMTP id z8so15910011daj.31 for ; Tue, 03 Jan 2012 15:41:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.211.161 with SMTP id nd1mr16637339pbc.50.1325634107132; Tue, 03 Jan 2012 15:41:47 -0800 (PST) Received: by 10.68.10.234 with HTTP; Tue, 3 Jan 2012 15:41:47 -0800 (PST) In-Reply-To: <470A0DC9-FD87-4EE4-8F23-227D86AD2B54@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <31DFE5C9-2DE0-4A1B-A216-AE8F47E75109@gmail.com> <470A0DC9-FD87-4EE4-8F23-227D86AD2B54@gmail.com> Date: Tue, 3 Jan 2012 17:41:47 -0600 Message-ID: From: Nico Williams To: RJ Atkinson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 03 Jan 2012 23:41:49 -0000 On Mon, Jan 2, 2012 at 7:34 PM, RJ Atkinson wrote: > On 02 =C2=A0Jan 2012, at 20:06 , Nico Williams wrote: >> On Mon, Jan 2, 2012 at 6:45 PM, RJ Atkinson wrote: >> With tunnel mode you effectively repeat the options inside and outside >> the tunnel. > > One could repeat the headers; some implementations don't. > It doesn't help transit devices to repeat the headers > if they can't validate them before acting upon them. > >> Routers can't validate the integrity protection >> regardless of whether AH or ESP-NULL in tunnel mode is used, > > Disagree. =C2=A0Intermediate authentication can be performed > by routers/firewalls, at least when AH is used. =C2=A0The > router/firewall could then act on the options in the > packet having reasonable assurance that the option itself, > and its contents, were valid for that packet. OK, so you have networks using manually keyed SAs with routers/firewalls sharing the same SAs. I hadn't considered that as it isn't exactly scalable. But fair enough. >> but assuming that an attacker can only modify options at one place in th= e >> path then the recipient can see that options were modified. > > Unfortunately, it is not really a generally valid assumption > that there is only 1 potential attack point along a path. I elided the point that an attacker who can modify the packets close to the sender and recipient could hide any in-flight changes from the recipient. But if there are middle-boxes with access to the SAs' keys then that doesn't apply. >>> Sadly, at present there is still no 100% reliable >>> method for parsing past an ESP header with NULL encryption. >>> There are various documents describing methods which >>> have various success probabilities, but none that is >>> 100% reliable. >> >> Sure, this is necessarily true until any replacement for AH is >> universally deployed and that indicates that only integrity >> protection is provided. > > If some such mechanism exists, and if it provides 100% reliable > ability to parse-past/parse-into, and if it is plausibly efficient > to parse-into/parse-past in real-time for high-performance > switches/routers/firewalls, then this discussion might be > more useful than it is at present. =C2=A0That is rather a lot > of IFs, however, none of which seem true today. Fair enough. Nico -- From kohn.jack@gmail.com Tue Jan 3 19:02:53 2012 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 8118F11E8074 for ; Tue, 3 Jan 2012 19:02:53 -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 ekf76E0PfwLV for ; Tue, 3 Jan 2012 19:02:53 -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 7A10911E8075 for ; Tue, 3 Jan 2012 19:02:52 -0800 (PST) Received: by qcsf15 with SMTP id f15so12072869qcs.31 for ; Tue, 03 Jan 2012 19:02:52 -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; bh=rqGugn0pap8/L2b0DXdX1frcatkcng2CzRUACfHRl3U=; b=NYZwaBGVZijOPeNEyD1ebe9WakJdSf23ZUgTZ2B4ZWPtk+mVH3JRQcgpDXWuVlicDj vmYlgYUFBbAUdrWN55uCMODa1kir25hIiWpICq+Pcs23x+29EUw47vYjeeJnG4LwbjDE xUtaMfqokx2W2kBTGP31dnMk9jrK2G42MO9Vw= MIME-Version: 1.0 Received: by 10.229.77.133 with SMTP id g5mr19970778qck.39.1325646171998; Tue, 03 Jan 2012 19:02:51 -0800 (PST) Received: by 10.229.39.139 with HTTP; Tue, 3 Jan 2012 19:02:51 -0800 (PST) In-Reply-To: <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> Date: Wed, 4 Jan 2012 08:32:51 +0530 Message-ID: From: Jack Kohn To: RJ Atkinson Content-Type: text/plain; charset=ISO-8859-1 Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 04 Jan 2012 03:02:53 -0000 > Unfortunately, the IETF has long-standing challenges with > getting users/operators, especially enterprise/academic/ > government users, to participate in its WGs. The problem is not this. The problem is that a few loud people (in some occasions, just one) can filibuster good ideas over long held antiquated views on how technology is (or should be) used. In a few cases, its got little to do with the technology really .. Yours, Jack From nico@cryptonector.com Tue Jan 3 21:49:07 2012 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 C1BDA21F84E1 for ; Tue, 3 Jan 2012 21:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[AWL=0.056, 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 4hlUUBvhgo4M for ; Tue, 3 Jan 2012 21:49:07 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 304DD21F84DE for ; Tue, 3 Jan 2012 21:49:07 -0800 (PST) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 9CA4F318074 for ; Tue, 3 Jan 2012 21:49:06 -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; q=dns; s=cryptonector.com; b=x8PPecIaUMoZ9bqrRiTHW Ry5zTAPB/9l5g6chA6wMGqe6ZIL5xXmiUVO9/QlF5UkeUtJc6z2+ogOYl0APzpjY meeIIn94IFXhTV78DItK1CSgyqrNHdow2lnWlTFL8FXyk+Ldj37cWB7D0B8kIPSX B7jJsVUHkTLuz09hQVF190= 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; s=cryptonector.com; bh=Cnj5GPQDlR0LI8P4BncQ sK+tSpM=; b=h5IqljxfQxSOvRQtdA7O+DTNuJTqT9z/zcspGevCqPPW6StUQDJR BZuAHXLpP5xS2HzGyFN1Sb6uvzUveJnqWejdstAwc4DoWmcr2ct4dvbvccUwyY9G t1yMcLw0FUweWcdaOgJmnXSlDKFbY3RsPS+Z5n5VWKNXGY0kIgVGaiY= 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-a89.g.dreamhost.com (Postfix) with ESMTPSA id 82998318072 for ; Tue, 3 Jan 2012 21:49:06 -0800 (PST) Received: by dajz8 with SMTP id z8so16067891daj.31 for ; Tue, 03 Jan 2012 21:49:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.234 with SMTP id o10mr139589121pbv.90.1325656146131; Tue, 03 Jan 2012 21:49:06 -0800 (PST) Received: by 10.68.10.234 with HTTP; Tue, 3 Jan 2012 21:49:06 -0800 (PST) In-Reply-To: References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> Date: Tue, 3 Jan 2012 23:49:06 -0600 Message-ID: From: Nico Williams To: Jack Kohn Content-Type: text/plain; charset=UTF-8 Cc: IPsec ME WG List , RJ Atkinson Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 04 Jan 2012 05:49:07 -0000 On Tue, Jan 3, 2012 at 9:02 PM, Jack Kohn wrote: >> Unfortunately, the IETF has long-standing challenges with >> getting users/operators, especially enterprise/academic/ >> government users, to participate in its WGs. > > The problem is not this. > > The problem is that a few loud people (in some occasions, just one) > can filibuster good ideas over long held antiquated views on how > technology is (or should be) used. In a few cases, its got little to > do with the technology really .. Advising (and updating said advice as circumstances change) use-IPsec protocol designers as to when to use ESP and/or AH is something we should do. Deprecating AH seems like a nice idea, but if there's good reasons to still use it, then maybe not. In 2012 the use of manually keyed unicast SAs with group shared keys is not exactly impressive (because not scalable). We could reach consensus to ignore such usage of IPsec. Or not -- hardly a big deal if not, eh? Nico -- From manav.bhatia@alcatel-lucent.com Tue Jan 3 22:08:13 2012 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 AD8CB21F85C2 for ; Tue, 3 Jan 2012 22:08:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 SnrMWRIJIzsH for ; Tue, 3 Jan 2012 22:08:13 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2558021F85C1 for ; Tue, 3 Jan 2012 22:08:12 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q04685L0013857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Jan 2012 00:08:10 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q04684sP028998 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Jan 2012 11:38:05 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 4 Jan 2012 11:38:04 +0530 From: "Bhatia, Manav (Manav)" To: Nico Williams Date: Wed, 4 Jan 2012 11:35:52 +0530 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) Thread-Index: AczKpJrI51v2UZYuTIuT8OUzW12u1gAABK9Q Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A2953@INBANSXCHMBSA1.in.alcatel-lucent.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-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 04 Jan 2012 06:08:13 -0000 Hi Nico, =20 > Advising (and updating said advice as circumstances change)=20 > use-IPsec protocol designers as to when to use ESP and/or AH=20 > is something we should do. Deprecating AH seems like a nice=20 > idea, but if there's good reasons to still use it, then maybe not. We're not talking about deprecating or killing AH. I concede that I did all= ude to it in my first draft, but then changed the tone based on the WG feed= back, to say that we should "avoid" AH wherever possible. What we're trying to say is this: 1. If folks have a reason to use AH then they're most welcome to use it.=20 2. If there are topologies where it makes only sense to use AH then do that= . Ran pointed out to some very specific cases where it apparently makes sen= se to use AH and I have no problems with people using AH there. In the view= of most people there isn't a need for AH in the service provider network a= nd I am fine with a few people disagreeing with me.=20 3. If there are newer protocols that cant use ESP-NULL for some reason and = need to extend AH, then they should do that. All we're saying is that those= folks should not arbitrarily extend AH. They should have a good reason for= doing so. In short, if ESP-NULL can do the job, then DON'T mandate AH - no point havi= ng multiple protocols doing the same stuff. If it cant, then either (i) fix= ESP or (ii) go ahead and use AH. Pick up whichever is more elegant and pre= ferred by the community. I think that's all that we're trying to say here. Cheers, Manav From rja.lists@gmail.com Wed Jan 4 03:39:43 2012 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 AAE4E21F8735 for ; Wed, 4 Jan 2012 03:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.64 X-Spam-Level: X-Spam-Status: No, score=-3.64 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 gDHpRwEQu63M for ; Wed, 4 Jan 2012 03:39:43 -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 13D9521F8733 for ; Wed, 4 Jan 2012 03:39:43 -0800 (PST) Received: by qcsf15 with SMTP id f15so12272567qcs.31 for ; Wed, 04 Jan 2012 03:39:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=N0JtrdDInxNX1cJtVXDzKanHFpJ5FYCuP/YdJPNqzeI=; b=jhNHSrrKyMW62s5i4CUEv63W3DZRzT4VoeUB0HJzr0bq8oQkadhEHu3gMR9TpJsbIX tBAeoBuQQCNKbbooe4Fnd51AzyhVjH3tpb77iRaaGLNJtqZTIR3R2sTAzw5GvyBtBPvl XwlikN8vUgi6+1PI+etXQM5WV/BX6OOfFnX4g= Received: by 10.224.102.2 with SMTP id e2mr65876175qao.31.1325677182650; Wed, 04 Jan 2012 03:39:42 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id r10sm106288780qaz.7.2012.01.04.03.39.41 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 03:39:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: RJ Atkinson In-Reply-To: Date: Wed, 4 Jan 2012 06:39:43 -0500 Content-Transfer-Encoding: 7bit Message-Id: <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 04 Jan 2012 11:39:43 -0000 On 04 Jan 2012, at 00:49 , Nico Williams wrote: > Advising (and updating said advice as circumstances change) > use-IPsec protocol designers as to when to use ESP and/or > AH is something we should do. This has already been done. More than once. For a start, the latest IPsec RFCs contain advice. There are also other RFCs with such advice, including a relatively recent BCP on use of IPsec. There is no evidence of any recent change either to the operational circumstances or to the available alternatives. So no update is appropriate at this time. > Deprecating AH seems like a nice idea, but if there's good > reasons to still use it, then maybe not. There are deployments now and have been deployments all along -- and those deployments don't have any alternatives to AH. > In 2012 the use of manually keyed unicast SAs with > group shared keys is not exactly impressive (because not scalable). Actually, that assumption is not valid. There are multiple approaches to scalability available now. An obvious example is to use a KDC to distribute keys. Another example is to use existing provisioning systems to provision keys. ISPs have a wide range of provisioning systems, often locally developed. Enterprise users vary -- larger enterprises often have provisioning systems; smaller enterprise users less often (although their scale is also smaller). Many enterprise equipment vendors offer centralised management platforms that include provisioning capability, often multi-vendor provisioning capability. There is also a standards-based approach to configuration/provisioning -- using NetConf. There are even approaches that use RADIUS to distribute wrapped keys. Yours, Ran From manav.bhatia@alcatel-lucent.com Wed Jan 4 06:12:32 2012 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 6CF8C21F866D for ; Wed, 4 Jan 2012 06:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Jf5rNdVBQFYW for ; Wed, 4 Jan 2012 06:12:31 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id BBE8B21F84FF for ; Wed, 4 Jan 2012 06:12:31 -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 q04ECReB016168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 4 Jan 2012 08:12:29 -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 q04ECQg0023124 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 4 Jan 2012 19:42:27 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Wed, 4 Jan 2012 19:42:26 +0530 From: "Bhatia, Manav (Manav)" To: IPsecme WG Date: Wed, 4 Jan 2012 19:42:24 +0530 Thread-Topic: NIST's Guidelines for secure deployment of IPv6 Thread-Index: AczK6uF/sV4X1s36QyGLlmSov1Rk8A== Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A2AE1@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.39 Subject: [IPsec] NIST's Guidelines for secure deployment of IPv6 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, 04 Jan 2012 14:12:32 -0000 NIST has published the "Guidelines for secure deployment of IPv6" and it un= equivocally says that AH has fallen out for ESP-NULL. One can go through the document in detail. I have not gone through the enti= re document but here are some excerpts from that document: (1) It says the following for OSPFv3: "With routing protocols, routing integrity is usually a greater concern tha= n confidentiality. The ESP=20 parameter NULL indicating no encryption is generally regarded to be an acce= ptable choice for OSPF=20 security." (2) 4.2.4 Unresolved Aspects of IPv6 Multicast "The security recommendations for PIM call for using IPsec AH, even for uni= cast messages. Where IPsec=20 is used with IPv4, AH has generally fallen out of use in favor of ESP, with= NULL encryption when=20 authentication-only is desired. Thus the IPsec standard (RFC 4301) no long= er requires AH, and many=20 implementations omit it. See Section 5.3.6 for additional discussion of thi= s topic." (3) 5.3.1 Specification Overview "Two security protocols: Authentication Header (AH) and Encapsulating Secur= ity=20 Payload (ESP). AH can provide integrity and replay protection for packet h= eaders and data,=20 but it cannot encrypt them. ESP can provide encryption, integrity, and rep= lay protection for=20 packets, but it cannot protect the outermost IP header, as AH can. This pr= otection is not=20 needed in most cases. Accordingly, ESP is used much more frequently than A= H because of its=20 encryption capabilities, as well as other operational advantages. The late= st IPsec specification=20 states that implementations MAY implement AH, and many choose not to. For = a VPN, which=20 requires confidential communications, ESP is the natural choice." And the below is the most interesting: (4) 5.3.6 Unknown Aspects "A debate exists over whether to use AH or ESP with NULL encryption for IPs= ec packets requiring integrity protection but not confidentiality. The standards themselves do = not answer the question: IPv6=20 standards tend to recommend or require AH, whereas IPsec standards have dow= ngraded AH from MUST=20 implement to MAY implement. OSPFv3 originally specified AH, but this has b= een changed to ESPNULL. =20 Some implementations only provide ESP. AH has not been widely deployed. (= The common=20 IPv4 applications of IPsec-VPNs and secure remote access-usually provide co= nfidentiality, so this=20 question does not arise.) AH may also require more processing steps to com= pute or verify the integrity=20 check value. On the other hand, one of the main arguments in favor of AH i= s that it makes it easier for=20 devices such as packet filtering routers, firewalls, and intrusion detectio= n systems to recognize plaintext=20 and examine packets (because ESP-NULL transmits plaintext but gives no visi= ble indication that the=20 payload is unencrypted). As far as the cryptographic protection provided b= y AH versus ESP, it is difficult=20 to discern any tangible difference when IPsec is used as intended. In some= cases, AH may protect certain=20 vulnerable parts of the header or extension headers, but these cases are ra= re, and in these few cases,=20 ESPNULL can achieve the same effect by being run in tunnel mode." (5) 5.4.1 Using IPsec to Secure Autoconfiguration and ND "AH was downgraded to MAY in RFC 4301 and is not included in many implement= ations." Cheers, Manav = From mcr@sandelman.ca Wed Jan 4 06:16:06 2012 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 AE8CD21F8718 for ; Wed, 4 Jan 2012 06:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[AWL=0.603, 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 EDtsr-zQ+MGK for ; Wed, 4 Jan 2012 06:16:06 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 20D0021F86D1 for ; Wed, 4 Jan 2012 06:16:05 -0800 (PST) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 6A4CC34465; Wed, 4 Jan 2012 09:14:09 -0500 (EST) Received: by marajade.sandelman.ca (Postfix, from userid 179) id 4C68C98147; Wed, 4 Jan 2012 09:16:02 -0500 (EST) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 4882C9812A; Wed, 4 Jan 2012 09:16:02 -0500 (EST) From: Michael Richardson To: "Bhatia, Manav (Manav)" In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D028A2953@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D028A2953@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Wed, 04 Jan 2012 09:16:02 -0500 Message-ID: <6442.1325686562@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "ipsec@ietf.org" , Nico Williams Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 04 Jan 2012 14:16:06 -0000 >>>>> "Manav" == Manav Bhatia writes: Manav> Hi Nico, >> Advising (and updating said advice as circumstances change) >> use-IPsec protocol designers as to when to use ESP and/or AH is >> something we should do. Deprecating AH seems like a nice idea, >> but if there's good reasons to still use it, then maybe not. Manav> We're not talking about deprecating or killing AH. I concede Manav> that I did allude to it in my first draft, but then changed Manav> the tone based on the WG feedback, to say that we should Manav> "avoid" AH wherever possible. This is the status quo already. Why do we need this draft? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From manav.bhatia@alcatel-lucent.com Wed Jan 4 06:18:19 2012 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 7233E21F8756 for ; Wed, 4 Jan 2012 06:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 dTXTOekdWhWP for ; Wed, 4 Jan 2012 06:18:18 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9772421F8750 for ; Wed, 4 Jan 2012 06:18:18 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q04EIBSs021132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Jan 2012 08:18:14 -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 q04EIBN0002099 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Jan 2012 19:48:11 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 4 Jan 2012 19:48:11 +0530 From: "Bhatia, Manav (Manav)" To: RJ Atkinson , IPsec ME WG List Date: Wed, 4 Jan 2012 19:48:10 +0530 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) Thread-Index: AczK1Zp2mLmR5HBhQKijbz5EkDABNQAEYk7w Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> In-Reply-To: <48CB2A9F-D59C-462F-8C7A-82127A217703@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 04 Jan 2012 14:18:19 -0000 =20 > There is no evidence of any recent change either to the operational=20 > circumstances or to the available alternatives. So no update is appropri= ate at this time. One major recent change is the publication of WESP [RFC 5840] and the stand= ard for using Heuristics for detecting ESP-NULL packets [RFC 5879].=20 This takes away one major reason why folks wanted to use AH - that of being= able to deep inspect packets. Even the NIST guidelines for IPv6 deployment says that the main argument in= favor of AH is the ability to inspect packets. With WESP even that goes aw= ay. BTW, the Advanced Network Technologies Division of NIST has started work on= supporting the WESP header and ESP-NULL detection. http://dns.antd.nist.gov/ipv6/ Cheers, Manav From manav.bhatia@alcatel-lucent.com Wed Jan 4 06:22:20 2012 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 19F1C21F855B for ; Wed, 4 Jan 2012 06:22:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.576 X-Spam-Level: X-Spam-Status: No, score=-6.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 c1GgSdQLhjxy for ; Wed, 4 Jan 2012 06:22:19 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDB721F8558 for ; Wed, 4 Jan 2012 06:22:18 -0800 (PST) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q04EMEiK003761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Jan 2012 08:22:16 -0600 (CST) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q04EMDaV023500 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 4 Jan 2012 19:52:13 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Wed, 4 Jan 2012 19:52:13 +0530 From: "Bhatia, Manav (Manav)" To: "mcr@sandelman.ca" Date: Wed, 4 Jan 2012 19:52:12 +0530 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) Thread-Index: AczK62s0rxNA02jcTC6CzLY1/sihQQAAFiNw Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A2AE5@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D028A2953@INBANSXCHMBSA1.in.alcatel-lucent.com> <6442.1325686562@marajade.sandelman.ca> In-Reply-To: <6442.1325686562@marajade.sandelman.ca> 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 Cc: "ipsec@ietf.org" , Nico Williams Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 04 Jan 2012 14:22:20 -0000 Hi Marc, We don't say that. 4301 says that implementations MAY support AH and MUST s= upport ESP. This creates a problem for implementations if in future a new application o= r a protocol mandates the use of AH.=20 I will even go a step further and say that newer protocols should just assu= me ESP-NULL and not even bother with AH if they can do with just ESP. Cheers, Manav -----Original Message----- From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]=20 Sent: Wednesday, January 04, 2012 7:46 PM To: Bhatia, Manav (Manav) Cc: Nico Williams; ipsec@ietf.org Subject: Re: [IPsec] Avoiding Authentication Header (AH) >>>>> "Manav" =3D=3D Manav Bhatia writes: Manav> Hi Nico, =20 >> Advising (and updating said advice as circumstances change) >> use-IPsec protocol designers as to when to use ESP and/or AH is >> something we should do. Deprecating AH seems like a nice idea, >> but if there's good reasons to still use it, then maybe not. Manav> We're not talking about deprecating or killing AH. I concede Manav> that I did allude to it in my first draft, but then changed Manav> the tone based on the WG feedback, to say that we should Manav> "avoid" AH wherever possible. This is the status quo already. Why do we need this draft? --=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 From vnktshsriram@gmail.com Wed Jan 4 07:42:12 2012 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 95AE821F871B for ; Wed, 4 Jan 2012 07:42:12 -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 5VVO5CXARnCB for ; Wed, 4 Jan 2012 07:42:11 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5ED521F870A for ; Wed, 4 Jan 2012 07:42:11 -0800 (PST) Received: by dajz8 with SMTP id z8so16409599daj.31 for ; Wed, 04 Jan 2012 07:42:11 -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=iworwdoyVu5YcyuI57p6adzqVfdD0A4gRzBinUjTOt4=; b=G6KSBziMLRjiaV1kA9lILG3UleKcqI50B0bsnIFDfZNnIOfItC7gAh85/sh74/RZtZ M5PVc3z0pSSQ4kHpejqwi7Q+/r9OUgbQJj2cbO93p2E3c7ItnbLD06l8zGkwIjhLlh1w zK9LZ+Yo6czwaxeWiDhl1mszfnY6+dj5HnooY= MIME-Version: 1.0 Received: by 10.68.72.6 with SMTP id z6mr145000928pbu.73.1325691729660; Wed, 04 Jan 2012 07:42:09 -0800 (PST) Received: by 10.68.17.193 with HTTP; Wed, 4 Jan 2012 07:42:09 -0800 (PST) In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D028A2AE1@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D028A2AE1@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 4 Jan 2012 21:12:09 +0530 Message-ID: From: Venkatesh Sriram To: "Bhatia, Manav (Manav)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPsecme WG Subject: Re: [IPsec] NIST's Guidelines for secure deployment of IPv6 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, 04 Jan 2012 15:42:12 -0000 Another document from NIST - Profile for IPv6 in the US Government [1], lists AH as optional and ESP as mandatory. It however says that if devices want to differentiate ESP NULL with ESP encrypted traffic then they must use AH till the IPSecME WG comes up with a mature standard that can easily do this. It says that if it produces a mature RFC then the profile will be updated to recommend its use. The version i have with me was published prior to WESP's publication. http://www.antd.nist.gov/usgv6/usgv6-v1.pdf Sriram [1] This document is meant to assist Federal agencies in formulating plans for the acquisition of IPv6 technologies. On Wed, Jan 4, 2012 at 7:42 PM, Bhatia, Manav (Manav) wrote: > NIST has published the "Guidelines for secure deployment of IPv6" and it = unequivocally says that AH has fallen out for ESP-NULL. > > One can go through the document in detail. I have not gone through the en= tire document but here are some excerpts from that document: > > (1) It says the following for OSPFv3: > > "With routing protocols, routing integrity is usually a greater concern t= han confidentiality. The ESP > parameter NULL indicating no encryption is generally regarded to be an ac= ceptable choice for OSPF > security." > > (2) 4.2.4 Unresolved Aspects of IPv6 Multicast > > "The security recommendations for PIM call for using IPsec AH, even for u= nicast messages. =A0Where IPsec > is used with IPv4, AH has generally fallen out of use in favor of ESP, wi= th NULL encryption when > authentication-only is desired. =A0Thus the IPsec standard (RFC 4301) no = longer requires AH, and many > implementations omit it. See Section 5.3.6 for additional discussion of t= his topic." > > (3) 5.3.1 Specification Overview > > "Two security protocols: Authentication Header (AH) and Encapsulating Sec= urity > Payload (ESP). =A0AH can provide integrity and replay protection for pack= et headers and data, > but it cannot encrypt them. =A0ESP can provide encryption, integrity, and= replay protection for > packets, but it cannot protect the outermost IP header, as AH can. =A0Thi= s protection is not > needed in most cases. =A0Accordingly, ESP is used much more frequently th= an AH because of its > encryption capabilities, as well as other operational advantages. =A0The = latest IPsec specification > states that implementations MAY implement AH, and many choose not to. =A0= For a VPN, which > requires confidential communications, ESP is the natural choice." > > And the below is the most interesting: > > (4) 5.3.6 Unknown Aspects > > "A debate exists over whether to use AH or ESP with NULL encryption for I= Psec packets requiring > integrity protection but not confidentiality. =A0The standards themselves= do not answer the question: IPv6 > standards tend to recommend or require AH, whereas IPsec standards have d= owngraded AH from MUST > implement to MAY implement. =A0OSPFv3 originally specified AH, but this h= as been changed to ESPNULL. > Some implementations only provide ESP. =A0AH has not been widely deployed= . =A0(The common > IPv4 applications of IPsec-VPNs and secure remote access-usually provide = confidentiality, so this > question does not arise.) =A0AH may also require more processing steps to= compute or verify the integrity > check value. =A0On the other hand, one of the main arguments in favor of = AH is that it makes it easier for > devices such as packet filtering routers, firewalls, and intrusion detect= ion systems to recognize plaintext > and examine packets (because ESP-NULL transmits plaintext but gives no vi= sible indication that the > payload is unencrypted). =A0As far as the cryptographic protection provid= ed by AH versus ESP, it is difficult > to discern any tangible difference when IPsec is used as intended. =A0In = some cases, AH may protect certain > vulnerable parts of the header or extension headers, but these cases are = rare, and in these few cases, > ESPNULL can achieve the same effect by being run in tunnel mode." > > (5) 5.4.1 Using IPsec to Secure Autoconfiguration and ND > > "AH was downgraded to MAY in RFC 4301 and is not included in many impleme= ntations." > > Cheers, Manav > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From rja.lists@gmail.com Wed Jan 4 10:37:28 2012 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 3E10D11E8083 for ; Wed, 4 Jan 2012 10:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.632 X-Spam-Level: X-Spam-Status: No, score=-3.632 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 u+kAoz2nH+V6 for ; Wed, 4 Jan 2012 10:37:27 -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 9C18F11E8081 for ; Wed, 4 Jan 2012 10:37:22 -0800 (PST) Received: by qcsf15 with SMTP id f15so12570583qcs.31 for ; Wed, 04 Jan 2012 10:37:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=UNzEByKMNHS5lUND0VRaS8NAAfKOQHcgksz8n6p/Wgk=; b=i8w5zB9GrPtVGC+78Mz3WKRFiKOM84OqXZKDhh9QnYwbL5L4b2nMT90kjT5et+itvk jou6Wt/bJGIxFkcL6JProwQEvIQJXyZpkrJM538nv0FyO0ZC6hSkvS8lV6PPrXEJXVQb dp4DBnXFOM1T/EwJipL1KV5r1/yHe5zUpNZFw= Received: by 10.224.60.20 with SMTP id n20mr53078495qah.14.1325702241012; Wed, 04 Jan 2012 10:37:21 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id m20sm108767886qaj.14.2012.01.04.10.37.19 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 10:37:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: RJ Atkinson In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> Date: Wed, 4 Jan 2012 13:37:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5C745AC3-FA25-42BE-9848-DDEA3078A1FF@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 04 Jan 2012 18:37:28 -0000 On 04 Jan 2012, at 09:18 , Bhatia, Manav (Manav) wrote: >> There is no evidence of any recent change either to the operational=20= >> circumstances or to the available alternatives. So no update >> is appropriate at this time. >=20 > One major recent change is the publication of WESP [RFC 5840] > and the standard for using Heuristics for detecting ESP-NULL packets > [RFC 5879].=20 >=20 > This takes away one major reason why folks wanted to use AH - > that of being able to deep inspect packets. Unfortunately, that is wishful thinking, rather than reality. Neither WESP nor the other document provide a 100% reliable way=20 to parse-into/parse-past/deep-inspect ESP packets. One might=20 wish otherwise, but the reality is that there is no 100% reliable method today. Separately, as I've noted before, that isn't the only reason that folks use AH today in real-world deployments. =20 > Even the NIST guidelines for IPv6 deployment says that the main = argument in favor of AH is the ability to inspect packets. With WESP = even that goes away. Since WESP is not 100% reliable, WESP does not affect that reason to retain AH. Yours, Ran From paul.hoffman@vpnc.org Wed Jan 4 10:46:38 2012 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 61D8421F8786 for ; Wed, 4 Jan 2012 10:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 KfbzQNkTxwyb for ; Wed, 4 Jan 2012 10:46:38 -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 CE04A21F877A for ; Wed, 4 Jan 2012 10:46:37 -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 q04IkZgs033708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jan 2012 11:46:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <5C745AC3-FA25-42BE-9848-DDEA3078A1FF@gmail.com> Date: Wed, 4 Jan 2012 10:46:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <493ECD00-71C7-4471-9B33-9F7F903ECB14@vpnc.org> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <5C745AC3-FA25-42BE-9848-DDEA3078A1FF@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1251.1) Cc: IPsec ME WG List Subject: [IPsec] WESP and reliability 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, 04 Jan 2012 18:46:38 -0000 On Jan 4, 2012, at 10:37 AM, RJ Atkinson wrote: > Neither WESP nor the other document provide a 100% reliable way=20 > to parse-into/parse-past/deep-inspect ESP packets. One might=20 > wish otherwise, but the reality is that there is no 100% > reliable method today. Can you give an example where WESP (a protocol that was done in this WG) = is not 100% reliable for parse-into or parse-past? If we need to change = the protocol, we should. --Paul Hoffman From rja.lists@gmail.com Wed Jan 4 10:59:14 2012 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 0B97A21F855B for ; Wed, 4 Jan 2012 10:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.629 X-Spam-Level: X-Spam-Status: No, score=-3.629 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 GspJ66+qvtJv for ; Wed, 4 Jan 2012 10:59:13 -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 79BE821F8558 for ; Wed, 4 Jan 2012 10:59:13 -0800 (PST) Received: by qcsf15 with SMTP id f15so12586128qcs.31 for ; Wed, 04 Jan 2012 10:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=rvEpAnRl6j7lxoFhSIR962GpSIim+a3G24H2/AEqKcA=; b=VWlJNwwd3CuppPBxvdQKwZUKNoSCJvK5lm5h8yuikmZBuCKr0BpPzhCZFgMakrOSa1 7eFR3oEL+RtzGF99UJnzTIeOrS0Dz4fTM8uhmU5BAITEp+NPAplf+mPUO3WYLOtIDyCG W7nLrkg69KtMg4cM3ZikMw4/KrTi1Wa0TvcEE= Received: by 10.229.75.149 with SMTP id y21mr21302341qcj.69.1325703552952; Wed, 04 Jan 2012 10:59:12 -0800 (PST) Received: from [10.30.20.12] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id dh10sm108916046qab.19.2012.01.04.10.59.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 04 Jan 2012 10:59:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: RJ Atkinson In-Reply-To: <493ECD00-71C7-4471-9B33-9F7F903ECB14@vpnc.org> Date: Wed, 4 Jan 2012 13:59:11 -0500 Content-Transfer-Encoding: 7bit Message-Id: <541DCEA7-C5A6-42C6-A1CB-DCF91677FB08@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <5C745AC3-FA25-42BE-9848-DDEA3078A1FF@gmail.com> <493ECD00-71C7-4471-9B33-9F7F903ECB14@vpnc.org> To: IPsec ME WG List X-Mailer: Apple Mail (2.1251.1) Subject: Re: [IPsec] WESP and reliability 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, 04 Jan 2012 18:59:14 -0000 On 04 Jan 2012, at 13:46 , Paul Hoffman wrote: > On Jan 4, 2012, at 10:37 AM, RJ Atkinson wrote: >> Neither WESP nor the other document provide a 100% reliable way >> to parse-into/parse-past/deep-inspect ESP packets. One might >> wish otherwise, but the reality is that there is no 100% >> reliable method today. > > Can you give an example where WESP (a protocol that was > done in this WG) is not 100% reliable for parse-into > or parse-past? If we need to change the protocol, we should. Such packets have been encountered by prototype implementations in at least one firewall. I will certainly encourage those folks to share a sample packet here, but they don't usually show up at IETF and can be very shy. I think WESP was a valiant try, and it seems to work most of the time. It is just sad that the result just doesn't work in all cases. An entirely separate issue is that WESP is not generally available yet. One hopes that WESP support will become available soon, but that's not generally true now. Yours, Ran From paul.hoffman@vpnc.org Wed Jan 4 11:27:34 2012 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 CE43021F86DA for ; Wed, 4 Jan 2012 11:27:34 -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 gAGJ393MU8wA for ; Wed, 4 Jan 2012 11:27:34 -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 478EE21F8694 for ; Wed, 4 Jan 2012 11:27:34 -0800 (PST) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q04JRUCj035258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 4 Jan 2012 12:27:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <541DCEA7-C5A6-42C6-A1CB-DCF91677FB08@gmail.com> Date: Wed, 4 Jan 2012 11:27:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9BC8538C-618E-4EFE-940B-AB117DCAB8BB@vpnc.org> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <5C745AC3-FA25-42BE-9848-DDEA3078A1FF@gmail.com> <493ECD00-71C7-4471-9B33-9F7F903ECB14@vpnc.org> <541DCEA7-C5A6-42C6-A1CB-DCF91677FB08@gmail.com> To: RJ Atkinson X-Mailer: Apple Mail (2.1251.1) Cc: IPsec ME WG List Subject: Re: [IPsec] WESP and reliability 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, 04 Jan 2012 19:27:34 -0000 On Jan 4, 2012, at 10:59 AM, RJ Atkinson wrote: >=20 > On 04 Jan 2012, at 13:46 , Paul Hoffman wrote: >=20 >> On Jan 4, 2012, at 10:37 AM, RJ Atkinson wrote: >>> Neither WESP nor the other document provide a 100% reliable way=20 >>> to parse-into/parse-past/deep-inspect ESP packets. One might=20 >>> wish otherwise, but the reality is that there is no 100% >>> reliable method today. >>=20 >> Can you give an example where WESP (a protocol that was >> done in this WG) is not 100% reliable for parse-into >> or parse-past? If we need to change the protocol, we should. >=20 > Such packets have been encountered by prototype=20 > implementations in at least one firewall. I will > certainly encourage those folks to share a sample > packet here, but they don't usually show up at IETF > and can be very shy. Really? That's it? > I think WESP was a valiant try, and it seems to work > most of the time. It is just sad that the result=20 > just doesn't work in all cases. =20 You still haven't justified that statement, at least in my mind. I = welcome any of the shy people to speak up, even through a proxy such as = Ran. > An entirely separate issue is that WESP is not generally > available yet. One hopes that WESP support will become > available soon, but that's not generally true now. That is not an issue for this thread. --Paul Hoffman From yaronf.ietf@gmail.com Wed Jan 4 11:58:57 2012 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 7590711E8088 for ; Wed, 4 Jan 2012 11:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.373 X-Spam-Level: X-Spam-Status: No, score=-103.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 IAb-YbA6zuKd for ; Wed, 4 Jan 2012 11:58:56 -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 518E311E8079 for ; Wed, 4 Jan 2012 11:58:56 -0800 (PST) Received: by eekc14 with SMTP id c14so15830019eek.31 for ; Wed, 04 Jan 2012 11:58:55 -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=NC90Ul+7veiFdQotqXPSuhx0bn3gsZrWIkNM9geXE1Q=; b=NtdKK8QVvDdig5+vb85ZmrMavKptMzpkkSZesi+HZ0VvANGHRKCLXtUX+wy6IAf3S5 g9zZJVkw5cqiXf+cFPJtmsF012GgvcibzRTIUUiYGa8Km+wtXcDzNJKWaMRKMA0wAo/E xUVMCZOubR2vMclsgJJkp/5XUDFO/1d37v5X0= Received: by 10.14.11.142 with SMTP id 14mr24235148eex.9.1325707135320; Wed, 04 Jan 2012 11:58:55 -0800 (PST) Received: from [10.0.0.6] ([109.67.155.85]) by mx.google.com with ESMTPS id q67sm161914984eea.8.2012.01.04.11.58.53 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 11:58:54 -0800 (PST) Message-ID: <4F04AF7B.1010005@gmail.com> Date: Wed, 04 Jan 2012 21:58:51 +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: RJ Atkinson References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <5C745AC3-FA25-42BE-9848-DDEA3078A1FF@gmail.com> <493ECD00-71C7-4471-9B33-9F7F903ECB14@vpnc.org> <541DCEA7-C5A6-42C6-A1CB-DCF91677FB08@gmail.com> In-Reply-To: <541DCEA7-C5A6-42C6-A1CB-DCF91677FB08@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsec ME WG List Subject: Re: [IPsec] WESP and reliability 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, 04 Jan 2012 19:58:57 -0000 Hi Ran, I find the situation quite amusing, with fleeting little packets, timid engineers, and valiant standards people playing in this drama. But seriously, could it be that you're confusing the (AFAIK) fully deterministic WESP (RFC 5840) with the non-deterministic heuristic method (RFC 5879)? Or else is there anything missing in WESP that we should pay attention to, for example, maybe it doesn't support specific IV or ICV sizes that those non IETF-goers are using? Thanks, Yaron On 01/04/2012 08:59 PM, RJ Atkinson wrote: > On 04 Jan 2012, at 13:46 , Paul Hoffman wrote: > >> On Jan 4, 2012, at 10:37 AM, RJ Atkinson wrote: >>> Neither WESP nor the other document provide a 100% reliable way >>> to parse-into/parse-past/deep-inspect ESP packets. One might >>> wish otherwise, but the reality is that there is no 100% >>> reliable method today. >> Can you give an example where WESP (a protocol that was >> done in this WG) is not 100% reliable for parse-into >> or parse-past? If we need to change the protocol, we should. > Such packets have been encountered by prototype > implementations in at least one firewall. I will > certainly encourage those folks to share a sample > packet here, but they don't usually show up at IETF > and can be very shy. > > I think WESP was a valiant try, and it seems to work > most of the time. It is just sad that the result > just doesn't work in all cases. > > An entirely separate issue is that WESP is not generally > available yet. One hopes that WESP support will become > available soon, but that's not generally true now. > > Yours, > > Ran > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nico@cryptonector.com Wed Jan 4 12:13:30 2012 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 2165311E8088 for ; Wed, 4 Jan 2012 12:13:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.052, 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 VLGGphisVQTa for ; Wed, 4 Jan 2012 12:13:29 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 7881A11E8079 for ; Wed, 4 Jan 2012 12:13:29 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 435F36B0078 for ; Wed, 4 Jan 2012 12:13:29 -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=EAtVPT6Dd18p5Yv62TOXTAXE4Lly1kJVbEGsHra/C/c8 Sv6gPRV4wT0zkfXcFg4t/YnYh5W5rz32mYIU0DmyNVkWXR3DnxTvraAEICv+LKpB 56WuD+iKtpSb4Ipq/ZFr869FchLc+iJJTS3/u2q2XT41UAe4M1CJ5ZkLoypYhGc= 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=mZvXdmgXD6z+tMRviJ/aQifVtVE=; b=eudTZjrNqOC NMOUKwGK3pUGwa+rsFcbj4ZA4zq2hyGrAVUvHDvv9hQ8pjUgvWt6dflbBeH8/kcI 41pKeY6QzVGrTMQufTfypoDDQvDEI/3QEVVQ0rR3LMLNA4I95U88sl6Bbbc4BLSp SoeATs4xDCbsjGvI5sVUzH8d5kijGQEU= 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-a72.g.dreamhost.com (Postfix) with ESMTPSA id 2956D6B0014 for ; Wed, 4 Jan 2012 12:13:29 -0800 (PST) Received: by dajz8 with SMTP id z8so16582794daj.31 for ; Wed, 04 Jan 2012 12:13:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.234 with SMTP id o10mr145601818pbv.90.1325708008778; Wed, 04 Jan 2012 12:13:28 -0800 (PST) Received: by 10.68.10.234 with HTTP; Wed, 4 Jan 2012 12:13:28 -0800 (PST) In-Reply-To: <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> Date: Wed, 4 Jan 2012 14:13:28 -0600 Message-ID: From: Nico Williams To: RJ Atkinson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 04 Jan 2012 20:13:30 -0000 On Wed, Jan 4, 2012 at 5:39 AM, RJ Atkinson wrote: > On 04 =C2=A0Jan 2012, at 00:49 , Nico Williams wrote: >> In 2012 the use of manually keyed unicast SAs with >> group shared keys is not exactly impressive (because not scalable). > > Actually, that assumption is not valid. =C2=A0There are > multiple approaches to scalability available now. > > An obvious example is to use a KDC to distribute keys. Out of curiosity, does such a protocol for keying SAs at end-points and sharing the keys with routers/firewalls exist, and is it implemented in any routers/firewalls? Also, whether using an out-of-band provisioning system or a KDC, you still have the problem that you need O(N^2) SAs to be pre-keyed (or, if keyed dynamically, the middle-boxes need to be able to go fetch keys dynamically unless they are the KDCs). I can imagine a system with static-static DH key exchange, with trusted middle-boxes knowing the private DH keys. A system with symmetric keying only would be severely limited by the O(N^2) SA keying requirement, and would be limited in applicability to VPN (including BITW) applications and small end-to-end applications. Nico -- From manav.bhatia@alcatel-lucent.com Wed Jan 4 14:42:01 2012 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 5A32C11E80E9 for ; Wed, 4 Jan 2012 14:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 JjD0aCuEouei for ; Wed, 4 Jan 2012 14:42:00 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id BC90E11E80E8 for ; Wed, 4 Jan 2012 14:42:00 -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 q04MfrUR028690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Jan 2012 16:41:56 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q04MfqcU005862 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Jan 2012 04:11:52 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Thu, 5 Jan 2012 04:11:52 +0530 From: "Bhatia, Manav (Manav)" To: RJ Atkinson , IPsec ME WG List Date: Thu, 5 Jan 2012 04:11:18 +0530 Thread-Topic: [IPsec] WESP and reliability Thread-Index: AczLEvjxPqJwNz2jTvKLTIW7mig3oQAHqjXg Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A2B25@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <5C745AC3-FA25-42BE-9848-DDEA3078A1FF@gmail.com> <493ECD00-71C7-4471-9B33-9F7F903ECB14@vpnc.org> <541DCEA7-C5A6-42C6-A1CB-DCF91677FB08@gmail.com> In-Reply-To: <541DCEA7-C5A6-42C6-A1CB-DCF91677FB08@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [IPsec] WESP and reliability 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, 04 Jan 2012 22:42:01 -0000 Ran,=20 > Such packets have been encountered by prototype implementations in at lea= st one firewall. =20 > I will certainly encourage those folks to share a sample packet here, but= they don't=20 > usually show up at IETF and can be very shy. > > I think WESP was a valiant try, and it seems to work most of the time. =20 > It is just sad that the result just doesn't work in all cases. =20 As a co-author of WESP I can tell you that the design was whetted by severa= l HW teams and it works *all* the time. The design was reviewed and approve= d by major silicon vendors and fortunately for you I am not speaking for a = few shy people who refuse to be recognized, but some very audacious people = who have sent their approval mails on this mailing list and have stood up a= nd spoken in favor of the WESP design - multiple times. The NIST Guidelines for Secure IPv6 deployment also refers to WESP as a pro= tocol that can be used to disambiguate ESP-NULL from encrypted ESP packets.= A SW division of NIST has already started working on supporting WESP. Given this I would appreciate if you can stop your rant against WESP till y= ou come up with a real technical reason of why you think WESP is unreliable= and "just doesn't work in all cases". Cheers, Manav= From kohn.jack@gmail.com Wed Jan 4 15:56:26 2012 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 9D69721F8715 for ; Wed, 4 Jan 2012 15:56:26 -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 rMu3KyHEbRm9 for ; Wed, 4 Jan 2012 15:56:26 -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 22BF121F8711 for ; Wed, 4 Jan 2012 15:56:26 -0800 (PST) Received: by qcsf15 with SMTP id f15so12782091qcs.31 for ; Wed, 04 Jan 2012 15:56:25 -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; bh=gT755MDjgS7f5HPKSWelO3g+HYkwhXYfqqcBzeuPOV8=; b=hp+jKrBFNGug6DMrojjVzJBkDA8v0XpLyhR0FRzFdyUj5GAuqCCYqKOV5csgCiprLC R+xB1YRjQoycIQByQoyj/bFUsAZ1Z2q5VIAZRYJ4ZLonBiYbL3+UpCqN7J3GQmGnJB63 itI6dF7Q3NoTDY75CBJ6LTQyqslcWx385fjAg= MIME-Version: 1.0 Received: by 10.229.77.85 with SMTP id f21mr20973285qck.79.1325721385671; Wed, 04 Jan 2012 15:56:25 -0800 (PST) Received: by 10.229.39.139 with HTTP; Wed, 4 Jan 2012 15:56:25 -0800 (PST) In-Reply-To: <4F04AF7B.1010005@gmail.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <5C745AC3-FA25-42BE-9848-DDEA3078A1FF@gmail.com> <493ECD00-71C7-4471-9B33-9F7F903ECB14@vpnc.org> <541DCEA7-C5A6-42C6-A1CB-DCF91677FB08@gmail.com> <4F04AF7B.1010005@gmail.com> Date: Thu, 5 Jan 2012 05:26:25 +0530 Message-ID: From: Jack Kohn To: Yaron Sheffer Content-Type: text/plain; charset=ISO-8859-1 Cc: IPsec ME WG List , RJ Atkinson Subject: Re: [IPsec] WESP and reliability 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, 04 Jan 2012 23:56:26 -0000 > method (RFC 5879)? Or else is there anything missing in WESP that we > should pay attention to, for example, maybe it doesn't support specific > IV or ICV sizes that those non IETF-goers are using? This stumped me for some time and i went back to read RFC 5840. The HdrLen in the WESP header will always point to the start of the unencrypted payload for the devices to inspect. No matter what IV or ICV size folks use, WESP will always work (contrary to claims made by a few individuals on the list). Jack From turners@ieca.com Wed Jan 4 19:31:16 2012 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 6869211E808C for ; Wed, 4 Jan 2012 19:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Sul8i1L6Xc+R for ; Wed, 4 Jan 2012 19:31:14 -0800 (PST) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.82.10]) by ietfa.amsl.com (Postfix) with ESMTP id ED0A611E8080 for ; Wed, 4 Jan 2012 19:31:11 -0800 (PST) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id E4D14871FB6F5; Wed, 4 Jan 2012 21:31:09 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway15.websitewelcome.com (Postfix) with ESMTP id DAAA1871FB6D5 for ; Wed, 4 Jan 2012 21:31:09 -0600 (CST) Received: from [96.241.0.108] (port=39403 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rie2k-0000a1-6u; Wed, 04 Jan 2012 21:31:06 -0600 Message-ID: <4F05197A.9090505@ieca.com> Date: Wed, 04 Jan 2012 22:31:06 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <7C362EEF9C7896468B36C9B79200D8350D028A2953@INBANSXCHMBSA1.in.alcatel-lucent.com> <6442.1325686562@marajade.sandelman.ca> <7C362EEF9C7896468B36C9B79200D8350D028A2AE5@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D028A2AE5@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.241.0.108]:39403 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "ipsec@ietf.org" , Nico Williams , "mcr@sandelman.ca" Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 05 Jan 2012 03:31:16 -0000 Manav, I'm trying to figure out whose implementation this situation will create a problem for? If the new application or protocol ends up doing one of the 3 things you listed (http://www.ietf.org/mail-archive/web/ipsec/current/msg07401.html), then is the problem that those who haven't implemented AH now have to? Are there any new applications or protocols that are mandating the use of AH? Currently, I'm unconcerned about somebody sneaking a new protocol that mandates AH past the IETF because of this group. This group certainly isn't made up of shrinking violets ;) spt On 1/4/12 9:22 AM, Bhatia, Manav (Manav) wrote: > Hi Marc, > > We don't say that. 4301 says that implementations MAY support AH and MUST support ESP. > > This creates a problem for implementations if in future a new application or a protocol mandates the use of AH. > > I will even go a step further and say that newer protocols should just assume ESP-NULL and not even bother with AH if they can do with just ESP. > > Cheers, Manav > > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] > Sent: Wednesday, January 04, 2012 7:46 PM > To: Bhatia, Manav (Manav) > Cc: Nico Williams; ipsec@ietf.org > Subject: Re: [IPsec] Avoiding Authentication Header (AH) > > >>>>>> "Manav" == Manav Bhatia writes: > Manav> Hi Nico, > > >> Advising (and updating said advice as circumstances change) > >> use-IPsec protocol designers as to when to use ESP and/or AH is > >> something we should do. Deprecating AH seems like a nice idea, > >> but if there's good reasons to still use it, then maybe not. > > Manav> We're not talking about deprecating or killing AH. I concede > Manav> that I did allude to it in my first draft, but then changed > Manav> the tone based on the WG feedback, to say that we should > Manav> "avoid" AH wherever possible. > > This is the status quo already. > Why do we need this draft? > From yaronf.ietf@gmail.com Wed Jan 4 22:35:22 2012 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 A07E421F87B5 for ; Wed, 4 Jan 2012 22:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.486 X-Spam-Level: X-Spam-Status: No, score=-103.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 5xW3XCoqSa4y for ; Wed, 4 Jan 2012 22:35:22 -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 E059C21F8799 for ; Wed, 4 Jan 2012 22:35:21 -0800 (PST) Received: by eekc14 with SMTP id c14so127131eek.31 for ; Wed, 04 Jan 2012 22:35:19 -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=F1HOYNx34zjeAcxkB5+mkyfdZST/9B88UKmDG/CTcs8=; b=Ztsxub13dQrKiHhXW4B5snwlLi+JkdeV+WIUBGJej89P21eT8FbJvM1uDqTSIQnUhc oTZDYf2FnOTUSyECr0sJRjYvmVqttAMeiwrd+sxQdTKZog/9i/zTQ3YCJVanV22TMZwv qJFjBqb/7kMLm18YAxJDdKJaIo1u/bbhDOZ90= Received: by 10.14.50.204 with SMTP id z52mr302184eeb.92.1325745319653; Wed, 04 Jan 2012 22:35:19 -0800 (PST) Received: from [10.0.0.6] ([109.67.155.85]) by mx.google.com with ESMTPS id t59sm229726298eeh.10.2012.01.04.22.35.17 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 22:35:18 -0800 (PST) Message-ID: <4F0544A3.8050706@gmail.com> Date: Thu, 05 Jan 2012 08:35:15 +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: Jack Kohn References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <5C745AC3-FA25-42BE-9848-DDEA3078A1FF@gmail.com> <493ECD00-71C7-4471-9B33-9F7F903ECB14@vpnc.org> <541DCEA7-C5A6-42C6-A1CB-DCF91677FB08@gmail.com> <4F04AF7B.1010005@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsec ME WG List , RJ Atkinson Subject: Re: [IPsec] WESP and reliability 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, 05 Jan 2012 06:35:22 -0000 I agree. Yaron On 01/05/2012 01:56 AM, Jack Kohn wrote: >> method (RFC 5879)? Or else is there anything missing in WESP that we >> should pay attention to, for example, maybe it doesn't support specific >> IV or ICV sizes that those non IETF-goers are using? > This stumped me for some time and i went back to read RFC 5840. > > The HdrLen in the WESP header will always point to the start of the > unencrypted payload for the devices to inspect. No matter what IV or > ICV size folks use, WESP will always work (contrary to claims made by > a few individuals on the list). > > Jack From yaronf.ietf@gmail.com Wed Jan 4 23:22:48 2012 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 4C46121F8627 for ; Wed, 4 Jan 2012 23:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 50sDr26utQFS for ; Wed, 4 Jan 2012 23:22:47 -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 79D2C21F8626 for ; Wed, 4 Jan 2012 23:22:47 -0800 (PST) Received: by eekc14 with SMTP id c14so147546eek.31 for ; Wed, 04 Jan 2012 23:22:46 -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=f80AZGHjyWxns+reLR5OK57/kravqdthX4IJ5IOO378=; b=lm7LFSxuBNa7aK5tlDq1SUt1zSrvFTPlIZG6Vp4g7XVvZewTtmdyLbjlfg88El4DXo gC4FIyapsqUCGWYdBEkiI5oCk5Rj6vKVu9k+4z92GoUJ7eUNF753eW9mabsZYhRRCYz3 duCvaJyT4uf9JZll5vW/uJjs5vs1A0tHz71lg= Received: by 10.14.98.196 with SMTP id v44mr277816eef.53.1325748166471; Wed, 04 Jan 2012 23:22:46 -0800 (PST) Received: from [10.0.0.6] ([109.67.155.85]) by mx.google.com with ESMTPS id t1sm230211313eeb.3.2012.01.04.23.22.44 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 23:22:45 -0800 (PST) Message-ID: <4F054FC3.4040400@gmail.com> Date: Thu, 05 Jan 2012 09:22:43 +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: Sean Turner References: <7C362EEF9C7896468B36C9B79200D8350D028A2953@INBANSXCHMBSA1.in.alcatel-lucent.com> <6442.1325686562@marajade.sandelman.ca> <7C362EEF9C7896468B36C9B79200D8350D028A2AE5@INBANSXCHMBSA1.in.alcatel-lucent.com> <4F05197A.9090505@ieca.com> In-Reply-To: <4F05197A.9090505@ieca.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Nico Williams , "Bhatia, Manav \(Manav\)" , "mcr@sandelman.ca" Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 05 Jan 2012 07:22:48 -0000 Hi Sean, first, thanks for the collective compliment. But in fact I have seen two recent cases where IPsec/IKE-related work did manage to sneak past this workgroup until quite late in the process ( http://tools.ietf.org/html/draft-ietf-hokey-rfc5296bis-06, http://tools.ietf.org/html/draft-ietf-dime-ikev2-psk-diameter-11). It may be a matter of lack of communication or lack of energy, but these things do happen. So I do see value in a draft that explicitly recommends not using AH in general, and points out where AH does make sense. Thanks, Yaron On 01/05/2012 05:31 AM, Sean Turner wrote: > Manav, > > I'm trying to figure out whose implementation this situation will > create a problem for? If the new application or protocol ends up doing > one of the 3 things you listed > (http://www.ietf.org/mail-archive/web/ipsec/current/msg07401.html), > then is the problem that those who haven't implemented AH now have to? > > Are there any new applications or protocols that are mandating the use > of AH? > > Currently, I'm unconcerned about somebody sneaking a new protocol that > mandates AH past the IETF because of this group. This group certainly > isn't made up of shrinking violets ;) > > spt > > On 1/4/12 9:22 AM, Bhatia, Manav (Manav) wrote: >> Hi Marc, >> >> We don't say that. 4301 says that implementations MAY support AH and >> MUST support ESP. >> >> This creates a problem for implementations if in future a new >> application or a protocol mandates the use of AH. >> >> I will even go a step further and say that newer protocols should >> just assume ESP-NULL and not even bother with AH if they can do with >> just ESP. >> >> Cheers, Manav >> >> -----Original Message----- >> From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] >> Sent: Wednesday, January 04, 2012 7:46 PM >> To: Bhatia, Manav (Manav) >> Cc: Nico Williams; ipsec@ietf.org >> Subject: Re: [IPsec] Avoiding Authentication Header (AH) >> >> >>>>>>> "Manav" == Manav Bhatia writes: >> Manav> Hi Nico, >> >> >> Advising (and updating said advice as circumstances change) >> >> use-IPsec protocol designers as to when to use ESP and/or AH is >> >> something we should do. Deprecating AH seems like a nice idea, >> >> but if there's good reasons to still use it, then maybe not. >> >> Manav> We're not talking about deprecating or killing AH. I concede >> Manav> that I did allude to it in my first draft, but then changed >> Manav> the tone based on the WG feedback, to say that we should >> Manav> "avoid" AH wherever possible. >> >> This is the status quo already. >> Why do we need this draft? >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From manav.bhatia@alcatel-lucent.com Thu Jan 5 01:43:20 2012 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 22F8E21F87CA for ; Thu, 5 Jan 2012 01:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 MY5R68LMCRKJ for ; Thu, 5 Jan 2012 01:43:19 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 68C5121F85F4 for ; Thu, 5 Jan 2012 01:43:19 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q059hElD013186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jan 2012 03:43:16 -0600 (CST) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q059hCtX019001 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Jan 2012 15:13: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; Thu, 5 Jan 2012 15:13:13 +0530 From: "Bhatia, Manav (Manav)" To: Sean Turner Date: Thu, 5 Jan 2012 15:13:08 +0530 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) Thread-Index: AczLWn0YgGvNm6yrS4m8g5Msbkt0kQAMUbUg Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A2C92@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D028A2953@INBANSXCHMBSA1.in.alcatel-lucent.com> <6442.1325686562@marajade.sandelman.ca> <7C362EEF9C7896468B36C9B79200D8350D028A2AE5@INBANSXCHMBSA1.in.alcatel-lucent.com> <4F05197A.9090505@ieca.com> In-Reply-To: <4F05197A.9090505@ieca.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.37 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 05 Jan 2012 09:43:20 -0000 Hi Sean, All I am saying is this: There are many implementations that don't support AH as 4301 has a MAY supp= ort clause for AH. Many people don't understand this. You could argue that its trivial and the= y should know this, but this aint an ideal world and people don't realize t= his. Even within IETF there could be WGs looking at using or extending AH. Given that ESP does everything useful that AH does, it makes no sense to co= ntinue using AH. I think we should have a draft that says this. However, th= ere are some very corner cases where it *may* make sense to use AH (though = I am still a little unconvinced, but I'll concede for the sake of moving on= ) and people are most welcome to do that. If a WG ends up mandating AH (when ESP could have been used) then Yes it's = a problem for everyone, right from the vendors to the users, who have to no= w support AH too in their products and networks. And btw, what we're attempting here is not new in IETF. If you look at a ve= ry recent RFC 6472 which was published as a BCP then that's also very simil= ar to what we're trying to do in the IPsec world. Folks had been using AS_S= ETs in BGP since a long time and its wasn't breaking down the networks. The= BCP was published (to quote from the RFC) to: to simplify the design and implementation of BGP and to make the semantics of the originator of a route more clear. This will also simplify the design, implementation, and deployment of ongoing work in the Secure Inter-Domain Routing Working Group. Similar to the above RFC I think the draft in question does simplify a few = things. There is work happening in KARP (that I know you're well aware of) = where one of the requirements is to come out with a security mechanism that= does NOT preclude the possibility of adding encryption services later. AH = can never meet this requirement, so its practically out of the door. When w= e have so many documents hinting towards that (including the ones from NIST= ), then why are we being shy about admitting this openly. I agree with Yaron that there is value in some document that recommends not= using AH when ESP-NULL can be employed, and also that points out where AH = does make sense. Cheers, Manav=20 -----Original Message----- From: Sean Turner [mailto:turners@ieca.com]=20 Sent: Thursday, January 05, 2012 9:01 AM To: Bhatia, Manav (Manav) Cc: mcr@sandelman.ca; ipsec@ietf.org; Nico Williams Subject: Re: [IPsec] Avoiding Authentication Header (AH) Manav, I'm trying to figure out whose implementation this situation will create a = problem for? If the new application or protocol ends up doing one of the 3= things you listed (http://www.ietf.org/mail-archive/web/ipsec/current/msg0= 7401.html), then is the problem that those who haven't implemented AH now h= ave to? Are there any new applications or protocols that are mandating the use of A= H? Currently, I'm unconcerned about somebody sneaking a new protocol that mand= ates AH past the IETF because of this group. This group certainly isn't ma= de up of shrinking violets ;) spt On 1/4/12 9:22 AM, Bhatia, Manav (Manav) wrote: > Hi Marc, > > We don't say that. 4301 says that implementations MAY support AH and MUST= support ESP. > > This creates a problem for implementations if in future a new application= or a protocol mandates the use of AH. > > I will even go a step further and say that newer protocols should just as= sume ESP-NULL and not even bother with AH if they can do with just ESP. > > Cheers, Manav > > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] > Sent: Wednesday, January 04, 2012 7:46 PM > To: Bhatia, Manav (Manav) > Cc: Nico Williams; ipsec@ietf.org > Subject: Re: [IPsec] Avoiding Authentication Header (AH) > > >>>>>> "Manav" =3D=3D Manav Bhatia writes: > Manav> Hi Nico, > > >> Advising (and updating said advice as circumstances change) > >> use-IPsec protocol designers as to when to use ESP and/or AH is > >> something we should do. Deprecating AH seems like a nice idea, > >> but if there's good reasons to still use it, then maybe not. > > Manav> We're not talking about deprecating or killing AH. I concede > Manav> that I did allude to it in my first draft, but then changed > Manav> the tone based on the WG feedback, to say that we should > Manav> "avoid" AH wherever possible. > > This is the status quo already. > Why do we need this draft? > From kivinen@iki.fi Thu Jan 5 06:00:46 2012 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 06B7C21F881B for ; Thu, 5 Jan 2012 06:00:46 -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=[AWL=0.000, 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 Mop29aU7nMH0 for ; Thu, 5 Jan 2012 06:00:45 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160D221F8817 for ; Thu, 5 Jan 2012 06:00: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 q05E0bgL006932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jan 2012 16:00:37 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q05E0aum018931; Thu, 5 Jan 2012 16:00:36 +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: <20229.44292.629825.7429@fireball.kivinen.iki.fi> Date: Thu, 5 Jan 2012 16:00:36 +0200 From: Tero Kivinen To: "Bhatia, Manav (Manav)" In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 18 min Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 05 Jan 2012 14:00:46 -0000 Bhatia, Manav (Manav) writes: > > There is no evidence of any recent change either to the operational > > circumstances or to the available alternatives. So no update is > > appropriate at this time. > > One major recent change is the publication of WESP [RFC 5840] and > the standard for using Heuristics for detecting ESP-NULL packets > [RFC 5879]. > > This takes away one major reason why folks wanted to use AH - that > of being able to deep inspect packets. > > Even the NIST guidelines for IPv6 deployment says that the main > argument in favor of AH is the ability to inspect packets. With WESP > even that goes away. Getting WESP implemented to the boxes will require a lot of time. There are still lots of boxes which do not even support IKEv2 (which is required for WESP) and IKEv2 has been out for 6 years already. AH might already be implemented on some boxes, so using it might offer faster deployment time than WESP. The only *protocol* benefit WESP have over AH is that it works through NATs. As I see it the main reason AH is now MAY, not MUST, is that there has not been that much use for it, and that has caused it to be as second class citizen in the VPN driven IPsec work. Because of that testing etc has been somewhat ommitted. For example most of the interoperability events has concentrated ESP testing, and only very briefly done some AH testing (if there has been extra time). Because quite a lot of IPsec development have been driven by the VPN vendors, who do not have use for AH (or WESP), those vendors have seen the previous mandatory to implment AH, as unnecessary burden for their implementations. Thats why degrading it to MAY was good way forward in the RFC4301. This does not mean there is no use for AH in some environments. I personally (at least now) think that it would have been more useful to just say use AH than to create WESP (and heuristics) at all... That would have given some use cases for AH, which would have then perhaps moved it back to used track in the IPsec protocol family. I myself think there is no reason to say anything about AH at this point. It is MAY, so nobody needs to implement it. Every new protocol using IPsec should consider whether they want to use ESP, ESP-NULL, WESP, or AH and make their own decisions based on what would be best for that environment and protocol. I.e if you require confidentiality then you needs to use ESP, if you require transport mode outer IP option protection you need to use AH, otherwise you can pick any of them... If you want to make sure other protocols do not unnecessarely specify AH for their use, you should just participate in writing those specifications and explain why do you think AH should be avoided in that environment. -- kivinen@iki.fi From kivinen@iki.fi Thu Jan 5 06:23:16 2012 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 DDFBA21F87CA for ; Thu, 5 Jan 2012 06:23:14 -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 WAmILNbgIjnT for ; Thu, 5 Jan 2012 06:23:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01EB021F8762 for ; Thu, 5 Jan 2012 06:23:13 -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 q05EN787018794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jan 2012 16:23:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q05EN6E9020690; Thu, 5 Jan 2012 16:23:06 +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: <20229.45642.477101.356308@fireball.kivinen.iki.fi> Date: Thu, 5 Jan 2012 16:23:06 +0200 From: Tero Kivinen To: "Bhatia, Manav (Manav)" In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D028A2C92@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350D028A2953@INBANSXCHMBSA1.in.alcatel-lucent.com> <6442.1325686562@marajade.sandelman.ca> <7C362EEF9C7896468B36C9B79200D8350D028A2AE5@INBANSXCHMBSA1.in.alcatel-lucent.com> <4F05197A.9090505@ieca.com> <7C362EEF9C7896468B36C9B79200D8350D028A2C92@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 10 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 05 Jan 2012 14:23:17 -0000 Bhatia, Manav (Manav) writes: > Hi Sean, > > All I am saying is this: > > There are many implementations that don't support AH as 4301 has a > MAY support clause for AH. Just noting that same is true for WESP. It is not mandatory to implement, and I would claim there are way more implementations out there supporting AH than there are supporting WESP. > Even within IETF there could be WGs looking at using or extending > AH. If there are some, just point us to them... anyways extending AH would clearly require comments from the IPsec community so doing such thing and not getting comments from this list would (or at least should) be impossible. > Given that ESP does everything useful that AH does, it makes no > sense to continue using AH. I think we should have a draft that says > this. However, there are some very corner cases where it *may* make > sense to use AH (though I am still a little unconvinced, but I'll > concede for the sake of moving on) and people are most welcome to do > that. ESP-NULL does not provide the "reliable 100% proof" ability to parse past the header. WESP does, but that is in the same category in the implementations than AH (MAY), so that does not help. Heuristics does provide a way to parse past the headers, but people claim it is not reliable enough for them, and again it is in same category in the implementations. Altough deploying heuristics implementation is faster as it only requires changes to middleboxes not end nodes... > If a WG ends up mandating AH (when ESP could have been used) then > Yes it's a problem for everyone, right from the vendors to the > users, who have to now support AH too in their products and > networks. If WG wants to mandate AH, and we cannot convince them otherwise, having a document which says so does not help. On the other hand if we have stealth WG trying to sneak AH past IPsec community, I think they will also conviently ignore this document too. In summary I do not think there is problem, and I do not think we need to say anything about AH right now. -- kivinen@iki.fi From msa@moth.iki.fi Thu Jan 5 06:26:05 2012 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 2E31921F87F1 for ; Thu, 5 Jan 2012 06:26:05 -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 aB4OiEolzUGU for ; Thu, 5 Jan 2012 06:26:04 -0800 (PST) Received: from moth.iki.fi (moth.iki.fi [212.16.111.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9A08021F87CA for ; Thu, 5 Jan 2012 06:26:04 -0800 (PST) Received: from [130.188.197.233] (unknown [130.188.197.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: msa) by moth.iki.fi (Postfix) with ESMTPSA id E43A81E581D for ; Thu, 5 Jan 2012 16:26:09 +0200 (EET) Message-ID: <4F05B2FB.2070007@moth.iki.fi> Date: Thu, 05 Jan 2012 16:26:03 +0200 From: Markku Savela User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: ipsec@ietf.org References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <20229.44292.629825.7429@fireball.kivinen.iki.fi> In-Reply-To: <20229.44292.629825.7429@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 05 Jan 2012 14:26:05 -0000 I don't understand why this discussion is needed. AH is end-to-end, and the transformations to be used for the connection are negotiated with key negotiation and configured policies. If end points don't want to use AH for whatever reason (like not implemented), they are not asking it. If end points decide to us it, they have it implemented, it is their business and it should be irrelevant for any intermediate node (for deep onboxious packet inspection, skipping AH is trivial matter). From manav.bhatia@alcatel-lucent.com Thu Jan 5 06:37:11 2012 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 2391D21F8780 for ; Thu, 5 Jan 2012 06:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 W1hijiPxrrH4 for ; Thu, 5 Jan 2012 06:37:10 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8D29721F8771 for ; Thu, 5 Jan 2012 06:37:10 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q05Eb61k000371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jan 2012 08:37:09 -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 q05Eb5wu007348 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Jan 2012 20:07:06 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Thu, 5 Jan 2012 20:07:05 +0530 From: "Bhatia, Manav (Manav)" To: Tero Kivinen Date: Thu, 5 Jan 2012 20:07:07 +0530 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) Thread-Index: AczLsm/3amwBwUzuQKWNHAVBGWQDywABLiHg Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A2D56@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <20229.44292.629825.7429@fireball.kivinen.iki.fi> In-Reply-To: <20229.44292.629825.7429@fireball.kivinen.iki.fi> 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.37 Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 05 Jan 2012 14:37:11 -0000 > Getting WESP implemented to the boxes will require a lot of time. > There are still lots of boxes which do not even support IKEv2 (which is r= equired for=20 > WESP) and IKEv2 has been out for 6 years already. AH might already be=20 WESP can be used with manual keying the way routing protocols today use ESP= and AH. Manav From kivinen@iki.fi Thu Jan 5 07:03:07 2012 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 0412921F8750 for ; Thu, 5 Jan 2012 07:03:07 -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=[AWL=0.000, 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 FfCbC3og8PRc for ; Thu, 5 Jan 2012 07:03:02 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8575821F8716 for ; Thu, 5 Jan 2012 07:03:02 -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 q05F2s5o015125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jan 2012 17:02:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q05F2qHN011877; Thu, 5 Jan 2012 17:02:52 +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: <20229.48028.145994.197136@fireball.kivinen.iki.fi> Date: Thu, 5 Jan 2012 17:02:52 +0200 From: Tero Kivinen To: "Bhatia, Manav (Manav)" In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D028A2D56@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <20229.44292.629825.7429@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8350D028A2D56@INBANSXCHMBSA1.in.alcatel-lucent.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 7 min Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 05 Jan 2012 15:03:07 -0000 Bhatia, Manav (Manav) writes: > > > Getting WESP implemented to the boxes will require a lot of time. > > There are still lots of boxes which do not even support IKEv2 > > (which is required for WESP) and IKEv2 has been out for 6 years > > already. AH might already be > > WESP can be used with manual keying the way routing protocols today > use ESP and AH. Hmm... RFC5840 says: ---------------------------------------------------------------------- 2.3. IKE Considerations This document assumes that WESP negotiation is performed using IKEv2. ... ---------------------------------------------------------------------- It seems the RFC5840 assumes you use IKEv2, but there might be some other document to specify manual keying for WESP. Or it could be said that RFC4301 section 4.5.1 covers also WESP... Actually I think it will. Anyways do you really think manually keyed WESP is feasible method to be used in large enterprises requiring deep packet inspection just so they do not need to replace obsoleted IKEv1 protocol with much better and actually working IKEv2? And why would routing protocols need to use WESP, I would assume they use ESP-NULL instead. In addition if you use manual keying you can also use mandated by policy "100% reliable" heuristics method from RFC5879 section 2.2. -- kivinen@iki.fi From ynir@checkpoint.com Thu Jan 5 07:47:44 2012 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 207AC21F8679 for ; Thu, 5 Jan 2012 07:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.415 X-Spam-Level: X-Spam-Status: No, score=-10.415 tagged_above=-999 required=5 tests=[AWL=0.184, 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 JZsVTAqjDV1n for ; Thu, 5 Jan 2012 07:47:43 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 39F4021F8759 for ; Thu, 5 Jan 2012 07:47:42 -0800 (PST) X-CheckPoint: {4F05C3D7-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 q05FlRRG025621; Thu, 5 Jan 2012 17:47:30 +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, 5 Jan 2012 17:47:27 +0200 From: Yoav Nir To: "Bhatia, Manav (Manav)" Date: Thu, 5 Jan 2012 17:47:30 +0200 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) Thread-Index: AczLwVN04G0kKlviQciXtNQtpM/mAw== Message-ID: <6B16D76E-A432-497D-A9A2-DF3465449247@checkpoint.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <20229.44292.629825.7429@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8350D028A2D56@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350D028A2D56@INBANSXCHMBSA1.in.alcatel-lucent.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 ME WG List , Tero Kivinen Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 05 Jan 2012 15:47:44 -0000 On Jan 5, 2012, at 4:37 PM, Bhatia, Manav (Manav) wrote: >=20 >> Getting WESP implemented to the boxes will require a lot of time. >> There are still lots of boxes which do not even support IKEv2 (which is = required for=20 >> WESP) and IKEv2 has been out for 6 years already. AH might already be=20 >=20 > WESP can be used with manual keying the way routing protocols today use E= SP and AH. Hi Manav. I guess it can, but ESP (and AH and presumably WESP) would be implemented a= t a lower layer than IKE. For some boxes that would be ESP implemented in s= ilicon and IKE implemented in software. So getting your own box to start doing IKEv2 is relatively straightforward = - a software fix (even if it's referred to as "firmware"), while WESP would= require a new box. Even in software implementations the IPsec is usually c= onsidered more "stable" than the IKE code. The big vendors have taken years to implement IKEv2 in regular boxes (as op= posed to lab curiosities). I don't see them rushing to implement WESP just = to please the middlebox makers. Yoav= From manav.bhatia@alcatel-lucent.com Thu Jan 5 08:05:01 2012 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 EAB6621F8688 for ; Thu, 5 Jan 2012 08:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 L7n-djNpMEkz for ; Thu, 5 Jan 2012 08:05:01 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5243C21F8679 for ; Thu, 5 Jan 2012 08:05:01 -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 q05G4AEB024180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jan 2012 10:04:13 -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 q05G48AF003499 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Jan 2012 21:34:09 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 5 Jan 2012 21:34:08 +0530 From: "Bhatia, Manav (Manav)" To: Yoav Nir Date: Thu, 5 Jan 2012 21:34:09 +0530 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) Thread-Index: AczLwVN04G0kKlviQciXtNQtpM/mAwAAESAg Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A2D67@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <20229.44292.629825.7429@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8350D028A2D56@INBANSXCHMBSA1.in.alcatel-lucent.com> <6B16D76E-A432-497D-A9A2-DF3465449247@checkpoint.com> In-Reply-To: <6B16D76E-A432-497D-A9A2-DF3465449247@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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: IPsec ME WG List , Tero Kivinen Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 05 Jan 2012 16:05:02 -0000 Hi Yoav, I see some potential of using WESP in the routing protocols where it helps = the end nodes in prioritizing certain control packets over the others.=20 One could argue that the end nodes know that the packets are NULL encrypted= and could use regular ESP as well. The problem with this is that the end n= odes then need to install per SPI filter entries which is not scalable. Pac= kets need to be punted to separate queues since Ipsec processing is often d= one in SW after the packets have been dequeued from the CPU queues. This is not a completely sorted idea and I need to spend more time on this = to see if it makes sense .. Cheers, Manav P.S. BTW, one vendor recommends AH for OSPFv3 (despite 4522 stating that as a MA= Y) since it helps their implementation to prioritize OSPFv3 packets. -----Original Message----- From: Yoav Nir [mailto:ynir@checkpoint.com]=20 Sent: Thursday, January 05, 2012 9:18 PM To: Bhatia, Manav (Manav) Cc: Tero Kivinen; IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) On Jan 5, 2012, at 4:37 PM, Bhatia, Manav (Manav) wrote: >=20 >> Getting WESP implemented to the boxes will require a lot of time. >> There are still lots of boxes which do not even support IKEv2 (which=20 >> is required for >> WESP) and IKEv2 has been out for 6 years already. AH might already be >=20 > WESP can be used with manual keying the way routing protocols today use E= SP and AH. Hi Manav. I guess it can, but ESP (and AH and presumably WESP) would be implemented a= t a lower layer than IKE. For some boxes that would be ESP implemented in s= ilicon and IKE implemented in software. So getting your own box to start doing IKEv2 is relatively straightforward = - a software fix (even if it's referred to as "firmware"), while WESP would= require a new box. Even in software implementations the IPsec is usually c= onsidered more "stable" than the IKE code. The big vendors have taken years to implement IKEv2 in regular boxes (as op= posed to lab curiosities). I don't see them rushing to implement WESP just = to please the middlebox makers. Yoav= From dharkins@lounge.org Thu Jan 5 08:23:01 2012 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 411DD21F8667 for ; Thu, 5 Jan 2012 08:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.66 X-Spam-Level: X-Spam-Status: No, score=-4.66 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_TOOL=2.3, 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 NWytHP3P3lhJ for ; Thu, 5 Jan 2012 08:23:00 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9179321F863C for ; Thu, 5 Jan 2012 08:22:55 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3AEC7A88810C; Thu, 5 Jan 2012 08:22:54 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 5 Jan 2012 08:22:54 -0800 (PST) Message-ID: <8ddf32c400110c28909960366274f61f.squirrel@www.trepanning.net> In-Reply-To: <20229.45642.477101.356308@fireball.kivinen.iki.fi> References: <7C362EEF9C7896468B36C9B79200D8350D028A2953@INBANSXCHMBSA1.in.alcatel-lucent.com> <6442.1325686562@marajade.sandelman.ca> <7C362EEF9C7896468B36C9B79200D8350D028A2AE5@INBANSXCHMBSA1.in.alcatel-lucent.com> <4F05197A.9090505@ieca.com> <7C362EEF9C7896468B36C9B79200D8350D028A2C92@INBANSXCHMBSA1.in.alcatel-lucent.com> <20229.45642.477101.356308@fireball.kivinen.iki.fi> Date: Thu, 5 Jan 2012 08:22:54 -0800 (PST) From: "Dan Harkins" To: "Tero Kivinen" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "ipsec@ietf.org" , "Bhatia, Manav \(Manav\)" Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 05 Jan 2012 16:23:01 -0000 On Thu, January 5, 2012 6:23 am, Tero Kivinen wrote: > Bhatia, Manav (Manav) writes: [snip] >> If a WG ends up mandating AH (when ESP could have been used) then >> Yes it's a problem for everyone, right from the vendors to the >> users, who have to now support AH too in their products and >> networks. > > If WG wants to mandate AH, and we cannot convince them otherwise, > having a document which says so does not help. On the other hand if we > have stealth WG trying to sneak AH past IPsec community, I think they > will also conviently ignore this document too. > > In summary I do not think there is problem, and I do not think we need > to say anything about AH right now. Indeed! I agree 100%. Me too. +1. Etc. Dan. From kivinen@iki.fi Mon Jan 9 07:54:13 2012 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 83CC511E8086 for ; Mon, 9 Jan 2012 07:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, 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 k2w9rT0jxFeF for ; Mon, 9 Jan 2012 07:54:09 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B9411E8080 for ; Mon, 9 Jan 2012 07:54: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 q09FomMu022579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jan 2012 17:50:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id q09Foisd020648; Mon, 9 Jan 2012 17:50:44 +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: <20235.3284.301719.250098@fireball.kivinen.iki.fi> Date: Mon, 9 Jan 2012 17:50:44 +0200 From: Tero Kivinen To: iana-matrix@iana.org In-Reply-To: References: <20162.16194.361337.415232@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 48 min X-Total-Time: 54 min Cc: ipsec@ietf.org, turners@ieca.com, liang@icann.org, stephen.farrell@cs.tcd.ie Subject: [IPsec] [IANA #111200] [old message] Possible update to isakmp-registry 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, 09 Jan 2012 15:54:13 -0000 [I CCed the ipsec@ietf.org list, as this changes the registration policies, and we have already had some discussion about this earlier on the list and other people there might also have their opinion about the matter.] Pearl Liang via RT writes: > 1) What are the registration procedures for these sub-registries > listed in http://www.iana.org/assignments/ipsec-registry: > > - Exchange Type > - Additional Exchanges Defined-- XCHG values > - Next Payload Types > - Notify Message Types > - Notify Messages - Error Types (1-8191) > - Notify Messages - Status Types (16384-24575) > > ? I would like to update "Not defined" if possible. For most of those it is not defined... I.e the original RFC does not specify any registration procedures for them (or for some other registries we have there). I would most likely think it would be best to put them as "Specification required" or "RFC required". Actually I think we should go through the RFC2407-2409 and see from there for which registries they do specify any registration policies, and use those values for only those registries and put everything else as "Specification required" or "RFC Required". ---------------------------------------------------------------------- Registry Name: Attribute Classes Current: Standards-track RFC RFC2409: 11.1 Attribute Classes Attributes negotiated in this protocol are identified by their class. Requests for assignment of new classes must be accompanied by a standards-track RFC which describes the use of this attribute. -> Standards-track RFC, already OK ---------------------------------------------------------------------- Registry Name: Encryption Algorithm Class Values (Value 1) Current: Standards-track or Informational RFC RFC2409: 11.2 Encryption Algorithm Class Values of the Encryption Algorithm Class define an encryption algorithm to use when called for in this document. Requests for assignment of new encryption algorithm values must be accompanied by a reference to a standards-track or Informational RFC or a reference to published cryptographic literature which describes this algorithm. -> Specification required, currently this is Standards-track or Informational RFC, but I think Specification required is closer to what the RFC says about "a reference to published cryptographic literature". ---------------------------------------------------------------------- Registry Name: Hash Algorithm (Value 2) Current: Standards-track or Informational RFC RFC2409: 11.3 Hash Algorithm Values of the Hash Algorithm Class define a hash algorithm to use when called for in this document. Requests for assignment of new hash algorithm values must be accompanied by a reference to a standards- track or Informational RFC or a reference to published cryptographic literature which describes this algorithm. Due to the key derivation and key expansion uses of HMAC forms of hash algorithms in IKE, requests for assignment of new hash algorithm values must take into account the cryptographic properties-- e.g it's resistance to collision-- of the hash algorithm itself. -> Specification required, see above. ---------------------------------------------------------------------- Registry Name: IPSEC Authentication Methods (Value 3) Current: Standards-track RFC There is nothing about this in the RFC2409, so I would say either "RFC required" or "Specification required" would be ok. There is draft http://tools.ietf.org/html/draft-harkins-ike-iana-update-00 already proposing this change. ---------------------------------------------------------------------- Registry Name: Group Description (Value 4) Current: Standards-track or Informational RFC Registry Name: Group Type (Value 5) Current: Standards-track or Informational RFC RFC2409: 11.4 Group Description and Group Type Values of the Group Description Class identify a group to use in a Diffie-Hellman exchange. Values of the Group Type Class define the type of group. Requests for assignment of new groups must be accompanied by a reference to a standards-track or Informational RFC which describes this group. Requests for assignment of new group types must be accompanied by a reference to a standards-track or Informational RFC or by a reference to published cryptographic or mathmatical literature which describes the new type. Group Description (Value 4) -> RFC required Group Type (Value 5) -> Specification required ---------------------------------------------------------------------- Registry Name: Life Type (Value 11) Current: Specification Required RFC2409: 11.5 Life Type Values of the Life Type Class define a type of lifetime to which the ISAKMP Security Association applies. Requests for assignment of new life types must be accompanied by a detailed description of the units of this type and its expiry. -> Hmm... this is vague, I would expect it means "Specification required", so ok already. ---------------------------------------------------------------------- Registry Name: PRF (Value 13) Current: Standards-track or Informational RFC There is nothing about this in the RFC2409, so I would say either "RFC required" or "Specification required" would be ok. ---------------------------------------------------------------------- Registry Name: Exchange Type Current: Not defined There is nothing in RFC2409/RFC2408. There has not been additions to this, and I do not expect there to be one (as all new stuff should be done on the protocol which obsoleted this one). I would say "Standards Action" would most likely be best for this. ---------------------------------------------------------------------- Registry Name: Additional Exchanges Defined-- XCHG values Current: Not defined There is nothing in RFC2409/RFC2408. Same as above -> "Standards Action". ---------------------------------------------------------------------- Registry Name: ISAKMP Domain of Interpretation (DOI) Current: Standards-track RFC RFC2408: Domain of Interpretation The Domain of Interpretation (DOI) is a 32-bit field which identifies the domain under which the security association negotiation is taking place. Requests for assignments of new DOIs must be accompanied by a standards-track RFC which describes the specific domain. -> "Standards action" (i.e. Standards-track RFC) ---------------------------------------------------------------------- Registry Name: Next Payload Types Current: Internet Draft There is nothing in RFC2409/RFC2408. There has been more of these, so "RFC required", I think Internet Draft is bit too low, and not matching the RFC5226 usages. ---------------------------------------------------------------------- Registry Name: Notify Message Types Current: Not defined Sub-registry: Notify Messages - Error Types (1-8191) Current: Not defined Sub-Registry: Notify Messages - Status Types (16384-24575) Current: Not defined No additions to these registries, but these are large registries, so perhaps "RFC required". ---------------------------------------------------------------------- There is a problem in the "IPSEC Authentication Methods (Value 3)" as there is 3 values which do not have any real specification, i.e. 6 Encryption with El-Gamal 7 Revised encryption with El-Gamal 8 ECDSA signatures [Fahn] As there is no reference to any document or anything, I have no idea how anybody could actually implement those in interoperable manner. I would suggest changing those to: 6 Reserved (was Encryption with El-Gamal) 7 Reserved (was Revised encryption with El-Gamal) 8 Reserved (was ECDSA signatures) so it is clear that nobody knows how those should be implemented... ---------------------------------------------------------------------- > 2) I've added the draft ietf-ipsec-ike-ecc-groups to ipsec-registry. > I then noticed that the document also requests the following values > as described in Table 2 in the IANA Considerations section: > > 6 EC2NGF163Random2 > 7 EC2NGF163Koblitz > 8 EC2NGF283Random > 9 EC2NGF283Koblitz > 10 EC2NGF409Random > 11 EC2NGF409Koblitz > 12 EC2NGF571Random > 13 EC2NGF571Koblitz These are from the http://tools.ietf.org/html/draft-ietf-ipsec-ike-ecc-groups-04 version, i.e. the registry was updated at some point in 2002 even when the registry had registration policy of "RFC Required" and the document was still draft (and was never published as RFC). I think you should remove "Panjwani" and "Blake-Wilson" and put "ipsec-ike-ecc-groups" for all of them, and put some down a footnote saying that the registry was updated too early and the draft never made it to the RFC, but as these values might be used by some implementations they are left there in the registry, but new implementations should not use them. Also the reference could point out that the values in the registry match the -04 version of the document. > 22 ECPRGF192Random > 23 EC2NGF163Random > 24 ECPRGF224Random > 25 EC2NGF233Random > 26 EC2NGF233Koblitz These overlap with the already allocated other groups, so those should not be added to the registry. > Question: are these, specifically 10-13 & 22-26, no longer required > by ietf-ipsec-ike-ecc-groups? If we should leave them untouched, > please let me know. The draft-ietf-ipsec-ike-ecc-groups document will most likely not be going forward so adding the footnotes and comments to references might be best. I did not yet check the isakmp-registry, I will do that later. > On Tue Nov 15 02:30:58 2011, kivinen@iki.fi wrote: > > Pearl Liang via RT writes: > > > Resending this... > > > > Some of the earlier ones had ended my spam folder, so didn't notice > > them... > > > > > On Wed Oct 12 11:34:48 2011, pearl.liang wrote: > > > > Hi, Tero, > > > > > > > > I've updated the registry. Please see: > > > > > > > > http://www.iana.org/assignments/sigtran-adapt > > > > I assume you mean > > > > http://www.iana.org/assignments/isakmp-registry > > > > and > > > > http://www.iana.org/assignments/ipsec-registry > > > > I do not think that sigtran-adapt registry has anything for me... > > > > > > Updates include: > > > > > > > > - added a pointer to the ipsec-registry for Group Description > > (Value 3) > > > > - updated the Registration Procedures for Sub-registry: > > Compression > > > > Private Algorithm (Value 9) > > > > These seem to be ok. > > > > > > There were some remaining questions prefixed with [pl] below for > > > > the following registries Paul proposed: > > > > > > > > - Exchange Type -- RFC 2408, section 3.1 > > > > - Certificate Encoding -- RFC 2408, section 3.9 > > > > - Notify Message Types -- RFC 2408, section 3.14.1 (subregistries: > > Error > > > > Types and Status Types) (Note: this is different from IPSEC Notify > > Message > > > > Types) > > > > See my comments later for these. > > > > > > > > > > Please let us know what we can do. > > > > > > > > Thank you, > > > > ~pearl > > > > > > > > > > > > On Tue Sep 27 14:35:47 2011, pearl.liang wrote: > > > > > Hi, Tero, > > > > > > > > > > i too apologize not responding earlier. Thank you though for > > > > > your helpful comments below about the variations between > > > > > the two registries, isakmp-registry and ipsec-registry. :( > > > > > My comments with the prefix [pl] are inline to make sure i > > understand > > > > > the changes that need to be made to the registry. If not, > > please > > > > > correct me. > > > > > > > > > > On Tue Sep 06 07:20:30 2011, kivinen@iki.fi wrote: > > > > > > Pearl Liang via RT writes: > > > > > > > resending this...(sorry). Please advise what changes we can > > make > > > > > > > to the registry. Questions are included in the below > > message. > > > > > > > > > > > > Sorry, I have been bit busy... > > > > > > > > > > > > > > > > > On Fri Jul 15 13:42:20 2011, pearl.liang wrote: > > > > > > > > > > >> Hello Tero, Sean and Stephen, > > > > > > > > > > >> > > > > > > > > > > >> We are working some old tickets. We received some > > edits > > > > > > from Paul > > > > > > > > > > Hoffman > > > > > > > > > > >> for the registry ISAKMP registry at > > > > > > > > > > >> http://www.iana.org/assignments/isakmp-registry. > > > > > > > > > > >> We are contacting you as the expert/ADs for this > > > > > parameter. > > > > > > > > > > Apologies in > > > > > > > > > > >> advance...this is a long message. > > > > > > > > > > >> > > > > > > > > > > >> Paul Hoffman's proposed changes are included in the > > below > > > > > > original > > > > > > > > > > >> message. Before we include his proposed changes, > > can you > > > > > > help to > > > > > > > > > > clarify > > > > > > > > > > >> the below questions and whether these changes are > > okay > > > > > and > > > > > > should > > > > > > > > > > be added > > > > > > > > > > >> to the registry. Any assistance you can provide is > > much > > > > > > > > > > appreciated. > > > > > > > > > > >> > > > > > > > > > > >> QUESTIONS: > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> Issue 1: RFCs 2407, 2408, and 2409 were all > > obsoleted by > > > > > > > > > > >> 4306, which defines Internet Key Exchange Version 2 > > > > > (IKEv2) > > > > > > > > > > >> Parameters. > > > > > > > > > > >> > > > > > > > > > > >> Question: should the registry be updated to 4306 > > for all > > > > > > > > > > >> references of 2407, 2408, and 2409? > > > > > > > > > > > > No. The IKEv1 and IKEv2 has completely separate registries, > > and > > > > > > RFC4306 created completely new set of registries and even when > > it > > > > > did > > > > > > copy quite a lot of values from the existing IKEv1 registries, > > new > > > > > > allocations needs to be done separately in both registries if > > > > > needed. > > > > > > > > > > > > Also note, that there is two sets of registries for IKEv1. The > > > > > > isakmp-registry and the ipsec-registry (also called Internet > > Key > > > > > > Exchange (IKE) attributes). > > > > > > > > > > > > The difference between those two registries is bit messy. The > > > > > > ipsec-registry is meant for parameters used for the IKE Phase > > 1 > > > > > > negotiation when you do not want to use the IPsec DOI (domain > > of > > > > > > interpretation). The isakmp-registry is used when using IPsec > > DOI > > > > > > (rfc2407). > > > > > > > > > > > > So in general the ipsec-registry is used for the IKEv1 phase 1 > > (i.e. > > > > > > when negotiating the IKE SA), and the isakmp-registry is used > > for > > > > > the > > > > > > IKEv2 Phase 2 (i.e. when negotiating Child SA or ESP/AH SA). > > > > > > > > > > > > > > > > [pl] OK, i'll not make any updates to that. > > > > > > > > > > > > > > > >> Issue 2: Paul proposed the following registration > > for > > > > > Group > > > > > > > > > > >> Description (Value 3) under IPSEC Security > > Association > > > > > > > > > > >> Attributes: > > > > > > > > > > >> > > > > > > > > > > >> Sub-registry: Group Description (Value 3) > > > > > > > > > > >> Reference: [RFC2407]?? > > > > > > > > > > >> Registration Procedures: ??? > > > > > > > > > > >> > > > > > > > > > > >> Name Value Reference > > > > > > > > > > >> ---- ----- --------- > > > > > > > > > > >> First Oakley Group 1 [RFC2409] > > > > > > > > > > >> Second Oakley Group 2 [RFC2409] > > > > > > > > > > >> Third Oakley Group 3 [RFC2409] > > > > > > > > > > >> Fourth Oakley Group 4 [RFC2409] > > > > > > > > > > >> Fifth Oakley Group 5 [RFC2409] > > > > > > > > > > >> > > > > > > > > > > >> It appears that the Attribute Class 'Group > > Description' > > > > > was > > > > > > > > > > >> defined as value #4 in RFC 2409. Also, I cannot > > locate > > > > > > > > > > >> Fifth Oakley Group in RFC > > > > > > > > > > >> 2409. > > > > > > > > > > > > The RFC2409 refers to the ipsec-registry where it has value of > > 3. > > > > > The > > > > > > isakmp-registry defines same parameter (but with value of 3) > > and > > > > > > refers to the RFC2409 for the values: > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Group Description > > > > > > > > > > > > Specifies the Oakley Group to be used in a PFS QM > > > > > > negotiation. For a list of supported values, see > > > > > Appendix > > > > > > A > > > > > > of [IKE]. > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > Most of the implementations I know actually assume that the > > this > > > > > Group > > > > > > Description (Value 3) registry in isakmp-registry is sharing > > same > > > > > > values than the Group Description (Value 4) registry in the > > > > > > ipsec-registry. > > > > > > > > > > > > The ipsec-registry has much more values than what is mentioned > > in > > > > > > Paul's message. > > > > > > > > > > > > The 5th group (1536 bit MODP group) was originally described > > as > > > > > email > > > > > > message to the ipsec list and implementors added it to their > > code > > > > > way > > > > > > before it was officially documented. This oversigth was fixed > > when > > > > > > RFC3526 was published. The RFC3526 documented the existing > > 1536 > > > > > group > > > > > > and added several others. > > > > > > > > > > > > > > > > >> Question: Should we add the above to the registry? > > And if > > > > > > > > > > >> so, what should we put in the registration > > procedures? > > > > > > > > > > > > I think it would be better to add pointer to the Group > > Description > > > > > > (Value 4) of the ipsec-registry instead as this is what > > > > > > implementations currently do. > > > > > > > > > > > > > > > > [pl] i can add a pointer to the ipsec-registry in the isakmp- > > registry. > > > > > Specifically, I can add the pointer to the Group Description > > (Value 4) > > > > > of the ipsec-registry when the registry is being converted to a > > source > > > > > of XML later. > > > > > > > > > > > > > > > >> Issue 3: It appears that new values of a sub- > > registry > > > > > > > > > > >> Compression Private Algorithm will be defined and > > > > > assigned > > > > > > > > > > >> by IEEE as noted in RFC 2407: > > > > > > > > > > >> > > > > > > > > > > >> Sub-registry: Compression Private Algorithm (Value > > 9) > > > > > > > > > > >> Reference: [RFC2407] > > > > > > > > > > >> Registration Procedures: ??? > > > > > > > > > > >> Note: > > > > > > > > > > >> Specifies a private vendor compression algorithm. > > The > > > > > > first > > > > > > > > > > >> three (3) octets must be an IEEE assigned > > company_id > > > > > (OUI). > > > > > > > > > > >> The next octet may be a vendor specific compression > > > > > > subtype, > > > > > > > > > > >> followed by zero or more octets of vendor data. > > > > > > > > > > >> > > > > > > > > > > >> Registry: > > > > > > > > > > >> Value Description Reference > > > > > > > > > > >> ----- ---------------- --------- > > > > > > > > > > >> There are no registrations at this time > > > > > > > > > > >> > > > > > > > > > > >> Question: does the above look correct? And if so, > > what > > > > > > > > > > >> should we put in the registration procedures field? > > > > > > > > > > > > As this is private vendor specific numbers and it is already > > using > > > > > > IEEE assigned company_id to make sure there are no overlaps, I > > think > > > > > > the best would be to say that "IANA does not assign" in the > > > > > > Registration Procedures. > > > > > > > > > > > > > > > > [pl] will do. > > > > > > > > > > > > > > > >> Issue 4: The following registries Paul proposed (in > > his > > > > > > > > > > >> message) that are not currently listed in > > > > > > > > > > >> http://www.iana.org/assignments/isakmp-registry: > > > > > > > > > > >> > > > > > > > > > > >> - Exchange Type -- RFC 2408, section 3.1 > > > > > > > > > > > > As exchange types are not strictly part of the DOI I think > > those > > > > > > should be in the ipsec-registry, and there is already registry > > for > > > > > > those in there: > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Registry Name: Additional Exchanges Defined-- XCHG values > > > > > > Reference: [RFC2409] > > > > > > Registration Procedures: Not defined > > > > > > > > > > > > Value Phase Reference > > > > > > ------ --------------- --------- > > > > > > 32 Quick Mode [RFC2409] > > > > > > 33 New Group Mode [RFC2409] > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > It does not have values of the original exchange types defined > > in > > > > > the > > > > > > RFC2408. The RFC2408 defines those as: > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > o Exchange Type (1 octet) - indicates the type of > > exchange > > > > > being > > > > > > used. This dictates the message and payload orderings > > in the > > > > > > ISAKMP exchanges. > > > > > > > > > > > > > > > > > > Exchange Type Value > > > > > > NONE 0 > > > > > > Base 1 > > > > > > Identity Protection 2 > > > > > > Authentication Only 3 > > > > > > Aggressive 4 > > > > > > Informational 5 > > > > > > ISAKMP Future Use 6 - 31 > > > > > > DOI Specific Use 32 - 239 > > > > > > Private Use 240 - 255 > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > I.e. those new values are allocated from the DOI specific use > > range, > > > > > > even when they are not really DOI specific as there is no DOI > > field > > > > > in > > > > > > the message where they are used, so I do not know how overlaps > > with > > > > > > DOI specific use numbers should be handled. > > > > > > > > > > > > One option is to assume that as they are allocated in the DOI > > > > > specific > > > > > > use range, the current registry from ipsec-registry should be > > moved > > > > > to > > > > > > the isakmp-registry, but as I think it more logically belongs > > to the > > > > > > ipsec-registry, I would keep it there. > > > > > > > > > > > > > > > > [pl] OK, no action is required in the isakmp-registry. As for > > ipsec- > > > > > registry, > > > > > should we update the existing registry 'Additional Exchanges > > Defined-- > > > > > XCHG > > > > > values' to include the above defined range (0-255)? > > > > > What is the registration procedure? > > > > No, I think it requres new registry and the additional exchanges is > > part of that, i.e. it is that DOI Specific Use 32-239 in the Exchange > > Type registry. > > > > This new registry should be: > > > > ---------------------------------------------------------------------- > > Registry Name: Exchange Type > > Reference: [RFC2408] > > > > Value Exchange Type Reference > > ----- ------------------ --------- > > 0 NONE [RFC2408] > > 1 Base [RFC2408] > > 2 Identity Protection [RFC2408] > > 3 Authentication Only [RFC2408] > > 4 Aggressive [RFC2408] > > 5 Informational [RFC2408] > > > > ---------------------------------------------------------------------- > > > > Registration procedure depends on the values: > > > > ISAKMP Future Use 6 - 31 > > DOI Specific Use 32 - 239 > > Private Use 240 - 255 > > > > That DOI Specific use is the Additional Exchanges Defined registry > > already in the ipsec-registry. > > > > > > > > > > > > >> - Certificate Encoding -- RFC 2408, section 3.9 > > > > > > > > > > > > This again would be better part of the ipsec-registry not > > > > > > isakmp-registry as again this is phase 1 concept not phase 2 > > (or > > > > > IPsec > > > > > > SA related) concept. > > > > > > > > > > > > Actually I think all RFC2408 related stuff belongs to the > > > > > > ipsec-registry, not isakmp-registry. > > > > > > > > > > > > This include already some registries which are now in the > > > > > > isakmp-registry, i.e. ISAKMP Domain of Interpretation (DOI) > > > > > > and Next Payload Types. Those should really be moved to the > > > > > > ipsec-registry (i.e. phase 1 or IKE registry) from the isakmp- > > > > > registry > > > > > > (the phase 2 or Child SA for IPsec registry). > > > > > > > > > > > > > > > > [pl] so, we should move both ISAKMP Domain of Interpretation > > (DOI) > > > > > and Next Payload Types to the ipsec-registry. Correct? And, is > > > > Yes, and add that certificate encoding registry. > > > > > > > 65535 the max value for ISAKMP Domain of Interpretation (DOI)? > > > > No, it is 32-bit value, i.e. max value is 4294967295. > > > > > > > > > > > > >> - Notify Message Types -- RFC 2408, section 3.14.1 > > > > > > > > > > >> (subregistries: Error Types and Status Types) > > (Note: > > > > > this > > > > > > > > > > >> is different from IPSEC Notify Message Types) > > > > > > > > > > > > This base registry should be in the ipsec-registry not in the > > > > > > isakmp-registry. The values already in the IPSEC Notify > > Message > > > > > Types > > > > > > in the isakmp-registry should stay there, as they are Child SA > > > > > > specific (i.e. from RFC2407), but the base notify registry > > should be > > > > > > in the phase 1 registry. > > > > > > > > > > > > > > > > [pl] How about add a pointer to the sub-registry 'IPSEC Notify > > Message > > > > > Types' of the isakmp-registry to the ipsec-registry? > > > > There is need to add the base registry to the ipsec-registry, and that > > includes numbers between 0-8191 and 16384-24575. > > > > Registry would be: > > ---------------------------------------------------------------------- > > Registry Name: Notify Message Types > > Reference: [RFC2408] > > > > Subregistries procedures are: > > > > 31 - 8191 Error types RESERVED (Future Use) > > 8192 - 16383 Doi-Specific Error types > > 16385 - 24575 Status types RESERVED (Future Use) > > 24576 - 32767 DOI-specific Status codes > > 32768 - 40959 Private Use > > 40960 - 65535 RESERVED (Future Use) > > > > Sub-Registry: Notify Messages - Error Types > > > > Value Notify Messages - Error Types Reference > > ----- ----------------------------- --------- > > 1 INVALID-PAYLOAD-TYPE [RFC2408] > > 2 DOI-NOT-SUPPORTED [RFC2408] > > 3 SITUATION-NOT-SUPPORTED [RFC2408] > > 4 INVALID-COOKIE [RFC2408] > > 5 INVALID-MAJOR-VERSION [RFC2408] > > 6 INVALID-MINOR-VERSION [RFC2408] > > 7 INVALID-EXCHANGE-TYPE [RFC2408] > > 8 INVALID-FLAGS [RFC2408] > > 9 INVALID-MESSAGE-ID [RFC2408] > > 10 INVALID-PROTOCOL-ID [RFC2408] > > 11 INVALID-SPI [RFC2408] > > 12 INVALID-TRANSFORM-ID [RFC2408] > > 13 ATTRIBUTES-NOT-SUPPORTED [RFC2408] > > 14 NO-PROPOSAL-CHOSEN [RFC2408] > > 15 BAD-PROPOSAL-SYNTAX [RFC2408] > > 16 PAYLOAD-MALFORMED [RFC2408] > > 17 INVALID-KEY-INFORMATION [RFC2408] > > 18 INVALID-ID-INFORMATION [RFC2408] > > 19 INVALID-CERT-ENCODING [RFC2408] > > 20 INVALID-CERTIFICATE [RFC2408] > > 21 CERT-TYPE-UNSUPPORTED [RFC2408] > > 22 INVALID-CERT-AUTHORITY [RFC2408] > > 23 INVALID-HASH-INFORMATION [RFC2408] > > 24 AUTHENTICATION-FAILED [RFC2408] > > 25 INVALID-SIGNATURE [RFC2408] > > 26 ADDRESS-NOTIFICATION [RFC2408] > > 27 NOTIFY-SA-LIFETIME [RFC2408] > > 28 CERTIFICATE-UNAVAILABLE [RFC2408] > > 29 UNSUPPORTED-EXCHANGE-TYPE [RFC2408] > > 30 UNEQUAL-PAYLOAD-LENGTHS [RFC2408] > > > > > > Sub-Registry: Notify Messages - Status Types > > > > Value Notify Messages - Status Types Reference > > ----- ------------------------------ --------- > > 16384 CONNECTED [RFC2408] > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > >> - ISAKMP Security Association Attributes -- RFC > > 2408, > > > > > > > > > > >> Appendix A (This isn't really a registry; this > > is a > > > > > > note) > > > > > > > > > > > > This does not belong to the isakmp-registry. It does not > > really > > > > > belong > > > > > > to the ipsec-registry either. I would ignore this completely. > > As far > > > > > > as I know nobody uses the values defined in that appendix. > > > > > > > > > > > > > > > > [pl] OK. > > > > > > > > > > > > > > > >> Question: should we add them? > > > > > > > > > > > > I would not add them to isakmp-registry, but add them (when > > needed) > > > > > to > > > > > > the isakmp-registry. > > > > > > > > > > > > > > > > >>> -------- Original Message -------- > > > > > > > > > > >>> Subject: Proposed changes to the ISAKMP registry > > > > > > > > > > >>> Date: Wed, 6 Mar 2002 20:00:54 -0800 > > > > > > ^^^^ > > > > > > > > > > > > Wow, this is old. And I though I am slow to respond... :-) > > > > > > > -- kivinen@iki.fi From nbn@cisco.com Tue Jan 10 05:48:05 2012 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 1210021F8649 for ; Tue, 10 Jan 2012 05:48:05 -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 jgHVhnOK4hP7 for ; Tue, 10 Jan 2012 05:48:04 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id DBEC021F8644 for ; Tue, 10 Jan 2012 05:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nbn@cisco.com; l=762; q=dns/txt; s=iport; t=1326203284; x=1327412884; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=LFrV/W0jBMDLYhmlwidm+M6JT9417JVLJ90qRq0LCRQ=; b=b6z/HLA+Ql8QS6jHP48oK1hEcC/SmamdBOBO6kKoKecDfZpXYhZWa/fY a82ziDT8sJjtxDLegtca0v0mdF7tiVAZAguCNoJPUx9IqI4DEEX/EMF5M hEWZ3WtMmjO/Y9qCASgGXqQUSh7EE/9DEAF7vlkx8CD0yvsz7jrBKgULo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EABJBDE9Io8UY/2dsb2JhbABDrWCBcwEBBBIBHQpPAgEqBhgGAVYBAQQLEBMHoCcBnjOId4I5YwSIOJ8W X-IronPort-AV: E=Sophos;i="4.71,487,1320624000"; d="scan'208";a="3121279" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 10 Jan 2012 13:48:02 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0ADm2it023114 for ; Tue, 10 Jan 2012 13:48:02 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Jan 2012 19:18:02 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jan 2012 19:18:01 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CPU usage for IPSec in Linux 2.6.38 Thread-Index: Acy+4VnthrWWVr78Rb+metu6uX0peAQuYYyQ References: <20203.19901.967544.547378@fireball.kivinen.iki.fi> From: "Naveen B N (nbn)" To: X-OriginalArrivalTime: 10 Jan 2012 13:48:02.0134 (UTC) FILETIME=[788F4760:01CCCF9E] Subject: [IPsec] CPU usage for IPSec in Linux 2.6.38 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, 10 Jan 2012 13:48:05 -0000 Hi All, I am using linux 2.6.36 kernel and trying to add 6000 Ikev2/ipsec tunnels=20 at 20 Ikev2 messages per second , I am using netlink socket which is set to=20 NON_BLOCKING and i am sending XFRM SPD added for every successful AUTH message received. But the problem is after the 4000 tunnels are established, CPU usage goes=20 to > 90%, which will likely cause dropping of few AUTH response from responder. NOTE: But when I disabled adding SPD messaged via netlink sockets using xfrm messages, I am able to complete 6000 ikev2 SA negotiation successfully. So the problem i am seeing is when sending XFRM netlink message > 4000. Any solutions are or analysis different then the above is appreciated. Thanks and Regards Naveen=20 From Paul_Koning@Dell.com Tue Jan 10 06:51:40 2012 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 4900821F850B for ; Tue, 10 Jan 2012 06:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqgm4bQkNIkY for ; Tue, 10 Jan 2012 06:51:39 -0800 (PST) Received: from ausxippc101.us.dell.com (ausxippc101.us.dell.com [143.166.85.207]) by ietfa.amsl.com (Postfix) with ESMTP id BFD9D21F84F7 for ; Tue, 10 Jan 2012 06:51:39 -0800 (PST) X-Loopcount0: from 10.175.216.251 From: To: , Date: Tue, 10 Jan 2012 08:51:36 -0600 Thread-Topic: CPU usage for IPSec in Linux 2.6.38 Thread-Index: Acy+4VnthrWWVr78Rb+metu6uX0peAQuYYyQAAMazIA= Message-ID: <09787EF419216C41A903FD14EE5506DD030F1A4FDA@AUSX7MCPC103.AMER.DELL.COM> References: <20203.19901.967544.547378@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] CPU usage for IPSec in Linux 2.6.38 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, 10 Jan 2012 14:51:40 -0000 This is the IPSec standard mailing list. You're talking about a question a= bout some specific implementation; you'll have to ask in a different place. paul -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of N= aveen B N (nbn) Sent: Tuesday, January 10, 2012 8:48 AM To: ipsec@ietf.org Subject: [IPsec] CPU usage for IPSec in Linux 2.6.38 Hi All, I am using linux 2.6.36 kernel and trying to add 6000 Ikev2/ipsec tunnels a= t 20 Ikev2 messages per second , I am using netlink socket which is set to = NON_BLOCKING and i am sending XFRM SPD added for every successful AUTH mess= age received. But the problem is after the 4000 tunnels are established, CPU usage goes t= o > 90%, which will likely cause dropping of few AUTH response from respond= er. NOTE: But when I disabled adding SPD messaged via netlink sockets using xfrm mess= ages, I am able to complete 6000 ikev2 SA negotiation successfully. So the problem i am seeing is when sending XFRM netlink message > 4000. Any solutions are or analysis different then the above is appreciated. Thanks and Regards Naveen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From wwwrun@ietfa.amsl.com Tue Jan 10 09:37:32 2012 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 19DA121F87B4; Tue, 10 Jan 2012 09:37:32 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120110173732.19DA121F87B4@ietfa.amsl.com> Date: Tue, 10 Jan 2012 09:37:32 -0800 (PST) Cc: ipsec@ietf.org, paul.hoffman@vpnc.org Subject: [IPsec] WG Action: RECHARTER: IP Security Maintenance and Extensions (ipsecme) 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, 10 Jan 2012 17:37:32 -0000 The IP Security Maintenance and Extensions (ipsecme) working group in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. IP Security Maintenance and Extensions (ipsecme) ------------------------------------- Current Status: Active Chairs: Paul Hoffman Yaron Sheffer Security Area Directors: Stephen Farrell Sean Turner Security Area Advisor: Sean Turner Mailing List Address: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Description of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4306, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group continues the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions to IPsec, mostly to IKEv2. The working group also serves as a focus point for other IETF Working Groups who use IPsec in their own protocols. The current work items include: 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, and so on. The IPsecME Working Group will handle this large scale VPN problem by: * Creating a problem statement document including use cases, definitions and proper requirements for discovery and updates. This document would be solution-agnostic. * Publishing 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. * Reviewing and help publish Informational documents describing current vendor proprietary solutions. This charter will expire in January 2014 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Goals and Milestones: Nov 2012 IETF Last Call on large scale VPN use cases Jun 2013 IETF Last Call on large scale VPN protocol From nbn@cisco.com Tue Jan 10 16:59:09 2012 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 6868B11E80A4 for ; Tue, 10 Jan 2012 16:59:09 -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 nUu9+ltJacUK for ; Tue, 10 Jan 2012 16:59:08 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4062F11E8099 for ; Tue, 10 Jan 2012 16:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=nbn@cisco.com; l=794; q=dns/txt; s=iport; t=1326243548; x=1327453148; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=UKOHX2Kbi/xMUc2fXYF4Iw35nFdVTdYXO7a6v610f6I=; b=jrZKYS79pFRWpubrK4mzRzGmwwKAA0Hqz1l29C0DdXWSmHcddPUTx9cx jO+nn9PITm4GXaoVVzI99C3cUNIsdZJ7IQ4vFcc9/9Gsc/JvIYTIB8JL9 JyUVB7i3kWUHhCw3pqcb5PddnR/kr6LGYDd8VZMr59luCO9oZHmgREEt9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAMDdDE9Io8UY/2dsb2JhbABDrV6BcgEBAQQSAR0KNAsMBAIBCBEEAQELBhcBBgEbKgkIAQEECwgIEQmHYJhaAZEbjHSId4I5YwSGcoFGmC+GZw X-IronPort-AV: E=Sophos;i="4.71,490,1320624000"; d="scan'208";a="3141603" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 11 Jan 2012 00:59:06 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0B0x6np023456; Wed, 11 Jan 2012 00:59:06 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 06:29:06 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jan 2012 06:29:03 +0530 Message-ID: In-Reply-To: <27656.1326211080@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPSec] CPU usage for IPSec in Linux 2.6.38 Thread-Index: AczPsKWzYRSJqezwSn+heaikbNSTuAAS16lA References: <20203.19901.967544.547378@fireball.kivinen.iki.fi> <27656.1326211080@marajade.sandelman.ca> From: "Naveen B N (nbn)" To: X-OriginalArrivalTime: 11 Jan 2012 00:59:06.0309 (UTC) FILETIME=[37E0CF50:01CCCFFC] Cc: ipsec@ietf.org Subject: Re: [IPsec] [IPSec] CPU usage for IPSec in Linux 2.6.38 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, 11 Jan 2012 00:59:09 -0000 I apologies for posting in the wrong mailing list. Regards Naveen=20 -----Original Message----- From: mcr@sandelman.ca [mailto:mcr@sandelman.ca]=20 Sent: Tuesday, January 10, 2012 9:28 PM To: Naveen B N (nbn) Subject: Re: [IPsec] CPU usage for IPSec in Linux 2.6.38 Naveen, please talk to your line manager about what the purpose of ipsec@IETF.org is. If they don't know, then try fred@cisco.com. --=20 ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition.=20 From manav.bhatia@alcatel-lucent.com Wed Jan 11 06:55:55 2012 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 82FC521F8629 for ; Wed, 11 Jan 2012 06:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 GhyMcVwIOmfS for ; Wed, 11 Jan 2012 06:55:55 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8C021F8616 for ; Wed, 11 Jan 2012 06:55:54 -0800 (PST) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q0BEtoK8027646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jan 2012 08:55:52 -0600 (CST) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0BEtmW3029479 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Jan 2012 20:25:49 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 11 Jan 2012 20:25:49 +0530 From: "Bhatia, Manav (Manav)" To: Tero Kivinen Date: Wed, 11 Jan 2012 20:25:47 +0530 Thread-Topic: [IPsec] Avoiding Authentication Header (AH) Thread-Index: AczLuyC/EgUphpP2QVSlneRcOtGfCAEtPs6w Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A3767@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <20229.44292.629825.7429@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8350D028A2D56@INBANSXCHMBSA1.in.alcatel-lucent.com> <20229.48028.145994.197136@fireball.kivinen.iki.fi> In-Reply-To: <20229.48028.145994.197136@fireball.kivinen.iki.fi> 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.39 Cc: IPsec ME WG List Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 11 Jan 2012 14:55:55 -0000 Hi Tero, [clipped] > And why would routing protocols need to use WESP, I would assume=20 > they use ESP-NULL instead. In addition if you use manual keying=20 Sigh. We've gone through this before I think on the KARP mailing list (am n= ot sure though). Routing protocols could "potentially" use WESP since they need to prioritiz= e certain control protocols over the other protocol packets (like OSPF hell= os and acks over other OSPF packets). Using WESP just makes deep inspection= easy. One could argue that routers know that incoming ESP-NULL packets are= not "encrypted" since they are the end points, however, that means that ro= uters need to install filter rules per SPI values, which is not scalable. S= o, while ESP-NULL *would* work, WESP just makes it a tad easier. Cheers, Manav From pkampana@cisco.com Fri Jan 13 14:57:41 2012 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 EB9DD1F0C44 for ; Fri, 13 Jan 2012 14:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_65=0.6, MANGLED_TOOL=2.3, 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 nlVw4QsVm6El for ; Fri, 13 Jan 2012 14:57:41 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4021F0C3D for ; Fri, 13 Jan 2012 14:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=1215; q=dns/txt; s=iport; t=1326495461; x=1327705061; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=fMdK3NdfkKZU8+WRmpZUVILVAlIQy/5XA3KIGsVFkBw=; b=EkmauVEQ/EY2A2LozmdOAgxYzCut63fJrSxkQKny/4lwWXBAmElcVPFG RASkdmSZvXXgPSP7mDAUz186l9Q8TJjFKJrJRfqaeZI10vkFk21gmvSix Tga0guaDLSdZTK1EsATDpc4LDsBWZ1RFbh1KQeGCDA3A20NeF+ViI3N1l Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABu2EE+tJV2Y/2dsb2JhbABCnliOWoEFgXIBAQEEAQEBBQoBFQIQNAsMAQMCCQ4BAgQBAQEnBxkOHwkIAQEEARILCQ6HYJhzAZ4mBIwdBIg8hH+aNA X-IronPort-AV: E=Sophos;i="4.71,507,1320624000"; d="scan'208";a="51081449" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 13 Jan 2012 22:57:40 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0DMveuO016342; Fri, 13 Jan 2012 22:57:40 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Jan 2012 16:57:40 -0600 Received: from WINICH1QO6NCS6 ([64.102.221.225]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 13 Jan 2012 16:57:40 -0600 From: "Panos Kampanakis" To: "'Dan Harkins'" , "Tero Kivinen" References: <7C362EEF9C7896468B36C9B79200D8350D028A2953@INBANSXCHMBSA1.in.alcatel-lucent.com><6442.1325686562@marajade.sandelman.ca><7C362EEF9C7896468B36C9B79200D8350D028A2AE5@INBANSXCHMBSA1.in.alcatel-lucent.com><4F05197A.9090505@ieca.com><7C362EEF9C7896468B36C9B79200D8350D028A2C92@INBANSXCHMBSA1.in.alcatel-lucent.com><20229.45642.477101.356308@fireball.kivinen.iki.fi> <8ddf32c400110c28909960366274f61f.squirrel@www.trepanning.net> In-Reply-To: <8ddf32c400110c28909960366274f61f.squirrel@www.trepanning.net> Date: Fri, 13 Jan 2012 17:57:16 -0500 Organization: Cisco Systems Inc. Message-ID: <003301ccd246$b2301120$16903360$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczLxlJVLC0sWIbxRnyt3j7dQD4yfwGf7lbQ Content-Language: en-us X-OriginalArrivalTime: 13 Jan 2012 22:57:40.0435 (UTC) FILETIME=[C065EA30:01CCD246] Cc: ipsec@ietf.org, "Bhatia, Manav \(Manav\)" Subject: Re: [IPsec] Avoiding Authentication Header (AH) 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, 13 Jan 2012 22:57:42 -0000 Agreed. Summarizes my opinion too. Panos -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Dan Harkins Sent: Thursday, January 05, 2012 11:23 AM To: Tero Kivinen Cc: ipsec@ietf.org; Bhatia,Manav (Manav) Subject: Re: [IPsec] Avoiding Authentication Header (AH) On Thu, January 5, 2012 6:23 am, Tero Kivinen wrote: > Bhatia, Manav (Manav) writes: [snip] >> If a WG ends up mandating AH (when ESP could have been used) then >> Yes it's a problem for everyone, right from the vendors to the >> users, who have to now support AH too in their products and >> networks. > > If WG wants to mandate AH, and we cannot convince them otherwise, > having a document which says so does not help. On the other hand if we > have stealth WG trying to sneak AH past IPsec community, I think they > will also conviently ignore this document too. > > In summary I do not think there is problem, and I do not think we need > to say anything about AH right now. Indeed! I agree 100%. Me too. +1. Etc. Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From mnmbhutta1@gmail.com Mon Jan 16 07:33:07 2012 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 06EE921F8682 for ; Mon, 16 Jan 2012 07:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_50=0.001, 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 A7-doVS0ja4K for ; Mon, 16 Jan 2012 07:33:06 -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 4701621F867E for ; Mon, 16 Jan 2012 07:33:06 -0800 (PST) Received: by eeit10 with SMTP id t10so987708eei.31 for ; Mon, 16 Jan 2012 07:33:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=qTE+xhnJWbltR8uSBWR1hom6GhdLb11uXYbtTsRD9tY=; b=VW3tOpneJk2VM2Zjx3A7AGljQEpIC63fERuMkxswnV2nZgZ8bL5ny6XypnbDp9Dw8S L6wpA0iNiGUBZoh/aYVyxE3MoLleERcGsiwvRdyyrqXYAYlmPOk4lHbnrjZ3Q0Q8ZNP0 auSiO8Vj7EqygMNsGqf14m8YOusrdHulFXypY= MIME-Version: 1.0 Received: by 10.213.31.147 with SMTP id y19mr3026681ebc.80.1326727985467; Mon, 16 Jan 2012 07:33:05 -0800 (PST) Received: by 10.213.28.18 with HTTP; Mon, 16 Jan 2012 07:33:05 -0800 (PST) Date: Mon, 16 Jan 2012 15:33:05 +0000 Message-ID: From: Nasir Bhutta To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=0015174c11dc49901c04b6a6ee46 Cc: h.cruickshank@surrey.ac.uk, Angelos Keromytis , Tero Kivinen Subject: [IPsec] IPsec Implementations in LInux Kernels 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, 16 Jan 2012 15:34:40 -0000 --0015174c11dc49901c04b6a6ee46 Content-Type: text/plain; charset=ISO-8859-1 Hi, We are working on a project where we need to modify the IPsec behaviour in linux kernel by programming.. We shall have to modify program for actual IPsec working, ESP Header, SPD and SAD databases access working ... I am wandering for following information: 1- What are the current linux IPsec implementations in different Linux flavours: (Ubuntu, Fedora, Chrome Linux etc). 2- Any further information (technical documentation) can be find on technical implementation of IPsec. Any level of help shall be appreciated.. With many thanks.. Kind Regards, Nasir --0015174c11dc49901c04b6a6ee46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=A0
We are working on a project where we need to modify the IPsec be= haviour in linux kernel by programming..=A0

We sha= ll have to modify program for actual IPsec working, ESP Header, SPD and SAD= databases access working ...

I am wandering for following information:=A0
=
1- What are the current linux IPsec implementations in diffe= rent Linux flavours: (Ubuntu, Fedora, Chrome Linux etc).=A0
2- An= y further information (technical documentation) can be find on technical im= plementation of IPsec.=A0

Any level of help shall be appreciated..=A0
<= br>
With many thanks..=A0

Kind Regards,<= /div>
Nasir
--0015174c11dc49901c04b6a6ee46-- From paul@nohats.ca Mon Jan 16 12:32:08 2012 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 022B021F8605 for ; Mon, 16 Jan 2012 12:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.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 895mI4sHCDvf for ; Mon, 16 Jan 2012 12:32:07 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 885B321F8575 for ; Mon, 16 Jan 2012 12:32:06 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 4628480828; Mon, 16 Jan 2012 15:31:39 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q0GKVbJN009650; Mon, 16 Jan 2012 15:31:37 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 16 Jan 2012 15:31:37 -0500 (EST) From: Paul Wouters To: Nasir Bhutta In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT X-Mailman-Approved-At: Tue, 17 Jan 2012 08:03:49 -0800 Cc: ipsec@ietf.org, h.cruickshank@surrey.ac.uk, Tero Kivinen , Angelos Keromytis Subject: Re: [IPsec] IPsec Implementations in LInux Kernels 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, 16 Jan 2012 21:09:56 -0000 On Mon, 16 Jan 2012, Nasir Bhutta wrote: > Hi, We are working on a project where we need to modify the IPsec behaviour in linux kernel by programming..  > > We shall have to modify program for actual IPsec working, ESP Header, SPD and SAD databases access working ... > > I am wandering for following information:  > > 1- What are the current linux IPsec implementations in different Linux flavours: (Ubuntu, Fedora, Chrome Linux etc).  > 2- Any further information (technical documentation) can be find on technical implementation of IPsec.  NETKEY is the BSD/KAME based stack with NETLINK/XFRM for Linux. This is in the default linux tree. KLIPS is the freeswan/openswan based stack with PFKEY. It is not in the default linux tree, but kmod packages and ubuntu deb packages exist. both stacks have different levels of support for acceleration using multiple CPUs and different vendor support. Apparently there is some userspace stack too that people are working on porting, see the users@openswan.org mailing list. Paul From paul.hoffman@vpnc.org Wed Jan 18 18:08:05 2012 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 3DA0011E80DA for ; Wed, 18 Jan 2012 18:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 7Zq69vH9+wDp for ; Wed, 18 Jan 2012 18:08: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 A58F811E8093 for ; Wed, 18 Jan 2012 18:08:04 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0J283VX055234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 18 Jan 2012 19:08:03 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 18 Jan 2012 18:08:04 -0800 References: <20120119010449.E29DE72E034@rfc-editor.org> To: IPsecme WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [IPsec] Fwd: RFC 6479 on IPsec Anti-Replay Algorithm without Bit Shifting 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, 19 Jan 2012 02:08:05 -0000 Begin forwarded message: > From: rfc-editor@rfc-editor.org > Subject: RFC 6479 on IPsec Anti-Replay Algorithm without Bit Shifting > Date: January 18, 2012 5:04:49 PM PST > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: rfc-editor@rfc-editor.org > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6479 > > Title: IPsec Anti-Replay Algorithm without Bit > Shifting > Author: X. Zhang, T. Tsou > Status: Informational > Stream: Independent > Date: January 2012 > Mailbox: xiangyang.zhang@huawei.com, > tena@huawei.com > Pages: 9 > Characters: 16619 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-zhang-ipsecme-anti-replay-07.txt > > URL: http://www.rfc-editor.org/rfc/rfc6479.txt > > This document presents an alternate method to do the anti-replay > checks and updates for IP Authentication Header (AH) and > Encapsulating Security Protocol (ESP). The method defined > in this document obviates the need for bit shifting and it reduces > the number of times an anti-replay window is adjusted. This document > is not an Internet Standards Track specification; it is > published for informational purposes. > > > 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 hannes.tschofenig@gmx.net Thu Jan 19 07:06:59 2012 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 D471F21F85E5 for ; Thu, 19 Jan 2012 07:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.012 X-Spam-Level: X-Spam-Status: No, score=-102.012 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, 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 8vQiDUxDGZFV for ; Thu, 19 Jan 2012 07:06:59 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id BDE3B21F85CC for ; Thu, 19 Jan 2012 07:06:58 -0800 (PST) Received: (qmail invoked by alias); 19 Jan 2012 15:06:56 -0000 Received: from unknown (EHLO [10.255.135.235]) [192.100.123.77] by mail.gmx.net (mp022) with SMTP; 19 Jan 2012 16:06:56 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/U5n4cr/LUihwYkPIIqwJdae+G1RJR6MOmR4F7OL 7hbtyAr8UcAlTq Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Hannes Tschofenig Date: Thu, 19 Jan 2012 17:06:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: ipsec@ietf.org X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Hannes Tschofenig Subject: [IPsec] Fwd: Smart Object Security Workshop Announcement 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, 19 Jan 2012 15:07:00 -0000 Hi all,=20 at the previous IAB Smart Object workshop Tero gave an interesting = presentation about a minimal IKEv2 implementation suitable for = constrained embedded devices. He also documented some thoughts in an = IETF draft: = http://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-00 Since Tero's code was written in Perl and not used on any real-world = embedded system platform it raised a number of questions about the code = size, performance, etc.=20 In case someone of you had gotten further experience please consider = attending the workshop. =20 Ciao Hannes Begin forwarded message: > From: Hannes Tschofenig > Date: January 19, 2012 2:46:10 PM GMT+02:00 > To: smartobject-participants@lists.i1b.org > Cc: Hannes Tschofenig > Subject: Smart Object Security Workshop Announcement >=20 > Hi all, >=20 > you all have been attending the Smart Object workshop last March in = Prague. We have worked on a follow-up workshop focused on security. It = will take place on the 23rd March 2012 in Paris; it is again attached to = the IETF meeting. >=20 > We are seeking input from participants to share their thoughts about = the ability to utilize existing and widely deployed security mechanisms = for smart objects. >=20 > In particular, we are interested to hear about: > - What techniques for issuing credentials have been deployed? > - What extensions are useful to make existing security protocols more = suitable for smart objects? > - What type of credentials are frequently used? > - What experience has been gained when implementing and deploying = application layer, transport layer, network layer, and link layer = security mechanisms (or a mixture of all of them)? > - How can =93clever=94 implementations make security protocols a = better fit for constrained devices? > - Are there lessons we can learn from existing deployments? >=20 > More workshop details can be found on the webpage of our host: > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ >=20 > If you plan to participate at the workshop please drop us a message = (with a short description of what you are planning to contribute) and we = can give you an early notice regarding your participation.=20 >=20 > It would be great to see you at the workshop and hear your thoughts.=20= >=20 > Ciao > Hannes >=20 From paul.hoffman@vpnc.org Thu Jan 19 14:43:30 2012 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 B322521F8691 for ; Thu, 19 Jan 2012 14:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 7CM55byBDW+6 for ; Thu, 19 Jan 2012 14:43:30 -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 201F521F859F for ; Thu, 19 Jan 2012 14:43:30 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0JMhQjL002253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 19 Jan 2012 15:43:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jan 2012 14:43:28 -0800 Message-Id: To: IPsecme WG Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [IPsec] Starting work on our new charter items 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, 19 Jan 2012 22:43:30 -0000 We have a new charter. Do we have any volunteers to start work on the = two documents we committed to work on? Related: we should consider having a face-to-face meeting at the = upcoming IETF in Paris, but only if there is value for the = newly-chartered work. In my mind, that means both a first draft = submitted *and* interesting questions that would benefit from = face-to-face discussion instead of just work on the list. Do people = believe we will have that? --Paul Hoffman From zong.zaifeng@zte.com.cn Thu Jan 19 22:43:17 2012 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 0FD7421F8591 for ; Thu, 19 Jan 2012 22:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.221 X-Spam-Level: X-Spam-Status: No, score=-95.221 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 MOTVZKW8+r5p for ; Thu, 19 Jan 2012 22:43:16 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 661F321F85D4 for ; Thu, 19 Jan 2012 22:43:15 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566905521606; Fri, 20 Jan 2012 14:19:54 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 69721.5521606; Fri, 20 Jan 2012 14:42:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q0K6gqZI050643 for ; Fri, 20 Jan 2012 14:42:52 +0800 (GMT-8) (envelope-from zong.zaifeng@zte.com.cn) To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zong.zaifeng@zte.com.cn Date: Fri, 20 Jan 2012 14:40:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-20 14:42:53, Serialize complete at 2012-01-20 14:42:53 Content-Type: multipart/alternative; boundary="=_alternative 0024D7B74825798B_=" X-MAIL: mse01.zte.com.cn q0K6gqZI050643 Subject: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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, 20 Jan 2012 06:43:17 -0000 This is a multipart message in MIME format. --=_alternative 0024D7B74825798B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgRm9sa3M6DQoNClRoZXJlIGlzIGEgbmV3IGRyYWZ0IGF2YWlsYWJsZSB0aGF0IHNvbWUgb2Yg eW91IG1heSBiZSBpbnRlcmVzdGVkDQppbiBsb29raW5nIGF0LiANCg0KVGhlIGRyYWZ0IGlzIGF2 YWlsYWJsZSB2aWEgdGhlIGZvbGxvd2luZyBsaW5rOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9k cmFmdC16b25nLWlwc2VjbWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0DQoNClBsZWFzZSBzZW5k IHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QuIFRoYW5rcyENCg0KDQpCUg0KWmFpZmVuZw0KDQoN CiANCi0tLS0tINeqt6LIyyDX2tTat+UwMDgyNDYvdXNlci96dGVfbHRkIMqxvOQgMjAxMi0wMS0y MCAxNDozMyAtLS0tLQ0KDQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgDQoyMDEyLTAxLTE4IDE2 OjA2DQoNCsrVvP7Iyw0Kem9uZy56YWlmZW5nQHp0ZS5jb20uY24NCrOty80NCnpvbmcuemFpZmVu Z0B6dGUuY29tLmNuDQrW98ziDQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXpv bmctaXBzZWNtZS1pa2V2Mi1jcGV4dDRmZW10by0wMC50eHQNCg0KDQoNCg0KDQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC16b25nLWlwc2VjbWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0 IGhhcyBiZWVuIA0Kc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBaYWlmZW5nIFpvbmcgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZTogICAgICAgICAgICAgICAg IGRyYWZ0LXpvbmctaXBzZWNtZS1pa2V2Mi1jcGV4dDRmZW10bw0KUmV2aXNpb246ICAgICAgICAg ICAgICAgICAwMA0KVGl0bGU6ICAgICAgICAgICAgICAgICAgICAgICAgICAgIElLRXYyIENvbmZp Z3VyYXRpb24gUGF5bG9hZCBFeHRlbnNpb24gDQpmb3IgTm90YXJpemluZyBGZW10b2NlbGwgaW4g TW9iaWxlIENvcmUgTmV0d29yaw0KQ3JlYXRpb24gZGF0ZTogICAgICAgICAgICAyMDEyLTAxLTE4 DQpXRyBJRDogICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQpOdW1iZXIgb2YgcGFnZXM6IDEyDQoNCkFic3RyYWN0Og0KICAgSVBTZWMgSUtFdjIsIFJGQyA1 OTk2IFtSRkM1OTk2XSwgaGFzIGJlZW4gYWRvcHRlZCBieSBtYW55DQogICBzdGFuZGFyZGl6ZWQg bmV0d29yayBzb2x1dGlvbnMgdG8gcHJvdmlkZSB0aGUgc2VjdXJlIHRyYW5zcG9ydA0KICAgYmV0 d2VlbiBuZXR3b3JrIGVsZW1lbnRzIG92ZXIgdGhpcmQgcGFydHkmIzM5O3MgaW5mcmFzdHJ1Y3R1 cmUuICBUb2RheQ0KICAgRmVtdG9jZWxsIGRlcGxveW1lbnQgcmVxdWlyZXMgdGhlIG1vYmlsZSBv cGVyYXRvciYjMzk7cyBGZW10b2NlbGwgQVANCiAgIChGQVApIHRvIGxldmVyYWdlIHRoZSBJUFNl YyBJS0V2MiB0byBzdXBwb3J0IG11dHVhbCBhdXRoZW50aWNhdGlvbg0KICAgYW5kIGRhdGEgcHJv dGVjdGlvbiBiZXR3ZWVuIHRoZSBpbnNlY3VyZSBGZW10b2NlbGwsIHdoaWNoIHR5cGljYWxseQ0K ICAgZGVwbG95ZWQgaW4gY3VzdG9tZXImIzM5O3MgcHJlbWlzZSwgYW5kIGl0cyBjb3JyZXNwb25k aW5nIG1vYmlsZSBjb3JlDQogICBuZXR3b3JrLg0KDQogICBBIGtub3duIHNlY3VyaXR5IHRocmVh dCBleGlzdHMgaW4gRmVtdG8gYXJjaGl0ZWN0dXJlIGZvciBmYWlsaW5nIHRvDQogICB2YWxpZGF0 ZSB0aGUgRkFQJiMzOTtzIGlkZW50aXR5IGFuZCBpbmZvcm1hdGlvbiBwcm92aWRlZCBieSBGQVAg YXQgdGhlDQogICBtb2JpbGUgb3BlcmF0b3ImIzM5O3MgY29yZSBuZXR3b3JrLg0KDQogICBUaGlz IGRvY3VtZW50IHJldmlld3MgdGhpcyBzZWN1cml0eSB0aHJlYXQgYW5kIHByb3Bvc2VzIGEgc2lt cGxlDQogICBleHRlbnNpb24gb2YgdGhlIElLRXYyIHRvIHJlc29sdmUgdGhlIGlzc3VlLg0KDQoN CiAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQo= --=_alternative 0024D7B74825798B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEZvbGtzOjwvZm9udD4NCjxi cj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0zPlRoZXJlIGlzIGEgbmV3IGRyYWZ0IGF2YWlsYWJsZSB0 aGF0IHNvbWUgb2YgeW91IG1heQ0KYmUgaW50ZXJlc3RlZDxicj4NCmluIGxvb2tpbmcgYXQuIDwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTM+VGhlIGRyYWZ0IGlzIGF2YWls YWJsZSB2aWEgdGhlIGZvbGxvd2luZyBsaW5rOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTM+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC16b25nLWlwc2VjbWUtaWtldjItY3Bl eHQ0ZmVtdG8tMDAudHh0PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mz5Q bGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LiBUaGFua3MhPC9mb250PjwvdHQ+ DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mz5CUjwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTM+WmFpZmVuZzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MSBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xv cj0jODAwMDgwIGZhY2U9InNhbnMtc2VyaWYiPi0tLS0tINeqt6LIyyDX2tTat+UwMDgyNDYvdXNl ci96dGVfbHRkDQrKsbzkIDIwMTItMDEtMjAgMTQ6MzMgLS0tLS08L2ZvbnQ+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9iPg0KPC9m b250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDEtMTggMTY6MDY8 L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ em9uZy56YWlmZW5nQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+ PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPnpvbmcuemFpZmVuZ0B6 dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5OZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC16b25nLWlwc2VjbWUtaWtldjItY3Bl eHQ0ZmVtdG8tMDAudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5BIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtem9uZy1pcHNlY21l LWlrZXYyLWNwZXh0NGZlbXRvLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBaYWlmZW5nIFpvbmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KcmVwb3NpdG9yeS48YnI+ DQo8YnI+DQpGaWxlbmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ZHJhZnQtem9uZy1pcHNlY21lLWlrZXYyLWNwZXh0NGZl bXRvPGJyPg0KUmV2aXNpb246ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzAwPGJyPg0KVGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpJS0V2MiBDb25m aWd1cmF0aW9uIFBheWxvYWQgRXh0ZW5zaW9uIGZvciBOb3Rhcml6aW5nIEZlbXRvY2VsbCBpbiBN b2JpbGUNCkNvcmUgTmV0d29yazxicj4NCkNyZWF0aW9uIGRhdGU6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzIwMTItMDEtMTg8 YnI+DQpXRyBJRDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCkluZGl2aWR1YWwgU3VibWlzc2lvbjxicj4NCk51bWJlciBvZiBw YWdlczogMTI8YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQogJm5ic3A7IElQU2VjIElLRXYyLCBS RkMgNTk5NiBbUkZDNTk5Nl0sIGhhcyBiZWVuIGFkb3B0ZWQgYnkgbWFueTxicj4NCiAmbmJzcDsg c3RhbmRhcmRpemVkIG5ldHdvcmsgc29sdXRpb25zIHRvIHByb3ZpZGUgdGhlIHNlY3VyZSB0cmFu c3BvcnQ8YnI+DQogJm5ic3A7IGJldHdlZW4gbmV0d29yayBlbGVtZW50cyBvdmVyIHRoaXJkIHBh cnR5JmFtcDsjMzk7cyBpbmZyYXN0cnVjdHVyZS4NCiZuYnNwO1RvZGF5PGJyPg0KICZuYnNwOyBG ZW10b2NlbGwgZGVwbG95bWVudCByZXF1aXJlcyB0aGUgbW9iaWxlIG9wZXJhdG9yJmFtcDsjMzk7 cyBGZW10b2NlbGwNCkFQPGJyPg0KICZuYnNwOyAoRkFQKSB0byBsZXZlcmFnZSB0aGUgSVBTZWMg SUtFdjIgdG8gc3VwcG9ydCBtdXR1YWwgYXV0aGVudGljYXRpb248YnI+DQogJm5ic3A7IGFuZCBk YXRhIHByb3RlY3Rpb24gYmV0d2VlbiB0aGUgaW5zZWN1cmUgRmVtdG9jZWxsLCB3aGljaCB0eXBp Y2FsbHk8YnI+DQogJm5ic3A7IGRlcGxveWVkIGluIGN1c3RvbWVyJmFtcDsjMzk7cyBwcmVtaXNl LCBhbmQgaXRzIGNvcnJlc3BvbmRpbmcgbW9iaWxlDQpjb3JlPGJyPg0KICZuYnNwOyBuZXR3b3Jr Ljxicj4NCjxicj4NCiAmbmJzcDsgQSBrbm93biBzZWN1cml0eSB0aHJlYXQgZXhpc3RzIGluIEZl bXRvIGFyY2hpdGVjdHVyZSBmb3IgZmFpbGluZw0KdG88YnI+DQogJm5ic3A7IHZhbGlkYXRlIHRo ZSBGQVAmYW1wOyMzOTtzIGlkZW50aXR5IGFuZCBpbmZvcm1hdGlvbiBwcm92aWRlZCBieQ0KRkFQ IGF0IHRoZTxicj4NCiAmbmJzcDsgbW9iaWxlIG9wZXJhdG9yJmFtcDsjMzk7cyBjb3JlIG5ldHdv cmsuPGJyPg0KPGJyPg0KICZuYnNwOyBUaGlzIGRvY3VtZW50IHJldmlld3MgdGhpcyBzZWN1cml0 eSB0aHJlYXQgYW5kIHByb3Bvc2VzIGEgc2ltcGxlPGJyPg0KICZuYnNwOyBleHRlbnNpb24gb2Yg dGhlIElLRXYyIHRvIHJlc29sdmUgdGhlIGlzc3VlLjxicj4NCjxicj4NCjxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJy Pg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90 dD4NCg== --=_alternative 0024D7B74825798B_=-- From ynir@checkpoint.com Fri Jan 20 00:59:48 2012 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 B49F321F8603 for ; Fri, 20 Jan 2012 00:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.110, 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 E9JO1nuNaLnM for ; Fri, 20 Jan 2012 00:59:48 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id B6C3D21F85F6 for ; Fri, 20 Jan 2012 00:59:47 -0800 (PST) X-CheckPoint: {4F192A29-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 q0K8xOKO006188; Fri, 20 Jan 2012 10:59:24 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 20 Jan 2012 10:59:24 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 20 Jan 2012 10:59:23 +0200 From: Yoav Nir To: Paul Hoffman Date: Fri, 20 Jan 2012 10:59:21 +0200 Thread-Topic: [IPsec] Starting work on our new charter items Thread-Index: AczXUc4X5hcoKXvnRj2rMKUeWG016g== Message-ID: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IPsecme WG Subject: Re: [IPsec] Starting work on our new charter items 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, 20 Jan 2012 08:59:48 -0000 On Jan 20, 2012, at 12:43 AM, Paul Hoffman wrote: > We have a new charter. Do we have any volunteers to start work on the two= documents we committed to work on? I think it's premature to start work on the solutions document, but it is t= ime to start work on the problem statement document. I'm willing to work on the problem statement document, but I'd rather not e= dit, if possible. > Related: we should consider having a face-to-face meeting at the upcoming= IETF in Paris, but only if there is value for the newly-chartered work. In= my mind, that means both a first draft submitted *and* interesting questio= ns that would benefit from face-to-face discussion instead of just work on = the list. Do people believe we will have that? The problem statement draft should have use cases, definitions, and require= ments. These I think benefit greatly from face-to-face discussion, so I thi= nk we should have a meeting regardless of whether a first draft is already = submitted. In fact this kind of brainstorm meeting can be even better at co= ming up with definitions than someone making up some definitions and offeri= ng them for others to discuss.= From paul.hoffman@vpnc.org Fri Jan 20 07:08:25 2012 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 F1AEE21F85B8 for ; Fri, 20 Jan 2012 07:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 a1zYQMgnRO0e for ; Fri, 20 Jan 2012 07:08:24 -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 4ECA021F8571 for ; Fri, 20 Jan 2012 07:08:24 -0800 (PST) Received: from [10.20.30.109] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0KF8DeS032619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Jan 2012 08:08:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Fri, 20 Jan 2012 07:08:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <64F18FD7-D12D-4F6F-9787-3EAA0C71FCA2@vpnc.org> References: To: Yoav Nir X-Mailer: Apple Mail (2.1251.1) Cc: IPsecme WG Subject: Re: [IPsec] Starting work on our new charter items 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, 20 Jan 2012 15:08:25 -0000 On Jan 20, 2012, at 12:59 AM, Yoav Nir wrote: > On Jan 20, 2012, at 12:43 AM, Paul Hoffman wrote: >=20 >> We have a new charter. Do we have any volunteers to start work on the = two documents we committed to work on? >=20 > I think it's premature to start work on the solutions document, but it = is time to start work on the problem statement document. >=20 > I'm willing to work on the problem statement document, but I'd rather = not edit, if possible. >=20 >> Related: we should consider having a face-to-face meeting at the = upcoming IETF in Paris, but only if there is value for the = newly-chartered work. In my mind, that means both a first draft = submitted *and* interesting questions that would benefit from = face-to-face discussion instead of just work on the list. Do people = believe we will have that? >=20 > The problem statement draft should have use cases, definitions, and = requirements. These I think benefit greatly from face-to-face = discussion, so I think we should have a meeting regardless of whether a = first draft is already submitted. In fact this kind of brainstorm = meeting can be even better at coming up with definitions than someone = making up some definitions and offering them for others to discuss. This is reasonable *but only if* people who care about the requirements = document are at the Paris meeting. If not, then we will have a quiet = room with only one or two speakers and many people who will have wasted = their time and money. Are there more volunteers to work on the requirements document *soon* so = that we can get a feel for the need for the meeting? --Paul Hoffman From prbatra@cisco.com Fri Jan 20 12:18:52 2012 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 90E8A21F86AB for ; Fri, 20 Jan 2012 12:18:52 -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 UtmmI-tgkaIm for ; Fri, 20 Jan 2012 12:18:51 -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 BC5EB21F86A4 for ; Fri, 20 Jan 2012 12:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=9621; q=dns/txt; s=iport; t=1327090731; x=1328300331; h=mime-version:subject:date:message-id:from:to; bh=2TYh4vmta0/2mxEWOk+JgcdrEOyKOEGMvWClmQZxoCk=; b=WwqXdQ/T9yzg3CV+ZastDy4NaPXpyE4/BPc+GJpmBuywy4QrArYieVpZ 1g87z+fY70sd+9XLvLkD4sEhb9V5EOVM9IYcuncRwtdNFWTsk1ElQfkOW oqPkZDhuMQP6asH30UHv/l9qGMHJzooKDXIExMivTpBKl/fikPN5ILkUa 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAG/LGU9Io8UY/2dsb2JhbABDgk2sQYF0AQQSAQkRA1sBKgYYB1AHAQQLEBqgV4EnAZ44i0NjBIg6nzI X-IronPort-AV: E=Sophos;i="4.71,544,1320624000"; d="scan'208,217";a="3859468" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 20 Jan 2012 20:18:49 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0KKInrv010815 for ; Fri, 20 Jan 2012 20:18:49 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); Sat, 21 Jan 2012 01:48:49 +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_01CCD7B0.B8333E24" Date: Sat, 21 Jan 2012 01:48:47 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: query related to rekey Thread-Index: AczXsLdu85SYI8WeRl+G+PKEAVUS4A== From: "Prashant Batra (prbatra)" To: X-OriginalArrivalTime: 20 Jan 2012 20:18:49.0268 (UTC) FILETIME=[B8457F40:01CCD7B0] Subject: [IPsec] query related to rekey 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, 20 Jan 2012 20:18:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCD7B0.B8333E24 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Section 2.8 of rfc-5996 states handling for rekeying. The text- >From a technical correctness and interoperability perspective, the responder MAY begin sending on an SA as soon as it sends its response to the CREATE_CHILD_SA request. In some situations, however, this could result in packets unnecessarily being dropped, so an implementation MAY defer such sending. =20 The responder can be assured that the initiator is prepared to receive messages on an SA if either (1) it has received a cryptographically valid message on the other half of the SA pair, or (2) the new SA rekeys an existing SA and it receives an IKE request to close the replaced SA. When rekeying an SA, the responder continues to send traffic on the old SA until one of those events occurs. When establishing a new SA, the responder MAY defer sending messages on a new SA until either it receives one or a timeout has occurred. If an initiator receives a message on an SA for which it has not received a response to its CREATE_CHILD_SA request, it interprets that as a likely packet loss and retransmits the CREATE_CHILD_SA request. An initiator MAY send a dummy ESP message on a newly created ESP SA if it has no messages queued in order to assure the responder that the initiator is ready to receive messages. =20 After initiating a rekey or responding to a rekey,=20 Is it correct to say, that any request should continue to be sent on old SA until you receive a DELETE request or you send a DELETE request to delete the rekeyed SA? The new SA should only be used after the old SA gets deleted. =20 Regards, Prashant ------_=_NextPart_001_01CCD7B0.B8333E24 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Section 2.8 of rfc-5996 states handling for = rekeying. The text-

From a technical = correctness and interoperability perspective, the

   responder MAY = begin sending on an SA as soon as it sends its response

   to the CREATE_CHILD_SA request.  In some situations, however, = this

   could result = in packets unnecessarily being dropped, so an

   = implementation MAY defer such sending.

 

   The responder = can be assured that the initiator is prepared to

   receive = messages on an SA if either (1) it has received a

   = cryptographically valid message on the other half of the SA pair, or

   (2) the new = SA rekeys an existing SA and it receives an IKE = request

   to close the replaced SA.  When rekeying an SA, the = responder

   continues to = send traffic on the old SA until one of those events

   occurs.  = When establishing a new SA, the responder MAY defer = sending

   messages on a = new SA until either it receives one or a timeout has

   = occurred.  If an initiator receives a message on an SA for which = it

   has not = received a response to its CREATE_CHILD_SA request, it

   interprets = that as a likely packet loss and retransmits the

   = CREATE_CHILD_SA request.  An initiator MAY send a dummy ESP = message

   on a newly = created ESP SA if it has no messages queued in order to

   assure the = responder that the initiator is ready to receive messages.

 

After initiating a rekey or responding to a rekey, =

Is it correct to say, that any request should = continue to be sent on old SA until you receive a DELETE request or you send a DELETE = request

to delete the rekeyed SA?

The new SA should only be used after the old SA = gets deleted.

 

Regards,

Prashant

------_=_NextPart_001_01CCD7B0.B8333E24-- From nico@cryptonector.com Fri Jan 20 12:49:23 2012 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 C309221F86F0 for ; Fri, 20 Jan 2012 12:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.040, 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 2H+ctpj5lrE3 for ; Fri, 20 Jan 2012 12:49:23 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id A5F2021F86EF for ; Fri, 20 Jan 2012 12:49:22 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 4338F10062 for ; Fri, 20 Jan 2012 12:49:22 -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; q=dns; s=cryptonector.com; b=UQRqLFhj5IAE1I81X9kZF SlpDvQaRI2MxYSPzUczJOO4mF/qpxp++wYwNAhyTaTEdr2CsoNsYPP92bDoFCfey nlqA0zt7lyQ0QISq6C8CVQA/sNSZRjlEIH4O92n/Nqto5qmJugLGryAtmh4COVr3 neNG2EM/XkNfVY+95uTuCw= 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; s=cryptonector.com; bh=VblMZZ1qw0XIEwuRTg6L jg9xOQM=; b=rx8r73j6O4Gg+AN+GfdGfzwskovp36pGuxTimkIAhpcjlaspZzpe uEIFk0m8SW+cj0c28ydWCUzVcXlsOzzNQjA/ZtMFqn5wFrRPe1KV7UQRi40YMb1h sGKOwtFe+Dz4wAlWdZpqUqgX1pR/TiFS/xzLllpM5r49Q9o8MdlOYMU= 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-a34.g.dreamhost.com (Postfix) with ESMTPSA id 2864B1005D for ; Fri, 20 Jan 2012 12:49:22 -0800 (PST) Received: by dakf10 with SMTP id f10so719206dak.31 for ; Fri, 20 Jan 2012 12:49:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.234 with SMTP id o10mr64784680pbv.90.1327092561734; Fri, 20 Jan 2012 12:49:21 -0800 (PST) Received: by 10.68.220.105 with HTTP; Fri, 20 Jan 2012 12:49:21 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Jan 2012 14:49:21 -0600 Message-ID: From: Nico Williams To: "Prashant Batra (prbatra)" Content-Type: text/plain; charset=UTF-8 Cc: ipsec@ietf.org Subject: Re: [IPsec] query related to rekey 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, 20 Jan 2012 20:49:23 -0000 On Fri, Jan 20, 2012 at 2:18 PM, Prashant Batra (prbatra) wrote: > After initiating a rekey or responding to a rekey, > > Is it correct to say, that any request should continue to be sent on old SA > until you receive a DELETE request or you send a DELETE request > to delete the rekeyed SA? Clearly some interlocking here would be nice, otherwise there will be a race and high likelihood of dropped packets, with ensuing pain at higher layers. IMO the CREATE_CHILD_SA reply indicates that the peer is ready to receive on that SA, but the local node may not be able to do so until the CREATE_CHILD_SA reply is processed, so the peer should NOT send on the new SA until it sees a DELETE of the old child SA. In other words: - assume that the responder to a CREATE_CHILD_SA is ready to receive ESP/AH on the new SA SPI as soon as the responder's CREATE_CHILD_SA reply is received, and by corollary the initiator can start sending on the new SA immediately; - assume that the initiator of a CREATE_CHILD_SA exchange is NOT ready to receive ESP/AH on the new SA SPI until the initiator sends a DELETE payload deleting the old SA SPI, so the responder should NOT send on the new SA until it gets that DELETE. Nico -- From prbatra@cisco.com Fri Jan 20 13:11:18 2012 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 EB81E21F8589 for ; Fri, 20 Jan 2012 13:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWXkykI32Llu for ; Fri, 20 Jan 2012 13:11:18 -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 8B6A921F85A2 for ; Fri, 20 Jan 2012 13:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=2135; q=dns/txt; s=iport; t=1327093877; x=1328303477; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=X8Msh7DrqEirXl45picA5QhLSbuQ3jozqJzAqaZgwic=; b=geEEjRiUOTzAGKg9bOcd6n4KW7DVyD7iQiMw1It3pZs+77KXuNMm69g4 h5GtA6UcUkhlYCuHHpZtgpD1UetrEyZIAtRA86l5qkLHN6lZ4S/lz3xIn jkbg2ykliygsWYh3Xqv71yIVBfu335bqIw558nkAfrc4LiYwyAwjz4PDg A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAB/XGU9Io8UY/2dsb2JhbABDrw+BcgEBAQQBAQEPAR0KNAsMBAIBCBEEAQEBCgYXAQYBJh8JCAEBBAsICBqHYpokAZ4yBItDYwSIOp8y X-IronPort-AV: E=Sophos;i="4.71,544,1320624000"; d="scan'208";a="3860753" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 20 Jan 2012 21:10:53 +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 q0KLAr8U029032; Fri, 20 Jan 2012 21:10:53 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); Sat, 21 Jan 2012 02:40:53 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Jan 2012 02:40:52 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] query related to rekey Thread-Index: AczXtQQqsMWeTM/TTVqw3GdoVLcUKwAAWGqA References: From: "Prashant Batra (prbatra)" To: "Nico Williams" X-OriginalArrivalTime: 20 Jan 2012 21:10:53.0290 (UTC) FILETIME=[FE556CA0:01CCD7B7] Cc: ipsec@ietf.org Subject: Re: [IPsec] query related to rekey 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, 20 Jan 2012 21:11:19 -0000 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Nico Williams Sent: Saturday, January 21, 2012 2:19 AM To: Prashant Batra (prbatra) Cc: ipsec@ietf.org Subject: Re: [IPsec] query related to rekey On Fri, Jan 20, 2012 at 2:18 PM, Prashant Batra (prbatra) wrote: > After initiating a rekey or responding to a rekey, > > Is it correct to say, that any request should continue to be sent on old SA > until you receive a DELETE request or you send a DELETE request > to delete the rekeyed SA? Clearly some interlocking here would be nice, otherwise there will be a race and high likelihood of dropped packets, with ensuing pain at higher layers. IMO the CREATE_CHILD_SA reply indicates that the peer is ready to receive on that SA, but the local node may not be able to do so until the CREATE_CHILD_SA reply is processed, so the peer should NOT send on the new SA until it sees a DELETE of the old child SA. [Prashant] That's, from the responder side, but it may happen that the node initiating IKE_REKEY wants to initiate CHILD_SA_REKEY=20 after sending IKE_REKEY_REQUEST as childsa is expired. So, it has to do it on old IKE_SA as he has not received the response. So is this case correct? In other words: - assume that the responder to a CREATE_CHILD_SA is ready to receive ESP/AH on the new SA SPI as soon as the responder's CREATE_CHILD_SA reply is received, and by corollary the initiator can start sending on the new SA immediately; - assume that the initiator of a CREATE_CHILD_SA exchange is NOT ready to receive ESP/AH on the new SA SPI until the initiator sends a DELETE payload deleting the old SA SPI, so the responder should NOT send on the new SA until it gets that DELETE. [Prashant] So, what is an ideal implementation that should be followed. I think, sticking to one standard, that's always send on the old SA until you send DELETE is a good option. Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nico@cryptonector.com Fri Jan 20 13:40:18 2012 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 69BC321F864D for ; Fri, 20 Jan 2012 13:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.039, 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 vHmliVxZfs55 for ; Fri, 20 Jan 2012 13:40:17 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id DBDDF21F84D0 for ; Fri, 20 Jan 2012 13:40:17 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 8ED3B94075 for ; Fri, 20 Jan 2012 13:40:17 -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=x4vQqnwM55CmVZRCXYuze7dlSkFO6qxW0UNxDw7kkZvh iLbgKNucNDQJU3FGFxADiAs8cWIHL1l8w1SrQhgLXPM5s+DvKpVqRq65ruqUtrhI hc9vyy5DNcr/OSBWIaWfP2oQE8sKF97gTKJf4M0rGnXw2J96DkO1QDodKIM3jBM= 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=dsVkZLvzjGvaeI3udFK12AC9Pwo=; b=aa6d+noLKWR UvFzRwjDNdcdT4YhzOpdsr/G0Q1+tRflSW741uThxI9bDEiHKPyppU7HCKhXoMSr iuFKfdJXvrmCllu935DQiIO1aQ9LsLsMfcegCWBqtyUDtI6cVQ28Ggisa7hVOHrV y4cn4qKxrHuQludOb6qRoWUtVq45eBPQ= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 7021294065 for ; Fri, 20 Jan 2012 13:40:17 -0800 (PST) Received: by pbaa13 with SMTP id a13so756683pba.31 for ; Fri, 20 Jan 2012 13:40:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.122.202 with SMTP id lu10mr38715009pbb.101.1327095617093; Fri, 20 Jan 2012 13:40:17 -0800 (PST) Received: by 10.68.220.105 with HTTP; Fri, 20 Jan 2012 13:40:16 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Jan 2012 15:40:16 -0600 Message-ID: From: Nico Williams To: "Prashant Batra (prbatra)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: Re: [IPsec] query related to rekey 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, 20 Jan 2012 21:40:18 -0000 On Fri, Jan 20, 2012 at 3:10 PM, Prashant Batra (prbatra) wrote: > > Clearly some interlocking here would be nice, otherwise there will be > > a race and high likelihood of dropped packets, with ensuing pain at > > higher layers. =C2=A0IMO the CREATE_CHILD_SA reply indicates that the p= eer > > is ready to receive on that SA, but the local node may not be able to > > do so until the CREATE_CHILD_SA reply is processed, so the peer should > > NOT send on the new SA until it sees a DELETE of the old child SA. > > [Prashant] That's, from the responder side, but it may happen that the > node initiating IKE_REKEY wants to initiate CHILD_SA_REKEY > after sending IKE_REKEY_REQUEST as childsa is expired. So, it has to do > it on old IKE_SA as he has not received the response. > So is this case correct? I described both sides. Again: the initiator should use the new SA as soon as the responder rekey reply is processed by the initiator, while the responder should use the old SA until the initiator deletes it. Obviously, if the old SA expires, well, the responder must use the new SA. So initiate rekeys such that there's enough time to complete the rekey. As for simultaneous re-keying, well, see section 2.8.1 of RFC5996. > [Prashant] So, what is an ideal implementation that should be followed. > I think, sticking to one standard, that's always send on the old SA > until you send DELETE is a good option. On the responder side, yes, subject to the caveats about SA expiration and simultaneous rekeying. On the initiator side you should send with the new SA as soon as you instal= l it. Nico -- From prbatra@cisco.com Fri Jan 20 13:55:39 2012 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 4C72921F860F for ; Fri, 20 Jan 2012 13:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlWw0oYBoSU8 for ; Fri, 20 Jan 2012 13:55:38 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1991521F8566 for ; Fri, 20 Jan 2012 13:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=prbatra@cisco.com; l=3346; q=dns/txt; s=iport; t=1327096538; x=1328306138; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=+Ljp2n/brVeXs10f9UVXyJ/qyuLiNOVDlf9nPAGQBy4=; b=SYL/lpLLVYL7xUSiDB782RtETD4NKOupuLNKfpXeowKnl8o85Sjh1a6Y ZX6mI5b7karmfqQBFD5VPfhDYVJMEPviixgwYreYnmYCxr11aA58b8+3l nEBVxNZRzS5x/DgazgncC7L/zX1YI97JBZ8k2U1mSZ5sUR551zqtCnSvc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEABziGU9Io8UY/2dsb2JhbABDhQSoGYFygXIBAQEEAQEBDwEQDQQ6CwwEAgEIEQQBAQECAgYGFwECAgIBASUfCQgBAQQLCAgah2KaGwGMY5FEBIEviWEzYwSIOp8y X-IronPort-AV: E=Sophos;i="4.71,545,1320624000"; d="scan'208";a="3856212" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 20 Jan 2012 21:55:36 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q0KLtafh023741; Fri, 20 Jan 2012 21:55:36 GMT Received: from xmb-bgl-419.cisco.com ([72.163.129.215]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 21 Jan 2012 03:25:36 +0530 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Sat, 21 Jan 2012 03:25:35 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] query related to rekey Thread-Index: AczXvB+1MiGoGLLLRfyaWJZ3I2m+2gAAYKSw References: From: "Prashant Batra (prbatra)" To: "Nico Williams" X-OriginalArrivalTime: 20 Jan 2012 21:55:36.0221 (UTC) FILETIME=[3D7C34D0:01CCD7BE] Cc: ipsec@ietf.org Subject: Re: [IPsec] query related to rekey 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, 20 Jan 2012 21:55:39 -0000 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpcHNlYy1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86aXBzZWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5pY28gV2ls bGlhbXMNClNlbnQ6IFNhdHVyZGF5LCBKYW51YXJ5IDIxLCAyMDEyIDM6MTAgQU0NClRvOiBQcmFz aGFudCBCYXRyYSAocHJiYXRyYSkNCkNjOiBpcHNlY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJ UHNlY10gcXVlcnkgcmVsYXRlZCB0byByZWtleQ0KDQpPbiBGcmksIEphbiAyMCwgMjAxMiBhdCAz OjEwIFBNLCBQcmFzaGFudCBCYXRyYSAocHJiYXRyYSkNCjxwcmJhdHJhQGNpc2NvLmNvbT4gd3Jv dGU6DQo+ID4gQ2xlYXJseSBzb21lIGludGVybG9ja2luZyBoZXJlIHdvdWxkIGJlIG5pY2UsIG90 aGVyd2lzZSB0aGVyZSB3aWxsIGJlDQo+ID4gYSByYWNlIGFuZCBoaWdoIGxpa2VsaWhvb2Qgb2Yg ZHJvcHBlZCBwYWNrZXRzLCB3aXRoIGVuc3VpbmcgcGFpbiBhdA0KPiA+IGhpZ2hlciBsYXllcnMu IMKgSU1PIHRoZSBDUkVBVEVfQ0hJTERfU0EgcmVwbHkgaW5kaWNhdGVzIHRoYXQgdGhlIHBlZXIN Cj4gPiBpcyByZWFkeSB0byByZWNlaXZlIG9uIHRoYXQgU0EsIGJ1dCB0aGUgbG9jYWwgbm9kZSBt YXkgbm90IGJlIGFibGUgdG8NCj4gPiBkbyBzbyB1bnRpbCB0aGUgQ1JFQVRFX0NISUxEX1NBIHJl cGx5IGlzIHByb2Nlc3NlZCwgc28gdGhlIHBlZXIgc2hvdWxkDQo+ID4gTk9UIHNlbmQgb24gdGhl IG5ldyBTQSB1bnRpbCBpdCBzZWVzIGEgREVMRVRFIG9mIHRoZSBvbGQgY2hpbGQgU0EuDQo+DQo+ IFtQcmFzaGFudF0gVGhhdCdzLCBmcm9tIHRoZSByZXNwb25kZXIgc2lkZSwgYnV0IGl0IG1heSBo YXBwZW4gdGhhdCB0aGUNCj4gbm9kZSBpbml0aWF0aW5nIElLRV9SRUtFWSB3YW50cyB0byBpbml0 aWF0ZSBDSElMRF9TQV9SRUtFWQ0KPiBhZnRlciBzZW5kaW5nIElLRV9SRUtFWV9SRVFVRVNUIGFz IGNoaWxkc2EgaXMgZXhwaXJlZC4gU28sIGl0IGhhcyB0byBkbw0KPiBpdCBvbiBvbGQgSUtFX1NB IGFzIGhlIGhhcyBub3QgcmVjZWl2ZWQgdGhlIHJlc3BvbnNlLg0KPiBTbyBpcyB0aGlzIGNhc2Ug Y29ycmVjdD8NCg0KSSBkZXNjcmliZWQgYm90aCBzaWRlcy4gIEFnYWluOiB0aGUgaW5pdGlhdG9y IHNob3VsZCB1c2UgdGhlIG5ldyBTQSBhcw0Kc29vbiBhcyB0aGUgcmVzcG9uZGVyIHJla2V5IHJl cGx5IGlzIHByb2Nlc3NlZCBieSB0aGUgaW5pdGlhdG9yLCB3aGlsZQ0KdGhlIHJlc3BvbmRlciBz aG91bGQgdXNlIHRoZSBvbGQgU0EgdW50aWwgdGhlIGluaXRpYXRvciBkZWxldGVzIGl0Lg0KDQpb UHJhc2hhbnRdIFllcywgdGhhdCBzaG91bGQgYmUgZmluZS4NCg0KT2J2aW91c2x5LCBpZiB0aGUg b2xkIFNBIGV4cGlyZXMsIHdlbGwsIHRoZSByZXNwb25kZXIgbXVzdCB1c2UgdGhlIG5ldw0KU0Eu ICBTbyBpbml0aWF0ZSByZWtleXMgc3VjaCB0aGF0IHRoZXJlJ3MgZW5vdWdoIHRpbWUgdG8gY29t cGxldGUgdGhlDQpyZWtleS4NCg0KW1ByYXNoYW50XSBTdGlsbCwgb25lIGNhc2UgaWYgaWtlc2Eg YW5kIGNoaWxkc2EgZXhwaXJlIGF0IHRoZSBzYW1lIHRpbWUsIHRoZW4gYXNzdW1lIGEgbm9kZSBp bml0aWF0ZXMgaWtlc2EtcmVrZXksIA0KYW5kIHdhbnRzIHRvIGluaXRpYXRlIGNoaWxkc2EtcmVr ZXkgYWxzbywgdGhlbiBzaG91bGQgaXQgd2FpdCBmb3IgdGhlIHJlc3BvbnNlIG9mIGlrZXNhLXJl a2V5IHRvIGNvbWUgYW5kIHRoZW4gaW5pdGlhdGUgDQpjaGlsc2EtcmVrZXkgb24gdGhlIG5ldyBT QSBvciBpbml0aWF0ZSBjaGlsZHNhLXJla2V5IG9uIHRoZSBvbGQgU0EgYmVmb3JlIHByb2Nlc3Np bmcgdGhlIGlrZXNhLXJla2V5IHJlc3BvbnNlLg0KDQpBcyBmb3Igc2ltdWx0YW5lb3VzIHJlLWtl eWluZywgd2VsbCwgc2VlIHNlY3Rpb24gMi44LjEgb2YgUkZDNTk5Ni4NCg0KPiBbUHJhc2hhbnRd IFNvLCB3aGF0IGlzIGFuIGlkZWFsIGltcGxlbWVudGF0aW9uIHRoYXQgc2hvdWxkIGJlIGZvbGxv d2VkLg0KPiBJIHRoaW5rLCBzdGlja2luZyB0byBvbmUgc3RhbmRhcmQsIHRoYXQncyBhbHdheXMg c2VuZCBvbiB0aGUgb2xkIFNBDQo+IHVudGlsIHlvdSBzZW5kIERFTEVURSBpcyBhIGdvb2Qgb3B0 aW9uLg0KDQpPbiB0aGUgcmVzcG9uZGVyIHNpZGUsIHllcywgc3ViamVjdCB0byB0aGUgY2F2ZWF0 cyBhYm91dCBTQSBleHBpcmF0aW9uDQphbmQgc2ltdWx0YW5lb3VzIHJla2V5aW5nLg0KDQpPbiB0 aGUgaW5pdGlhdG9yIHNpZGUgeW91IHNob3VsZCBzZW5kIHdpdGggdGhlIG5ldyBTQSBhcyBzb29u IGFzIHlvdSBpbnN0YWxsIGl0Lg0KDQpOaWNvDQotLQ0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg== From nico@cryptonector.com Fri Jan 20 15:14:52 2012 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 1CFE521F85C5 for ; Fri, 20 Jan 2012 15:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.037, 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 OglfuQEPzx2y for ; Fri, 20 Jan 2012 15:14:51 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id AC03C21F85B9 for ; Fri, 20 Jan 2012 15:14:50 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 4ACE41E13F for ; Fri, 20 Jan 2012 15:14:50 -0800 (PST) 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-a95.g.dreamhost.com (Postfix) with ESMTPSA id 944D82321B2 for ; Fri, 20 Jan 2012 14:02:20 -0800 (PST) Received: by dakf10 with SMTP id f10so758275dak.31 for ; Fri, 20 Jan 2012 14:02:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.196 with SMTP id n4mr64607714pbv.33.1327096933155; Fri, 20 Jan 2012 14:02:13 -0800 (PST) Received: by 10.68.220.105 with HTTP; Fri, 20 Jan 2012 14:02:13 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Jan 2012 16:02:13 -0600 Message-ID: From: Nico Williams To: "Prashant Batra (prbatra)" Content-Type: text/plain; charset=UTF-8 Cc: ipsec@ietf.org Subject: Re: [IPsec] query related to rekey 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, 20 Jan 2012 23:14:52 -0000 On Fri, Jan 20, 2012 at 3:55 PM, Prashant Batra (prbatra) wrote: > [Prashant] Still, one case if ikesa and childsa expire at the same time, then assume a node initiates ikesa-rekey, > and wants to initiate childsa-rekey also, then should it wait for the response of ikesa-rekey to come and then initiate > chilsa-rekey on the new SA or initiate childsa-rekey on the old SA before processing the ikesa-rekey response. Don't forget RFC6023. From ynir@checkpoint.com Fri Jan 20 15:27:06 2012 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 CD13B21F8534 for ; Fri, 20 Jan 2012 15:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.565 X-Spam-Level: X-Spam-Status: No, score=-10.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 7kpjvLKhYfwq for ; Fri, 20 Jan 2012 15:27:06 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D55CF21F8522 for ; Fri, 20 Jan 2012 15:27:05 -0800 (PST) X-CheckPoint: {4F19F569-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 q0KNQvfi005857; Sat, 21 Jan 2012 01:26:58 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 21 Jan 2012 01:26:57 +0200 From: Yoav Nir To: Nico Williams Date: Sat, 21 Jan 2012 01:26:54 +0200 Thread-Topic: [IPsec] query related to rekey Thread-Index: AczXywAxstOLEp7EQMiO/gOB5ccOAA== Message-ID: <46A156AA-9C92-4727-AAAF-1CE51DE7BA26@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Prashant Batra \(prbatra\)" Subject: Re: [IPsec] query related to rekey 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, 20 Jan 2012 23:27:06 -0000 On Jan 20, 2012, at 10:49 PM, Nico Williams wrote: >=20 > - assume that the initiator of a CREATE_CHILD_SA exchange is NOT > ready to receive ESP/AH on the new SA SPI until the initiator sends a > DELETE payload deleting the old SA SPI, so the responder should NOT > send on the new SA until it gets that DELETE. There are enough weird implementations out there that either never send the= DELETE or send it after a long time (as much as a minute), that I would no= t go that far. I think the responder should only send on the new SA after e= ither of the following two things happens: 1. A packet arrives on the new inbound SA 2. some time has passed (maybe 0.5 second) You can add reception of the DELETE as a third option if you like, but real= ly nothing bad happens if you send on an SA before the peer was ready. At w= orst it generates an unknown SPI log on the peer and forces the application= or transport layer to retransmit.= From ynir@checkpoint.com Fri Jan 20 23:30:59 2012 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 7F72D21F8656 for ; Fri, 20 Jan 2012 23:30:59 -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 I6o9R7XrStWK for ; Fri, 20 Jan 2012 23:30:55 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2B07221F8659 for ; Fri, 20 Jan 2012 23:30:54 -0800 (PST) X-CheckPoint: {4F1A66CB-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 q0L7Uljj031840; Sat, 21 Jan 2012 09:30:48 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 21 Jan 2012 09:30:47 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 21 Jan 2012 09:30:47 +0200 From: Yoav Nir To: " " Date: Sat, 21 Jan 2012 09:30:46 +0200 Thread-Topic: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt Thread-Index: AczYDpdzMBPLezlQT6af6rMDiu1/jA== Message-ID: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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, 21 Jan 2012 07:30:59 -0000 Hi Zaifeng Reading your draft, I'm trying to understand the problem you are solving. I= t is about the FAP being compromised and sending false information through = the tunnel. What is the malicious FAP lying about? How does sending some information (does "notarized" mean "signed"?) from th= e SeGW to the (compromised) FAP help? One general comment: "notarized" is a legal term, similar to "signature". A= lthough there is some analogy between the legal concept of signature and th= e digital signatures, such analogies only go so far. Using such a borrowed = term has IMHO led to more confusion than clarity. I would rather not use le= gal terms in protocols (although "protocol" is also a borrowed term) Thanks, Yoav On Jan 20, 2012, at 8:40 AM, wrote: >=20 > Hi Folks:=20 >=20 > There is a new draft available that some of you may be interested > in looking at.=20 >=20 > The draft is available via the following link:=20 > http://www.ietf.org/id/draft-zong-ipsecme-ikev2-cpext4femto-00.txt=20 >=20 > Please send your comments to the list. Thanks!=20 >=20 >=20 > BR=20 > Zaifeng=20 From zong.zaifeng@zte.com.cn Sat Jan 21 01:10:56 2012 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 0376521F8611 for ; Sat, 21 Jan 2012 01:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 gx9ljWPmJ-6Z for ; Sat, 21 Jan 2012 01:10:51 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2498B21F85A7 for ; Sat, 21 Jan 2012 01:10:50 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 538295521606; Sat, 21 Jan 2012 17:06:54 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 5467.20495145; Sat, 21 Jan 2012 17:10:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q0L9ARWw028439; Sat, 21 Jan 2012 17:10:27 +0800 (GMT-8) (envelope-from zong.zaifeng@zte.com.cn) In-Reply-To: To: Yoav Nir MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zong.zaifeng@zte.com.cn Date: Sat, 21 Jan 2012 17:08:01 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-21 17:10:29, Serialize complete at 2012-01-21 17:10:29 Content-Type: multipart/alternative; boundary="=_alternative 00325A034825798C_=" X-MAIL: mse01.zte.com.cn q0L9ARWw028439 Cc: "ipsec@ietf.org" Subject: [IPsec] =?gb2312?b?tPC4tDogUmU6ICBbSVBTZWNdOiBOZXcgVmVyc2lvbiBO?= =?gb2312?b?b3RpZmljYXRpb24gZm9yCWRyYWZ0LXpvbmctaXBzZWNtZS1pa2V2Mi1jcGV4?= =?gb2312?b?dDRmZW10by0wMC50eHQ=?= 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, 21 Jan 2012 09:10:56 -0000 This is a multipart message in MIME format. --=_alternative 00325A034825798C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgWW9hdjoNCg0KVGhhbmsgeW91IGZvciB5b3VyIGVtYWlsLiBSZWdhcmRpbmcgdG8geW91ciBx dWVzdGlvbiBvbiAid2hhdCBpcyB0aGUgDQptYWxpY2lvdXMgRkFQIGx5aW5nIGFib3V0IiwgSSB3 b3VsZCBsaWtlIHRvIGdpdmUgeW91IHNvbWUgZnVydGhlciANCmJhY2tncm91bmQuIEluIHJlYWwg ZmVtdG8gZGVwbG95bWVudCwgbm90IGV2ZXJ5IG1vYmlsZSB0ZXJtaW5hbCBpcyBhbGxvd2VkIA0K dG8gYXR0YWNoIHZpYSBhbiBGQVAuIEluIGZhY3QsIGluIHRoZSByZWFsIGRlcGxveW1lbnQsIHRo ZXJlIGFyZSAzIGtpbmRzIA0Kb2YgRkFQczogb3BlbiBtb2RlIEZBUCwgY2xvc2UgbW9kZSBGQVAs IGFuZCBoeWJyaWQgbW9kZSBGQVAuIFRoZSBvcGVuIG1vZGUgDQptZWFucyB0aGF0IHRoZSBGQVAg aXMgb3BlbiB0byBldmVyeW9uZSwgY2xvc2UgbW9kZSBtZWFucyB0aGUgRkFQIG9ubHkgDQphbGxv d3MgYSBjbG9zZWQgZ3JvdXAgb2YgbWVtYmVycyB0byBhY2Nlc3MsIGFuZCB0aGUgaHlicmlkIG1v ZGUgbWVhbnMgdGhhdCANCnRoZSBGQVAgaXMgb3BlbiB0byBldmVyeW9uZSwgYnV0IG9ubHkgYSBj bG9zZWQgZ3JvdXAgb2YgbWVtYmVycyB3aWxsIGhhdmUgDQpoaWdoZXIgcHJpb3JpdHkgb3IgaGF2 ZSBhdXRob3JpdHkgdG8gdmlzaXQgY2VydGFpbiByZXNvdXJjZXMuDQoNCkFjY29yZGluZyB0byBz b21lIFNETyAoZS5nLiAzR1BQKSwgdGhlIGFjY2VzcyBjb250cm9sIG9mIHRoZSBtb2JpbGUgDQp0 ZXJtaW5hbHMgYXR0YWNoaW5nIHZpYSBhIEZBUCBpcyBkb25lIGluIGNvcmUgbmV0d29yaywgdGh1 cywgaXQgaXMgdGhlIA0KY29yZSBuZXR3b3JrIHRoYXQgZGVjaWRlIHdoZXRoZXIgdGhlIG1vYmls ZSB0ZXJtaW5hbCBjYW4gYXR0YWNoIHRvIGFuIEZBUC4gDQpJbiBvcmRlciB0byBoZWxwIHRoZSBj b3JlIG5ldHdvcmsgbWFrZSBkZWNpc2lvbiBvbiB3aGV0aGVyIHRoZSBtb2JpbGUgDQp0ZXJtaW5h bCBjYW4gYXR0YWNoIHRvIGFuIEZBUCwgdGhlIEZBUCBuZWVkcyB0byBzZW5kIGluZm9ybWF0aW9u LCBzdWNoIGFzIA0KdGhlIG1vZGUgb2YgdGhlIEZBUCwgYW5kIHRoZSBhbGxvd2VkIG1lbWJlciBn cm91cCBvZiB0aGUgRkFQLCB0byB0aGUgY29yZSANCm5ldHdvcmsuIEEgY29tcHJvbWlzZWQgRkFQ IGNvdWxkIHNlbmQgZmFsc2UgbW9kZSBhbmQgZmFsc2UgYWxsb3dlZCBtZW1iZXIgDQpncm91cCB0 byB0aGUgY29yZSBuZXR3b3JrLCBzbyB0aGF0IGEgbm90IGFsbG93ZWQgbW9iaWxlIHRlcm1pbmFs IGNvdWxkIGJlIA0KYWxsb3dlZCBieSB0aGUgY29yZSBuZXR3b3JrLiANCg0KSSB3aXNoIHRoZSBh Ym92ZSBjbGFyaWZpY2F0aW9uIGhlbHBzIHlvdSB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtLg0KDQpS ZWdhcmRpbmcgdG8gdGhlIHRlcm0gbm90YXJpemVkLCBzaW5jZSBJIGFtIGdyZWVuIHRvIHRoaXMg Z3JvdXAsIEkgYW0gbm90IA0Kc3VyZSwgZG8geW91IHByZWZlciB0byByZXBsYWNlIHRoZSBub3Rh cml6ZSB3aXRoIHNpZ25hdHVyZT8gUGxlYXNlIGxldCBtZSANCmtub3csIHRoYW5rIHlvdSENCg0K DQpCUg0KWmFpZmVuZw0KDQogDQoNCg0KDQpZb2F2IE5pciA8eW5pckBjaGVja3BvaW50LmNvbT4g DQoyMDEyLTAxLTIxIDE1OjMwDQoNCsrVvP7Iyw0KIjx6b25nLnphaWZlbmdAenRlLmNvbS5jbj4g PHpvbmcuemFpZmVuZ0B6dGUuY29tLmNuPiIgDQo8em9uZy56YWlmZW5nQHp0ZS5jb20uY24+DQqz rcvNDQoiaXBzZWNAaWV0Zi5vcmciIDxpcHNlY0BpZXRmLm9yZz4NCtb3zOINClJlOiBbSVBzZWNd IFtJUFNlY106IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQpkcmFmdC16b25nLWlwc2Vj bWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0DQoNCg0KDQoNCg0KDQpIaSBaYWlmZW5nDQoNClJl YWRpbmcgeW91ciBkcmFmdCwgSSdtIHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtIHlv dSBhcmUgc29sdmluZy4gDQpJdCBpcyBhYm91dCB0aGUgRkFQIGJlaW5nIGNvbXByb21pc2VkIGFu ZCBzZW5kaW5nIGZhbHNlIGluZm9ybWF0aW9uIA0KdGhyb3VnaCB0aGUgdHVubmVsLg0KDQpXaGF0 IGlzIHRoZSBtYWxpY2lvdXMgRkFQIGx5aW5nIGFib3V0Pw0KSG93IGRvZXMgc2VuZGluZyBzb21l IGluZm9ybWF0aW9uIChkb2VzICJub3Rhcml6ZWQiIG1lYW4gInNpZ25lZCI/KSBmcm9tIA0KdGhl IFNlR1cgdG8gdGhlIChjb21wcm9taXNlZCkgRkFQIGhlbHA/DQoNCk9uZSBnZW5lcmFsIGNvbW1l bnQ6ICJub3Rhcml6ZWQiIGlzIGEgbGVnYWwgdGVybSwgc2ltaWxhciB0byAic2lnbmF0dXJlIi4g DQpBbHRob3VnaCB0aGVyZSBpcyBzb21lIGFuYWxvZ3kgYmV0d2VlbiB0aGUgbGVnYWwgY29uY2Vw dCBvZiBzaWduYXR1cmUgYW5kIA0KdGhlIGRpZ2l0YWwgc2lnbmF0dXJlcywgc3VjaCBhbmFsb2dp ZXMgb25seSBnbyBzbyBmYXIuIFVzaW5nIHN1Y2ggYSANCmJvcnJvd2VkIHRlcm0gaGFzIElNSE8g bGVkIHRvIG1vcmUgY29uZnVzaW9uIHRoYW4gY2xhcml0eS4gSSB3b3VsZCByYXRoZXIgDQpub3Qg dXNlIGxlZ2FsIHRlcm1zIGluIHByb3RvY29scyAoYWx0aG91Z2ggInByb3RvY29sIiBpcyBhbHNv IGEgYm9ycm93ZWQgDQp0ZXJtKQ0KDQpUaGFua3MsDQoNCllvYXYNCg0KT24gSmFuIDIwLCAyMDEy LCBhdCA4OjQwIEFNLCA8em9uZy56YWlmZW5nQHp0ZS5jb20uY24+IA0KPHpvbmcuemFpZmVuZ0B6 dGUuY29tLmNuPiB3cm90ZToNCg0KPiANCj4gSGkgRm9sa3M6IA0KPiANCj4gVGhlcmUgaXMgYSBu ZXcgZHJhZnQgYXZhaWxhYmxlIHRoYXQgc29tZSBvZiB5b3UgbWF5IGJlIGludGVyZXN0ZWQNCj4g aW4gbG9va2luZyBhdC4gDQo+IA0KPiBUaGUgZHJhZnQgaXMgYXZhaWxhYmxlIHZpYSB0aGUgZm9s bG93aW5nIGxpbms6IA0KPiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXpvbmctaXBzZWNt ZS1pa2V2Mi1jcGV4dDRmZW10by0wMC50eHQgDQo+IA0KPiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1l bnRzIHRvIHRoZSBsaXN0LiBUaGFua3MhIA0KPiANCj4gDQo+IEJSIA0KPiBaYWlmZW5nIA0KDQoN Cg0KDQo= --=_alternative 00325A034825798C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFlvYXY6PC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFuayB5b3UgZm9yIHlvdXIg ZW1haWwuIFJlZ2FyZGluZw0KdG8geW91ciBxdWVzdGlvbiBvbiAmcXVvdDt3aGF0IGlzIHRoZSBt YWxpY2lvdXMgRkFQIGx5aW5nIGFib3V0JnF1b3Q7LA0KSSB3b3VsZCBsaWtlIHRvIGdpdmUgeW91 IHNvbWUgZnVydGhlciBiYWNrZ3JvdW5kLiBJbiByZWFsIGZlbXRvIGRlcGxveW1lbnQsDQpub3Qg ZXZlcnkgbW9iaWxlIHRlcm1pbmFsIGlzIGFsbG93ZWQgdG8gYXR0YWNoIHZpYSBhbiBGQVAuIElu IGZhY3QsIGluDQp0aGUgcmVhbCBkZXBsb3ltZW50LCB0aGVyZSBhcmUgMyBraW5kcyBvZiBGQVBz OiBvcGVuIG1vZGUgRkFQLCBjbG9zZSBtb2RlDQpGQVAsIGFuZCBoeWJyaWQgbW9kZSBGQVAuIFRo ZSBvcGVuIG1vZGUgbWVhbnMgdGhhdCB0aGUgRkFQIGlzIG9wZW4gdG8gZXZlcnlvbmUsDQpjbG9z ZSBtb2RlIG1lYW5zIHRoZSBGQVAgb25seSBhbGxvd3MgYSBjbG9zZWQgZ3JvdXAgb2YgbWVtYmVy cyB0byBhY2Nlc3MsDQphbmQgdGhlIGh5YnJpZCBtb2RlIG1lYW5zIHRoYXQgdGhlIEZBUCBpcyBv cGVuIHRvIGV2ZXJ5b25lLCBidXQgb25seSBhDQpjbG9zZWQgZ3JvdXAgb2YgbWVtYmVycyB3aWxs IGhhdmUgaGlnaGVyIHByaW9yaXR5IG9yIGhhdmUgYXV0aG9yaXR5IHRvDQp2aXNpdCBjZXJ0YWlu IHJlc291cmNlcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkFjY29yZGluZyB0byBzb21lIFNETyAoZS5nLiAzR1BQKSwgdGhlDQphY2Nlc3MgY29udHJv bCBvZiB0aGUgbW9iaWxlIHRlcm1pbmFscyBhdHRhY2hpbmcgdmlhIGEgRkFQIGlzIGRvbmUgaW4g Y29yZQ0KbmV0d29yaywgdGh1cywgaXQgaXMgdGhlIGNvcmUgbmV0d29yayB0aGF0IGRlY2lkZSB3 aGV0aGVyIHRoZSBtb2JpbGUgdGVybWluYWwNCmNhbiBhdHRhY2ggdG8gYW4gRkFQLiBJbiBvcmRl ciB0byBoZWxwIHRoZSBjb3JlIG5ldHdvcmsgbWFrZSBkZWNpc2lvbiBvbg0Kd2hldGhlciB0aGUg bW9iaWxlIHRlcm1pbmFsIGNhbiBhdHRhY2ggdG8gYW4gRkFQLCB0aGUgRkFQIG5lZWRzIHRvIHNl bmQNCmluZm9ybWF0aW9uLCBzdWNoIGFzIHRoZSBtb2RlIG9mIHRoZSBGQVAsIGFuZCB0aGUgYWxs b3dlZCBtZW1iZXIgZ3JvdXANCm9mIHRoZSBGQVAsIHRvIHRoZSBjb3JlIG5ldHdvcmsuIEEgY29t cHJvbWlzZWQgRkFQIGNvdWxkIHNlbmQgZmFsc2UgbW9kZQ0KYW5kIGZhbHNlIGFsbG93ZWQgbWVt YmVyIGdyb3VwIHRvIHRoZSBjb3JlIG5ldHdvcmssIHNvIHRoYXQgYSBub3QgYWxsb3dlZA0KbW9i aWxlIHRlcm1pbmFsIGNvdWxkIGJlIGFsbG93ZWQgYnkgdGhlIGNvcmUgbmV0d29yay4gPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHdpc2ggdGhlIGFi b3ZlIGNsYXJpZmljYXRpb24gaGVscHMNCnlvdSB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtLjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UmVnYXJkaW5nIHRv IHRoZSB0ZXJtIG5vdGFyaXplZCwgc2luY2UNCkkgYW0gZ3JlZW4gdG8gdGhpcyBncm91cCwgSSBh bSBub3Qgc3VyZSwgZG8geW91IHByZWZlciB0byByZXBsYWNlIHRoZSBub3Rhcml6ZQ0Kd2l0aCBz aWduYXR1cmU/IFBsZWFzZSBsZXQgbWUga25vdywgdGhhbmsgeW91ITwvZm9udD4NCjxicj4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QlI8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlphaWZlbmc8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+WW9hdiBOaXIgJmx0O3luaXJAY2hlY2twb2ludC5j b20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIw MTItMDEtMjEgMTU6MzA8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Jmx0O3pvbmcuemFpZmVuZ0B6dGUuY29tLmNuJmd0Ow0KJmx0 O3pvbmcuemFpZmVuZ0B6dGUuY29tLmNuJmd0OyZxdW90OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsmbHQ7em9uZy56YWlmZW5nQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4m cXVvdDtpcHNlY0BpZXRmLm9yZyZxdW90OyAmbHQ7aXBzZWNAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5SZTogW0lQc2VjXSBbSVBTZWNdOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24N CmZvciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC16b25nLWlwc2VjbWUtaWtldjIt Y3BleHQ0ZmVtdG8tMDAudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBaYWlmZW5nPGJyPg0KPGJyPg0KUmVhZGluZyB5b3VyIGRy YWZ0LCBJJ20gdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0geW91IGFyZSBzb2x2aW5n Lg0KSXQgaXMgYWJvdXQgdGhlIEZBUCBiZWluZyBjb21wcm9taXNlZCBhbmQgc2VuZGluZyBmYWxz ZSBpbmZvcm1hdGlvbiB0aHJvdWdoDQp0aGUgdHVubmVsLjxicj4NCjxicj4NCldoYXQgaXMgdGhl IG1hbGljaW91cyBGQVAgbHlpbmcgYWJvdXQ/PGJyPg0KSG93IGRvZXMgc2VuZGluZyBzb21lIGlu Zm9ybWF0aW9uIChkb2VzICZxdW90O25vdGFyaXplZCZxdW90OyBtZWFuICZxdW90O3NpZ25lZCZx dW90Oz8pDQpmcm9tIHRoZSBTZUdXIHRvIHRoZSAoY29tcHJvbWlzZWQpIEZBUCBoZWxwPzxicj4N Cjxicj4NCk9uZSBnZW5lcmFsIGNvbW1lbnQ6ICZxdW90O25vdGFyaXplZCZxdW90OyBpcyBhIGxl Z2FsIHRlcm0sIHNpbWlsYXIgdG8NCiZxdW90O3NpZ25hdHVyZSZxdW90Oy4gQWx0aG91Z2ggdGhl cmUgaXMgc29tZSBhbmFsb2d5IGJldHdlZW4gdGhlIGxlZ2FsDQpjb25jZXB0IG9mIHNpZ25hdHVy ZSBhbmQgdGhlIGRpZ2l0YWwgc2lnbmF0dXJlcywgc3VjaCBhbmFsb2dpZXMgb25seSBnbw0Kc28g ZmFyLiBVc2luZyBzdWNoIGEgYm9ycm93ZWQgdGVybSBoYXMgSU1ITyBsZWQgdG8gbW9yZSBjb25m dXNpb24gdGhhbg0KY2xhcml0eS4gSSB3b3VsZCByYXRoZXIgbm90IHVzZSBsZWdhbCB0ZXJtcyBp biBwcm90b2NvbHMgKGFsdGhvdWdoICZxdW90O3Byb3RvY29sJnF1b3Q7DQppcyBhbHNvIGEgYm9y cm93ZWQgdGVybSk8YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KWW9hdjxicj4NCjxicj4N Ck9uIEphbiAyMCwgMjAxMiwgYXQgODo0MCBBTSwgJmx0O3pvbmcuemFpZmVuZ0B6dGUuY29tLmNu Jmd0OyAmbHQ7em9uZy56YWlmZW5nQHp0ZS5jb20uY24mZ3Q7DQp3cm90ZTo8YnI+DQo8YnI+DQom Z3Q7IDxicj4NCiZndDsgSGkgRm9sa3M6IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGVyZSBpcyBh IG5ldyBkcmFmdCBhdmFpbGFibGUgdGhhdCBzb21lIG9mIHlvdSBtYXkgYmUgaW50ZXJlc3RlZDxi cj4NCiZndDsgaW4gbG9va2luZyBhdC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBkcmFmdCBp cyBhdmFpbGFibGUgdmlhIHRoZSBmb2xsb3dpbmcgbGluazogPGJyPg0KJmd0OyBodHRwOi8vd3d3 LmlldGYub3JnL2lkL2RyYWZ0LXpvbmctaXBzZWNtZS1pa2V2Mi1jcGV4dDRmZW10by0wMC50eHQN Cjxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBs aXN0LiBUaGFua3MhIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJSIDxicj4NCiZn dDsgWmFpZmVuZyA8YnI+DQo8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 00325A034825798C_=-- From ynir@checkpoint.com Sun Jan 22 07:04:40 2012 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 4939E21F84A6 for ; Sun, 22 Jan 2012 07:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.466 X-Spam-Level: X-Spam-Status: No, score=-8.466 tagged_above=-999 required=5 tests=[AWL=-2.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 mw5wV3ktf-Hr for ; Sun, 22 Jan 2012 07:04:39 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EB39721F8494 for ; Sun, 22 Jan 2012 07:04:36 -0800 (PST) X-CheckPoint: {4F1C2294-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 q0MF4Kmm013075; Sun, 22 Jan 2012 17:04:21 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 22 Jan 2012 17:04:20 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sun, 22 Jan 2012 17:04:20 +0200 From: Yoav Nir To: "'zong.zaifeng@zte.com.cn'" Date: Sun, 22 Jan 2012 17:04:20 +0200 Thread-Topic: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt Thread-Index: AczYHJZwBrYW5Yn0RLGSkNCAUkAfhQA+SaJg Message-ID: <006FEB08D9C6444AB014105C9AEB133F017A59DE7E91@il-ex01.ad.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_006FEB08D9C6444AB014105C9AEB133F017A59DE7E91ilex01adche_" MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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, 22 Jan 2012 15:04:40 -0000 --_000_006FEB08D9C6444AB014105C9AEB133F017A59DE7E91ilex01adche_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U28gaWYgSSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5LCB0aGUgbm90YXJpemVkIGRhdGEgY29u dGFpbnMgdGhlIGFjY2VwdGFibGUgbW9kZSBhbmQgdGhlIGFsbG93ZWQgbWVtYmVyIGdyb3Vwcywg c2lnbmVkIChhbmQgdGltZS1saW1pdGVkPykgYnkgdGhlIFNlR1cuDQoNClRoZSB0dW5uZWxlZCBw cm90b2NvbCBiZXR3ZWVuIHRoZSBGQVAgYW5kIHRoZSBjb3JlIG5ldHdvcmsgd291bGQgY2hhbmdl LCBzbyB0aGF0IGluc3RlYWQgb2YgdGhlIEZBUCBzZW5kaW5nIHVuc3Vic3RhbnRpYXRlZCBjbGFp bXMsIGl0IHdvdWxkIHJlcGxheSB0aGUgbm90YXJpemVkIGRhdGEgZnJvbSB0aGUgU2VHVy4gV291 bGRuJ3QgdGhpcyByZXF1aXJlIGFuIHVwZGF0ZSBvZiBib3RoIGNvcmUgbmV0d29yayBjb21wb25l bnRzLCBTZUdXIGFuZCBGQVBzPw0KDQpJIHdvdWxkIHRoaW5rIHRoYXQgdGhlIFNlR1cgY291bGQg aW5zdGVhZCBsb29rIGF0IHRoZSBkZWNyeXB0ZWQgcHJvdG9jb2wgYmV0d2VlbiB0aGUgRkFQIGFu ZCB0aGUgY29yZSBuZXR3b3JrICAoaXQgaXMgZGVjcnlwdGluZyBpdCBhZnRlciBhbGwpLCBhbmQg YmxvY2sgaXQgaWYgaXQgY29udGFpbnMgImxpZXMiLiBBIGNoYW5nZSBsaWtlIHRoaXMgd291bGQg cmVxdWlyZSBtb2RpZnlpbmcgb25seSB0aGUgU2VHVy4gSSBtYXkgYmUgc2hvd2luZyBzb21lIHNl cmlvdXMgZmlyZXdhbGwgdmVuZG9yIGJpYXMgaGVyZS4uLg0KDQpBbnl3YXksIHllcywgeW91ciBj bGFyaWZpY2F0aW9uIGhlbHBlZCBtZSB2ZXJ5IG11Y2guDQoNClJlZ2FyZGluZyB0aGUgdGVybSAi bm90YXJpemVkIiwgSSB3b3VsZCBwcmVmZXIgbm90IHRvIGJyaW5nIGluIGEgbmV3IHRlcm0gdGhh dCBpcyBidXJkZW5lZCB3aXRoIG90aGVyIG1lYW5pbmcuIEJ1dCBsZWdhbCBub3RhcmllcyBhcmUg b2JzY3VyZSBlbm91Z2ggdGhhdCBpdCBkb2Vzbid0IG1hdHRlciBtdWNoLiBQZXJoYXBzIHNvbWUg ZXhwbGFuYXRpb24gYXMgdG8gd2hhdCBpdCBtZWFucyBpbiB0aGUgZHJhZnQgd291bGQgaGVscC4N Cg0KDQpZb3UgYXJlIGNvcnJlY3QgaW4gdGhlIGRyYWZ0LCB0aGF0IGl0IGlzIG91dCBvZiBzY29w ZSBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgd2hhdCB0aGUgZXhhY3QgY29udGVudCBvZiB0aGUgbmV3 IGF0dHJpYnV0ZSBpcy4gSG93ZXZlciwgdGhlIENQIHBheWxvYWQgaXMgY29udGFpbmVkIGluIHRo ZSBiaWdnZXN0IHBhY2tldCBvZiBhbGwgb2YgSUtFIC0gdGhlIElLRV9BVVRIIHBhY2tldHMuIENh biB5b3UgdGVsbCB1cyBob3cgbGFyZ2UgdGhlc2UgYXR0cmlidXRlcyBtYXkgYmU/IFNpbmNlIElL RSBpcyBzdGlsbCBVRFAtb25seSwgc2l6ZSBtYXR0ZXJzIHZlcnkgbXVjaC4NCg0KVGhhbmtzDQoN CllvYXYNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IHpvbmcuemFp ZmVuZ0B6dGUuY29tLmNuIFttYWlsdG86em9uZy56YWlmZW5nQHp0ZS5jb20uY25dDQpTZW50OiAy MSBKYW51YXJ5IDIwMTIgMTE6MDgNClRvOiBZb2F2IE5pcg0KQ2M6IGlwc2VjQGlldGYub3JnDQpT dWJqZWN0OiC08Li0OiBSZTogW0lQc2VjXSBbSVBTZWNdOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXpvbmctaXBzZWNtZS1pa2V2Mi1jcGV4dDRmZW10by0wMC50eHQNCg0KDQpI aSBZb2F2Og0KDQpUaGFuayB5b3UgZm9yIHlvdXIgZW1haWwuIFJlZ2FyZGluZyB0byB5b3VyIHF1 ZXN0aW9uIG9uICJ3aGF0IGlzIHRoZSBtYWxpY2lvdXMgRkFQIGx5aW5nIGFib3V0IiwgSSB3b3Vs ZCBsaWtlIHRvIGdpdmUgeW91IHNvbWUgZnVydGhlciBiYWNrZ3JvdW5kLiBJbiByZWFsIGZlbXRv IGRlcGxveW1lbnQsIG5vdCBldmVyeSBtb2JpbGUgdGVybWluYWwgaXMgYWxsb3dlZCB0byBhdHRh Y2ggdmlhIGFuIEZBUC4gSW4gZmFjdCwgaW4gdGhlIHJlYWwgZGVwbG95bWVudCwgdGhlcmUgYXJl IDMga2luZHMgb2YgRkFQczogb3BlbiBtb2RlIEZBUCwgY2xvc2UgbW9kZSBGQVAsIGFuZCBoeWJy aWQgbW9kZSBGQVAuIFRoZSBvcGVuIG1vZGUgbWVhbnMgdGhhdCB0aGUgRkFQIGlzIG9wZW4gdG8g ZXZlcnlvbmUsIGNsb3NlIG1vZGUgbWVhbnMgdGhlIEZBUCBvbmx5IGFsbG93cyBhIGNsb3NlZCBn cm91cCBvZiBtZW1iZXJzIHRvIGFjY2VzcywgYW5kIHRoZSBoeWJyaWQgbW9kZSBtZWFucyB0aGF0 IHRoZSBGQVAgaXMgb3BlbiB0byBldmVyeW9uZSwgYnV0IG9ubHkgYSBjbG9zZWQgZ3JvdXAgb2Yg bWVtYmVycyB3aWxsIGhhdmUgaGlnaGVyIHByaW9yaXR5IG9yIGhhdmUgYXV0aG9yaXR5IHRvIHZp c2l0IGNlcnRhaW4gcmVzb3VyY2VzLg0KDQpBY2NvcmRpbmcgdG8gc29tZSBTRE8gKGUuZy4gM0dQ UCksIHRoZSBhY2Nlc3MgY29udHJvbCBvZiB0aGUgbW9iaWxlIHRlcm1pbmFscyBhdHRhY2hpbmcg dmlhIGEgRkFQIGlzIGRvbmUgaW4gY29yZSBuZXR3b3JrLCB0aHVzLCBpdCBpcyB0aGUgY29yZSBu ZXR3b3JrIHRoYXQgZGVjaWRlIHdoZXRoZXIgdGhlIG1vYmlsZSB0ZXJtaW5hbCBjYW4gYXR0YWNo IHRvIGFuIEZBUC4gSW4gb3JkZXIgdG8gaGVscCB0aGUgY29yZSBuZXR3b3JrIG1ha2UgZGVjaXNp b24gb24gd2hldGhlciB0aGUgbW9iaWxlIHRlcm1pbmFsIGNhbiBhdHRhY2ggdG8gYW4gRkFQLCB0 aGUgRkFQIG5lZWRzIHRvIHNlbmQgaW5mb3JtYXRpb24sIHN1Y2ggYXMgdGhlIG1vZGUgb2YgdGhl IEZBUCwgYW5kIHRoZSBhbGxvd2VkIG1lbWJlciBncm91cCBvZiB0aGUgRkFQLCB0byB0aGUgY29y ZSBuZXR3b3JrLiBBIGNvbXByb21pc2VkIEZBUCBjb3VsZCBzZW5kIGZhbHNlIG1vZGUgYW5kIGZh bHNlIGFsbG93ZWQgbWVtYmVyIGdyb3VwIHRvIHRoZSBjb3JlIG5ldHdvcmssIHNvIHRoYXQgYSBu b3QgYWxsb3dlZCBtb2JpbGUgdGVybWluYWwgY291bGQgYmUgYWxsb3dlZCBieSB0aGUgY29yZSBu ZXR3b3JrLg0KDQpJIHdpc2ggdGhlIGFib3ZlIGNsYXJpZmljYXRpb24gaGVscHMgeW91IHVuZGVy c3RhbmQgdGhlIHByb2JsZW0uDQoNClJlZ2FyZGluZyB0byB0aGUgdGVybSBub3Rhcml6ZWQsIHNp bmNlIEkgYW0gZ3JlZW4gdG8gdGhpcyBncm91cCwgSSBhbSBub3Qgc3VyZSwgZG8geW91IHByZWZl ciB0byByZXBsYWNlIHRoZSBub3Rhcml6ZSB3aXRoIHNpZ25hdHVyZT8gUGxlYXNlIGxldCBtZSBr bm93LCB0aGFuayB5b3UhDQoNCg0KQlINClphaWZlbmcNCg0KDQoNCg0KWW9hdiBOaXIgPHluaXJA Y2hlY2twb2ludC5jb20+DQoNCjIwMTItMDEtMjEgMTU6MzANCg0KytW8/sjLDQoiPHpvbmcuemFp ZmVuZ0B6dGUuY29tLmNuPiA8em9uZy56YWlmZW5nQHp0ZS5jb20uY24+IiAgICAgICAgPHpvbmcu emFpZmVuZ0B6dGUuY29tLmNuPg0Ks63LzQ0KImlwc2VjQGlldGYub3JnIiA8aXBzZWNAaWV0Zi5v cmc+DQrW98ziDQpSZTogW0lQc2VjXSBbSVBTZWNdOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yICAgICAgICBkcmFmdC16b25nLWlwc2VjbWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0DQoN Cg0KDQoNCg0KSGkgWmFpZmVuZw0KDQpSZWFkaW5nIHlvdXIgZHJhZnQsIEknbSB0cnlpbmcgdG8g dW5kZXJzdGFuZCB0aGUgcHJvYmxlbSB5b3UgYXJlIHNvbHZpbmcuIEl0IGlzIGFib3V0IHRoZSBG QVAgYmVpbmcgY29tcHJvbWlzZWQgYW5kIHNlbmRpbmcgZmFsc2UgaW5mb3JtYXRpb24gdGhyb3Vn aCB0aGUgdHVubmVsLg0KDQpXaGF0IGlzIHRoZSBtYWxpY2lvdXMgRkFQIGx5aW5nIGFib3V0Pw0K SG93IGRvZXMgc2VuZGluZyBzb21lIGluZm9ybWF0aW9uIChkb2VzICJub3Rhcml6ZWQiIG1lYW4g InNpZ25lZCI/KSBmcm9tIHRoZSBTZUdXIHRvIHRoZSAoY29tcHJvbWlzZWQpIEZBUCBoZWxwPw0K DQpPbmUgZ2VuZXJhbCBjb21tZW50OiAibm90YXJpemVkIiBpcyBhIGxlZ2FsIHRlcm0sIHNpbWls YXIgdG8gInNpZ25hdHVyZSIuIEFsdGhvdWdoIHRoZXJlIGlzIHNvbWUgYW5hbG9neSBiZXR3ZWVu IHRoZSBsZWdhbCBjb25jZXB0IG9mIHNpZ25hdHVyZSBhbmQgdGhlIGRpZ2l0YWwgc2lnbmF0dXJl cywgc3VjaCBhbmFsb2dpZXMgb25seSBnbyBzbyBmYXIuIFVzaW5nIHN1Y2ggYSBib3Jyb3dlZCB0 ZXJtIGhhcyBJTUhPIGxlZCB0byBtb3JlIGNvbmZ1c2lvbiB0aGFuIGNsYXJpdHkuIEkgd291bGQg cmF0aGVyIG5vdCB1c2UgbGVnYWwgdGVybXMgaW4gcHJvdG9jb2xzIChhbHRob3VnaCAicHJvdG9j b2wiIGlzIGFsc28gYSBib3Jyb3dlZCB0ZXJtKQ0KDQpUaGFua3MsDQoNCllvYXYNCg0KT24gSmFu IDIwLCAyMDEyLCBhdCA4OjQwIEFNLCA8em9uZy56YWlmZW5nQHp0ZS5jb20uY24+IDx6b25nLnph aWZlbmdAenRlLmNvbS5jbj4gd3JvdGU6DQoNCj4NCj4gSGkgRm9sa3M6DQo+DQo+IFRoZXJlIGlz IGEgbmV3IGRyYWZ0IGF2YWlsYWJsZSB0aGF0IHNvbWUgb2YgeW91IG1heSBiZSBpbnRlcmVzdGVk DQo+IGluIGxvb2tpbmcgYXQuDQo+DQo+IFRoZSBkcmFmdCBpcyBhdmFpbGFibGUgdmlhIHRoZSBm b2xsb3dpbmcgbGluazoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC16b25nLWlwc2Vj bWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0DQo+DQo+IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVu dHMgdG8gdGhlIGxpc3QuIFRoYW5rcyENCj4NCj4NCj4gQlINCj4gWmFpZmVuZw0KDQoNCg0K --_000_006FEB08D9C6444AB014105C9AEB133F017A59DE7E91ilex01adche_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
So if=20 I understand this correctly, the notarized data contains the acceptable mod= e and=20 the allowed member groups, signed (and time-limited?) by the SeGW.=20
 
The=20 tunneled protocol between the FAP and the core network would change, so tha= t=20 instead of the FAP sending unsubstantiated claims, it would replay the nota= rized=20 data from the SeGW. Wouldn't this require an update of both core network=20 components, SeGW and FAPs?
 
I=20 would think that the SeGW could instead look at the decrypted protocol betw= een=20 the FAP and the core network  (it is decrypting it after all), and blo= ck it=20 if it contains "lies". A change like this would require modifying only the = SeGW.=20 I may be showing some serious firewall vendor bias here...
 
Anyway, yes, your clarification helped me very=20 much.
 
Regarding the term "notarized", I would prefer not to bring i= n a new=20 term that is burdened with other meaning. But legal notaries are obscure en= ough=20 that it doesn't matter much. Perhaps some explanation as to what it means i= n the=20 draft would help.
 
 
You=20 are correct in the draft, that it is out of scope for the working group wha= t the=20 exact content of the new attribute is. However, the CP payload is contained= in=20 the biggest packet of all of IKE - the IKE_AUTH packets. Can you tell us ho= w=20 large these attributes may be? Since IKE is still UDP-only, size matters ve= ry=20 much.
 
Thanks
 
Yoav

From: zong.zaifeng@zte.com.cn=20 [mailto:zong.zaifeng@zte.com.cn]
Sent: 21 January 2012=20 11:08
To: Yoav Nir
Cc: ipsec@ietf.org
Subject: =B4=F0=B8=B4:=20 Re: [IPsec] [IPSec]: New Version Notification for=20 draft-zong-ipsecme-ikev2-cpext4femto-00.txt


Hi Yoav:

Thank you for your email. Regarding to your question on "= what is=20 the malicious FAP lying about", I would like to give you some further=20 background. In real femto deployment, not every mobile terminal is allowed = to=20 attach via an FAP. In fact, in the real deployment, there are 3 kinds of FA= Ps:=20 open mode FAP, close mode FAP, and hybrid mode FAP. The open mode means tha= t the=20 FAP is open to everyone, close mode means the FAP only allows a closed grou= p of=20 members to access, and the hybrid mode means that the FAP is open to everyo= ne,=20 but only a closed group of members will have higher priority or have author= ity=20 to visit certain resources.

According to some SDO (e.g. 3GPP), the access control of = the=20 mobile terminals attaching via a FAP is done in core network, thus, it is t= he=20 core network that decide whether the mobile terminal can attach to an FAP. = In=20 order to help the core network make decision on whether the mobile terminal= can=20 attach to an FAP, the FAP needs to send information, such as the mode of th= e=20 FAP, and the allowed member group of the FAP, to the core network. A compro= mised=20 FAP could send false mode and false allowed member group to the core networ= k, so=20 that a not allowed mobile terminal could be allowed by the core network.=20

I wish the above clarificat= ion helps=20 you understand the problem.

Regarding to the term notarized, since I am green to this= group,=20 I am not sure, do you prefer to replace the notarize with signature? Please= let=20 me know, thank you!


BR<= /FONT>=20
Zaifeng

 


Yoav Nir=20 <ynir@checkpoint.com>

2012-01-21 15:30

=CA=D5=BC= =FE=C8=CB
"<zong.zaifeng@zte.com.cn= >=20 <zong.zaifeng@zte.com.cn>"      =20  <zong.zaifeng@zte.com.cn>=20
=B3=AD=CB= =CD
"ipsec@ietf.org"=20 <ipsec@ietf.org>=20
=D6=F7=CC= =E2
Re: [IPsec] [IPSec]: New Ver= sion=20 Notification for      =20  draft-zong-ipsecme-ikev2-cpext4femto-00.txt





Hi Zaifeng

Reading your draft, I'm trying to understand the= =20 problem you are solving. It is about the FAP being compromised and sending = false=20 information through the tunnel.

What is the malicious FAP lying=20 about?
How does sending some information (does "notarized" mean "signed"= ?)=20 from the SeGW to the (compromised) FAP help?

One general comment:=20 "notarized" is a legal term, similar to "signature". Although there is some= =20 analogy between the legal concept of signature and the digital signatures, = such=20 analogies only go so far. Using such a borrowed term has IMHO led to more=20 confusion than clarity. I would rather not use legal terms in protocols=20 (although "protocol" is also a borrowed=20 term)

Thanks,

Yoav

On Jan 20, 2012, at 8:40 AM,=20 <zong.zaifeng@zte.com.cn> <zong.zaifeng@zte.com.cn>=20 wrote:

>
> Hi Folks:
>
> There is a new draf= t=20 available that some of you may be interested
> in looking at.
>= ;=20
> The draft is available via the following link:
>=20 http://www.ietf.org/id/draft-zong-ipsecme-ikev2-cpext4femto-00.txt
>= =20
> Please send your comments to the list. Thanks!
>
>=20
> BR
> Zaifeng



--_000_006FEB08D9C6444AB014105C9AEB133F017A59DE7E91ilex01adche_-- From tso@zteusa.com Sun Jan 22 14:57:16 2012 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 E159B21F8567; Sun, 22 Jan 2012 14:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.365 X-Spam-Level: ** X-Spam-Status: No, score=2.365 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76] 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 MDGi9AEj4Nzp; Sun, 22 Jan 2012 14:57:15 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 76B6221F84BF; Sun, 22 Jan 2012 14:57:14 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690433787882; Mon, 23 Jan 2012 06:33:30 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 5467.1063234048; Mon, 23 Jan 2012 06:57:04 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q0MMuwEf002446; Mon, 23 Jan 2012 06:56:58 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F017A59DE7E91@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133F017A59DE7E91@il-ex01.ad.checkpoint.com> To: Yoav Nir MIME-Version: 1.0 X-KeepSent: FEB7E2E8:635B8C29-8825798D:0071D246; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Sun, 22 Jan 2012 14:55:15 -0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-23 06:56:59, Serialize complete at 2012-01-23 06:56:59 Content-Type: multipart/alternative; boundary="=_alternative 007E10A38825798D_=" X-MAIL: mse02.zte.com.cn q0MMuwEf002446 Cc: ipsec-bounces@ietf.org, zhou.xiaoyun@zte.com.cn, zhu.jinguo@zte.com.cn, meng.yu@zte.com.cn, "ipsec@ietf.org" , zhu.li8@zte.com.cn, "'zong.zaifeng@zte.com.cn'" , Carl Williams Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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, 22 Jan 2012 22:57:17 -0000 This is a multipart message in MIME format. --=_alternative 007E10A38825798D_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBZb2F2LCANCg0KU2luY2VyZWx5IHRoYW5rcyBmb3IgeW91ciBraW5kIHJlc3BvbnNlcyB0 byBteSBjb2xsZWFndWUgWmFpRmVuZy4gDQoNClNpbmNlIGl0IGlzIENoaW5lc2UgU3ByaW5nIEZl c3RpdmFsIGhvbGlkYXkgc3RhcnRpbmcgdG9kYXkgYW5kIHdpbGwgbGFzdCANCmZvciBhbm90aGVy IHdlZWssIEkgaGF2ZSBwcm9taXNlZCBaYWlGZW5nIHRvIHRha2UgY2FyZSBvZiB0aGUgUSZBIA0K cmVnYXJkaW5nIGhlciBJRVRGIGRyYWZ0IG9uIHRoZSBtYWlsaW5nIGxpc3QuICBIZW5jZSwgcGxl YXNlIGFsbG93IG1lIHRvIA0KcmVzcG9uZCB0byB5b3VyIHF1ZXN0aW9ucy4gDQoNCllvdSBhc2tl ZCB1cyBleGNlbGxlbnQgcXVlc3Rpb25zIHJlZ2FyZGluZyB0aGUgY2xhcmlmaWNhdGlvbnMgb24g dGhlIHJvbGVzIA0KYW5kIHJlc3BvbnNpYmlsaXRpZXMgZm9yIHRoZSBTZUdXIGFuZCB0aGUgQ29y ZSBOZXR3b3JrLiANCg0KWW9hdiBzYWlkOiANCj4+Pj4+DQpJIHdvdWxkIHRoaW5rIHRoYXQgdGhl IFNlR1cgY291bGQgaW5zdGVhZCBsb29rIGF0IHRoZSBkZWNyeXB0ZWQgcHJvdG9jb2wgDQpiZXR3 ZWVuIHRoZSBGQVAgYW5kIHRoZSBjb3JlIG5ldHdvcmsgIChpdCBpcyBkZWNyeXB0aW5nIGl0IGFm dGVyIGFsbCksIGFuZCANCmJsb2NrIGl0IGlmIGl0IGNvbnRhaW5zICJsaWVzIi4gQSBjaGFuZ2Ug bGlrZSB0aGlzIHdvdWxkIHJlcXVpcmUgbW9kaWZ5aW5nIA0Kb25seSB0aGUgU2VHVy4gSSBtYXkg YmUgc2hvd2luZyBzb21lIHNlcmlvdXMgZmlyZXdhbGwgdmVuZG9yIGJpYXMgaGVyZS4uLg0KPj4+ Pj4NClRoZSByZWFzb24gdGhhdCB3ZSBkaWQgbm90IGNvbnNpZGVyIHRoZSBTZUdXIHRvICJpbnRl cnByZXQiIHRoZSBjb250ZW50cyANCm9mIHRoZSBDUCBpbiBvcmRlciB0byBwZXJmb3JtIHRoZSBp bnRlcmNlcHRpb24gYmVjYXVzZSBvZiB0aGUgZm9sbG93aW5nIA0KdGhyZWUgcmVhc29uczoNCigx KSBBcyB5b3UgaGF2ZSBhbHJlYWR5IGtub3duIHRoYXQsIHRoZSBDUCdzIGNvbnRlbnRzIGFyZSBu b3QgZXhwZWN0ZWQgdG8gDQpiZSBkZWZpbmVkIGJ5IElFVEYuIA0KKDIpIFRoZSBTZUdXIGlzIGEg Z2VuZXJpYyBuZXR3b3JrIGVsZW1lbnQgd2hpY2ggaXMgY29tbW9ubHkgZW1wbG95ZWQgYnkgDQp0 aGUgRmVtdG8gYXJjaGl0ZWN0dXJlIGFjcm9zcyB0aGUgM0dQUCwgM0dQUDIsIFdpTUFYIGFuZCBG ZW10byBGb3J1bSwgYW5kIA0KaXMgbm90IHNwZWNpZmljIHRvIGEgcGFydGljdWxhciBtb2JpbGUg dGVjaG5vbG9neSwgaGVuY2UsIGluIG9yZGVyIGZvciB0aGUgDQpTZUdXIHRvIHBlcmZvcm0gdGhl IGludGVyY2VwdGlvbiwgaXQgd2lsbCBoYXZlIHRoZSBmdWxsIGtub3dsZWRnZSBvbiAiaG93IiAN CnRvIGludGVycHJldCB0aGUgQ1AncyBjb250ZW50cyBhY2NvcmRpbmcgdG8gdGhlIDNHUFAsIDNH UFAyIG9yIFdpTUFYIA0KZGVzaWduIGRlY2lzaW9uIHdoaWNoIGxlYWRzIHRvIHRoZSBuZXh0IHJl YXNvbiAuLg0KKDMpIFRoZXJlIGlzIG5vIHN0YW5kYXJkaXplZCBpbnRlcmZhY2UgYmV0d2VlbiB0 aGUgU2VHVyBhbmQgdGhlIE1vYmlsZSANCkNvcmUgTmV0d29yaywgaGVuY2UsIHRoZXJlIGlzIG5v IHdheSB0byBhbGxvdyB0aGUgbW9iaWxlIGNvcmUgbmV0d29yayB0byANCmR5bmFtaWNhbGx5IGNv bmZpZ3VyZSB0aGUgaW5mbyB0byB0aGUgU2VHVyB0aGF0IGlzIGNvcnJlc3BvbmRpbmcgdG8gdGhl IA0KZ2l2ZW4gbW9iaWxlIHRlY2hub2xvZ3kNCg0KR2l2ZW4gdGhlIGFib3ZlIHRocmVlIGNvbnNp ZGVyYXRpb25zLCB3ZSBkZWNpZGUgdGhhdCBieSBlbXVsYXRpbmcgdG9kYXkgDQoibm90YXJ5IiBi ZWhhdmlvciBmb3IgYWxsb3dpbmcgdGhlIHRydXN0ZWQgcGFydHkgdG8gbm90YXJpemUgdGhlIHVu dHJ1c3RlZCANCnBhcnR5IHdoaWNoIGlzIGNvbW11bmljYXRpbmcgd2l0aCB0aGUgM3JkIHBhcnR5 IGlzIGEgYmV0dGVyIGFwcHJvYWNoIHRvIA0KYWRkcmVzcyB0aGUgYXJjaGl0ZWN0dXJlIHJlc3Ry aWN0aW9ucyB0aGF0IEkgZXhwbGFpbmVkIGFib3ZlLiANCg0KWW9hdiBzYWlkOiANCj4+Pj4+DQpS ZWdhcmRpbmcgdGhlIHRlcm0gIm5vdGFyaXplZCIsIEkgd291bGQgcHJlZmVyIG5vdCB0byBicmlu ZyBpbiBhIG5ldyB0ZXJtIA0KdGhhdCBpcyBidXJkZW5lZCB3aXRoIG90aGVyIG1lYW5pbmcuIEJ1 dCBsZWdhbCBub3RhcmllcyBhcmUgb2JzY3VyZSBlbm91Z2ggDQp0aGF0IGl0IGRvZXNuJ3QgbWF0 dGVyIG11Y2guIFBlcmhhcHMgc29tZSBleHBsYW5hdGlvbiBhcyB0byB3aGF0IGl0IG1lYW5zIA0K aW4gdGhlIGRyYWZ0IHdvdWxkIGhlbHAuDQo+Pj4+Pg0KVGhlIHJlYXNvbiB0aGF0IHdlIGJvcnJv dyB0aGUgdGVybSAibm90YXJ5IiBpcyBiZWNhdXNlIG9mIHRoZSBkZXNpZ24gdGhhdCANCndlIHBy b3Bvc2UgaXMgYWxtb3N0IGlkZW50aWNhbCB0byB0aGUgY29uY2VwdCBvZiBub3RhcnkgLSBpLmUu IA0KLSBGQVAgaXMgdGhlIHVudHJ1c3RlZCBwYXJ0eSBmb3IgdGhlIG1vYmlsZSBjb3JlIG5ldHdv cmsgYW5kIGlzIHJlc2lkZWQgYXQgDQp0aGUgY3VzdG9tZXIncyBwcmVtaXNlcw0KLSBTZUdXIGlz IHRoZSB0cnVzdGVkIHBhcnR5IGZvciB0aGUgbW9iaWxlIGNvcmUgbmV0d29yayBhbmQgaXMgcmVz aWRlZCBhdCANCnRoZSBnYXRld2F5IGVudHJ5IG9mIHRoZSBtb2JpbGUgY29yZSBuZXR3b3JrDQot IFNlR1cgaGFzIGZ1bGwga25vd2xlZGdlIG9mIHRoZSB0cnVlIGlkZW50aXR5IG9mIHRoZSBGQVAg YW5kIGhlbmNlLCBvbmNlIA0KaXQgYXV0aGVudGljYXRlcyBhbmQgYXV0aG9yaXplcyB0aGUgRkFQ LCBpdCBjYW4gdGhlbiBub3Rhcml6ZSB0aGUgDQppbmZvcm1hdGlvbiB0aGF0IGlzIHByZXNlbnRl ZCBieSB0aGUgRkFQDQotIE1vYmlsZSBjb3JlIG5ldHdvcmsgdGhhdCBlbnRydXN0cyB0byBTZUdX IHdpbGwgdmVyaWZ5IHRoZSBub3Rhcml6ZWQgaW5mbyANCnByZXNlbnQgYnkgdGhlIEZBUCBpbiBv cmRlciB0byBkZXRlcm1pbmUgdGhlIGxlZ2l0aW1hY3kgb2YgdGhlIEZBUCdzIA0KaW5mb3JtYXRp b24gDQoNCkhlbmNlLCBJIHdvdWxkIGxpa2UgdG8gZm9sbG93IHlvdXIgYWR2aWNlIHRvIHByb3Bv c2UgdGhlIGZvbGxvd2luZyANCmV4cGxhbmF0aW9ucyBhZGRlZCB0byB0aGUgem9uZydzIGRyYWZ0 ICJ0ZXJtaW5vbG9neSIgc2VjdGlvbiBmb3IgdGhlIA0KY29uY2VwdHMgb2YgIm5vdGFyaXplZCBp bmZvIiBhbmQgIm5vdGFyaXplZCBzaWduYXR1cmUiOg0KTm90YXJpemVkIEluZm8gLSBJbmZvcm1h dGlvbiB0aGF0IGlzIG9yaWdpbmF0ZWQgYnkgdGhlIHVudHJ1c3RlZCBwYXJ0eSANCihlLmcuIEZB UCkgdG8gdGhlIHRydXN0ZWQgcGFydHkgKGUuZy4gU2VHVykgZm9yIHRoZSBjZXJ0aWZpY2F0aW9u IG9mIHRoZSANCmlkZW50aXR5IG9mIHRoZSB1bnRydXN0ZWQgcGFydHkgYmFzZWQgb24gUEtJLiAN Ck5vdGFyaXplZCBTaWduYXR1cmUgLSBTaWduYXR1cmUgcHJvdmlkZWQgYnkgdGhlIHRydXN0ZWQg cGFydHkgd2hvIGhhcyB0aGUgDQpmdWxsIGF1dGhvcml0eSB0byBjZXJ0aWZ5IHRoZSB0cnVlIGlk ZW50aXR5IG9mIHRoZSB1bnRydXN0ZWQgcGFydHkgYmFzZWQgDQpvbiB0aGUgUEtJLCBhbmQgdXNp bmcgdGhlIFBLSSBpbmZvcm1hdGlvbiB0byBjZXJ0aWZ5IHRoZSBzcGVjaWZpYyBjb250ZW50cyAN CndlcmUgb3JpZ2luYXRlZCBieSB0aGUgdW50cnVzdGVkIHBhcnR5LiANCg0KUmVnYXJkaW5nIHRv IHRoZSBzaXplcyBvZiB0aGUgbm90YXJpemVkIGluZm9ybWF0aW9uIGFuZCB0aGUgbm90YXJpemVk IA0Kc2lnbmF0dXJlLCB3ZSBkb24ndCBleHBlY3QgdGhlbSB0byBiZSB2ZXJ5IGxhcmdlLiAgSG93 ZXZlciwgc2luY2UgaXQgaXMgDQppbXBsZW1lbnRhdGlvbiBkZWNpc2lvbiwgaXQgaXMgaGFyZCBm b3IgdXMgdG8gcmVzcG9uZCB0byB5b3Ugb24gdGhlIGV4YWN0IA0Kc2l6ZSByaWdodCBub3cuICBJ ZiB0aGUgc2l6ZSBpcyBhIGNvbmNlcm4sIGNvdWxkIHdlIGxpbWl0IGl0IHRvIG5vIG1vcmUgDQp0 aGFuIDEwMCBieXRlcyBpZiB0aGlzIGlzIGFjY2VwdGFibGUgdG8geW91LiAgIFlvdXIgdGhvdWdo dCBpcyBtb3N0IA0KYXBwcmVjaWF0ZWQuIA0KDQpTaW5jZXJlbHkgdGhhbmtzIGluIGFkdmFuY2Ug Zm9yIHlvdXIga2luZCBhZHZpY2UuIENoZWVycy4NClRyaWNjaSANCg0KDQoNCg0KWW9hdiBOaXIg PHluaXJAY2hlY2twb2ludC5jb20+IA0KU2VudCBieTogaXBzZWMtYm91bmNlc0BpZXRmLm9yZw0K MDEvMjIvMjAxMiAwNzowNCBBTQ0KDQpUbw0KIid6b25nLnphaWZlbmdAenRlLmNvbS5jbiciIDx6 b25nLnphaWZlbmdAenRlLmNvbS5jbj4NCmNjDQoiaXBzZWNAaWV0Zi5vcmciIDxpcHNlY0BpZXRm Lm9yZz4NClN1YmplY3QNClJlOiBbSVBzZWNdIFtJUFNlY106IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiAgIGZvciANCmRyYWZ0LXpvbmctaXBzZWNtZS1pa2V2Mi1jcGV4dDRmZW10by0wMC50eHQN Cg0KDQoNCg0KDQoNClNvIGlmIEkgdW5kZXJzdGFuZCB0aGlzIGNvcnJlY3RseSwgdGhlIG5vdGFy aXplZCBkYXRhIGNvbnRhaW5zIHRoZSANCmFjY2VwdGFibGUgbW9kZSBhbmQgdGhlIGFsbG93ZWQg bWVtYmVyIGdyb3Vwcywgc2lnbmVkIChhbmQgdGltZS1saW1pdGVkPykgDQpieSB0aGUgU2VHVy4g DQogDQpUaGUgdHVubmVsZWQgcHJvdG9jb2wgYmV0d2VlbiB0aGUgRkFQIGFuZCB0aGUgY29yZSBu ZXR3b3JrIHdvdWxkIGNoYW5nZSwgDQpzbyB0aGF0IGluc3RlYWQgb2YgdGhlIEZBUCBzZW5kaW5n IHVuc3Vic3RhbnRpYXRlZCBjbGFpbXMsIGl0IHdvdWxkIHJlcGxheSANCnRoZSBub3Rhcml6ZWQg ZGF0YSBmcm9tIHRoZSBTZUdXLiBXb3VsZG4ndCB0aGlzIHJlcXVpcmUgYW4gdXBkYXRlIG9mIGJv dGggDQpjb3JlIG5ldHdvcmsgY29tcG9uZW50cywgU2VHVyBhbmQgRkFQcz8NCiANCkkgd291bGQg dGhpbmsgdGhhdCB0aGUgU2VHVyBjb3VsZCBpbnN0ZWFkIGxvb2sgYXQgdGhlIGRlY3J5cHRlZCBw cm90b2NvbCANCmJldHdlZW4gdGhlIEZBUCBhbmQgdGhlIGNvcmUgbmV0d29yayAgKGl0IGlzIGRl Y3J5cHRpbmcgaXQgYWZ0ZXIgYWxsKSwgYW5kIA0KYmxvY2sgaXQgaWYgaXQgY29udGFpbnMgImxp ZXMiLiBBIGNoYW5nZSBsaWtlIHRoaXMgd291bGQgcmVxdWlyZSBtb2RpZnlpbmcgDQpvbmx5IHRo ZSBTZUdXLiBJIG1heSBiZSBzaG93aW5nIHNvbWUgc2VyaW91cyBmaXJld2FsbCB2ZW5kb3IgYmlh cyBoZXJlLi4uDQogDQpBbnl3YXksIHllcywgeW91ciBjbGFyaWZpY2F0aW9uIGhlbHBlZCBtZSB2 ZXJ5IG11Y2guDQogDQpSZWdhcmRpbmcgdGhlIHRlcm0gIm5vdGFyaXplZCIsIEkgd291bGQgcHJl ZmVyIG5vdCB0byBicmluZyBpbiBhIG5ldyB0ZXJtIA0KdGhhdCBpcyBidXJkZW5lZCB3aXRoIG90 aGVyIG1lYW5pbmcuIEJ1dCBsZWdhbCBub3RhcmllcyBhcmUgb2JzY3VyZSBlbm91Z2ggDQp0aGF0 IGl0IGRvZXNuJ3QgbWF0dGVyIG11Y2guIFBlcmhhcHMgc29tZSBleHBsYW5hdGlvbiBhcyB0byB3 aGF0IGl0IG1lYW5zIA0KaW4gdGhlIGRyYWZ0IHdvdWxkIGhlbHAuDQogDQpZb3UgYXJlIGNvcnJl Y3QgaW4gdGhlIGRyYWZ0LCB0aGF0IGl0IGlzIG91dCBvZiBzY29wZSBmb3IgdGhlIHdvcmtpbmcg DQpncm91cCB3aGF0IHRoZSBleGFjdCBjb250ZW50IG9mIHRoZSBuZXcgYXR0cmlidXRlIGlzLiBI b3dldmVyLCB0aGUgQ1AgDQpwYXlsb2FkIGlzIGNvbnRhaW5lZCBpbiB0aGUgYmlnZ2VzdCBwYWNr ZXQgb2YgYWxsIG9mIElLRSAtIHRoZSBJS0VfQVVUSCANCnBhY2tldHMuIENhbiB5b3UgdGVsbCB1 cyBob3cgbGFyZ2UgdGhlc2UgYXR0cmlidXRlcyBtYXkgYmU/IFNpbmNlIElLRSBpcyANCnN0aWxs IFVEUC1vbmx5LCBzaXplIG1hdHRlcnMgdmVyeSBtdWNoLg0KIA0KVGhhbmtzDQogDQpZb2F2DQoN CkZyb206IHpvbmcuemFpZmVuZ0B6dGUuY29tLmNuIFttYWlsdG86em9uZy56YWlmZW5nQHp0ZS5j b20uY25dIA0KU2VudDogMjEgSmFudWFyeSAyMDEyIDExOjA4DQpUbzogWW9hdiBOaXINCkNjOiBp cHNlY0BpZXRmLm9yZw0KU3ViamVjdDogtPC4tDogUmU6IFtJUHNlY10gW0lQU2VjXTogTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciANCmRyYWZ0LXpvbmctaXBzZWNtZS1pa2V2Mi1jcGV4dDRm ZW10by0wMC50eHQNCg0KDQpIaSBZb2F2OiANCg0KVGhhbmsgeW91IGZvciB5b3VyIGVtYWlsLiBS ZWdhcmRpbmcgdG8geW91ciBxdWVzdGlvbiBvbiAid2hhdCBpcyB0aGUgDQptYWxpY2lvdXMgRkFQ IGx5aW5nIGFib3V0IiwgSSB3b3VsZCBsaWtlIHRvIGdpdmUgeW91IHNvbWUgZnVydGhlciANCmJh Y2tncm91bmQuIEluIHJlYWwgZmVtdG8gZGVwbG95bWVudCwgbm90IGV2ZXJ5IG1vYmlsZSB0ZXJt aW5hbCBpcyBhbGxvd2VkIA0KdG8gYXR0YWNoIHZpYSBhbiBGQVAuIEluIGZhY3QsIGluIHRoZSBy ZWFsIGRlcGxveW1lbnQsIHRoZXJlIGFyZSAzIGtpbmRzIA0Kb2YgRkFQczogb3BlbiBtb2RlIEZB UCwgY2xvc2UgbW9kZSBGQVAsIGFuZCBoeWJyaWQgbW9kZSBGQVAuIFRoZSBvcGVuIG1vZGUgDQpt ZWFucyB0aGF0IHRoZSBGQVAgaXMgb3BlbiB0byBldmVyeW9uZSwgY2xvc2UgbW9kZSBtZWFucyB0 aGUgRkFQIG9ubHkgDQphbGxvd3MgYSBjbG9zZWQgZ3JvdXAgb2YgbWVtYmVycyB0byBhY2Nlc3Ms IGFuZCB0aGUgaHlicmlkIG1vZGUgbWVhbnMgdGhhdCANCnRoZSBGQVAgaXMgb3BlbiB0byBldmVy eW9uZSwgYnV0IG9ubHkgYSBjbG9zZWQgZ3JvdXAgb2YgbWVtYmVycyB3aWxsIGhhdmUgDQpoaWdo ZXIgcHJpb3JpdHkgb3IgaGF2ZSBhdXRob3JpdHkgdG8gdmlzaXQgY2VydGFpbiByZXNvdXJjZXMu IA0KDQpBY2NvcmRpbmcgdG8gc29tZSBTRE8gKGUuZy4gM0dQUCksIHRoZSBhY2Nlc3MgY29udHJv bCBvZiB0aGUgbW9iaWxlIA0KdGVybWluYWxzIGF0dGFjaGluZyB2aWEgYSBGQVAgaXMgZG9uZSBp biBjb3JlIG5ldHdvcmssIHRodXMsIGl0IGlzIHRoZSANCmNvcmUgbmV0d29yayB0aGF0IGRlY2lk ZSB3aGV0aGVyIHRoZSBtb2JpbGUgdGVybWluYWwgY2FuIGF0dGFjaCB0byBhbiBGQVAuIA0KSW4g b3JkZXIgdG8gaGVscCB0aGUgY29yZSBuZXR3b3JrIG1ha2UgZGVjaXNpb24gb24gd2hldGhlciB0 aGUgbW9iaWxlIA0KdGVybWluYWwgY2FuIGF0dGFjaCB0byBhbiBGQVAsIHRoZSBGQVAgbmVlZHMg dG8gc2VuZCBpbmZvcm1hdGlvbiwgc3VjaCBhcyANCnRoZSBtb2RlIG9mIHRoZSBGQVAsIGFuZCB0 aGUgYWxsb3dlZCBtZW1iZXIgZ3JvdXAgb2YgdGhlIEZBUCwgdG8gdGhlIGNvcmUgDQpuZXR3b3Jr LiBBIGNvbXByb21pc2VkIEZBUCBjb3VsZCBzZW5kIGZhbHNlIG1vZGUgYW5kIGZhbHNlIGFsbG93 ZWQgbWVtYmVyIA0KZ3JvdXAgdG8gdGhlIGNvcmUgbmV0d29yaywgc28gdGhhdCBhIG5vdCBhbGxv d2VkIG1vYmlsZSB0ZXJtaW5hbCBjb3VsZCBiZSANCmFsbG93ZWQgYnkgdGhlIGNvcmUgbmV0d29y ay4gDQoNCkkgd2lzaCB0aGUgYWJvdmUgY2xhcmlmaWNhdGlvbiBoZWxwcyB5b3UgdW5kZXJzdGFu ZCB0aGUgcHJvYmxlbS4gDQoNClJlZ2FyZGluZyB0byB0aGUgdGVybSBub3Rhcml6ZWQsIHNpbmNl IEkgYW0gZ3JlZW4gdG8gdGhpcyBncm91cCwgSSBhbSBub3QgDQpzdXJlLCBkbyB5b3UgcHJlZmVy IHRvIHJlcGxhY2UgdGhlIG5vdGFyaXplIHdpdGggc2lnbmF0dXJlPyBQbGVhc2UgbGV0IG1lIA0K a25vdywgdGhhbmsgeW91ISANCg0KDQpCUiANClphaWZlbmcgDQoNCiAgDQoNCg0KWW9hdiBOaXIg PHluaXJAY2hlY2twb2ludC5jb20+IA0KMjAxMi0wMS0yMSAxNTozMCANCg0KDQrK1bz+yMsNCiI8 em9uZy56YWlmZW5nQHp0ZS5jb20uY24+IDx6b25nLnphaWZlbmdAenRlLmNvbS5jbj4iIA0KPHpv bmcuemFpZmVuZ0B6dGUuY29tLmNuPiANCrOty80NCiJpcHNlY0BpZXRmLm9yZyIgPGlwc2VjQGll dGYub3JnPiANCtb3zOINClJlOiBbSVBzZWNdIFtJUFNlY106IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgDQpkcmFmdC16b25nLWlwc2VjbWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0DQoN Cg0KDQoNCg0KDQoNCg0KSGkgWmFpZmVuZw0KDQpSZWFkaW5nIHlvdXIgZHJhZnQsIEknbSB0cnlp bmcgdG8gdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSB5b3UgYXJlIHNvbHZpbmcuIA0KSXQgaXMgYWJv dXQgdGhlIEZBUCBiZWluZyBjb21wcm9taXNlZCBhbmQgc2VuZGluZyBmYWxzZSBpbmZvcm1hdGlv biANCnRocm91Z2ggdGhlIHR1bm5lbC4NCg0KV2hhdCBpcyB0aGUgbWFsaWNpb3VzIEZBUCBseWlu ZyBhYm91dD8NCkhvdyBkb2VzIHNlbmRpbmcgc29tZSBpbmZvcm1hdGlvbiAoZG9lcyAibm90YXJp emVkIiBtZWFuICJzaWduZWQiPykgZnJvbSANCnRoZSBTZUdXIHRvIHRoZSAoY29tcHJvbWlzZWQp IEZBUCBoZWxwPw0KDQpPbmUgZ2VuZXJhbCBjb21tZW50OiAibm90YXJpemVkIiBpcyBhIGxlZ2Fs IHRlcm0sIHNpbWlsYXIgdG8gInNpZ25hdHVyZSIuIA0KQWx0aG91Z2ggdGhlcmUgaXMgc29tZSBh bmFsb2d5IGJldHdlZW4gdGhlIGxlZ2FsIGNvbmNlcHQgb2Ygc2lnbmF0dXJlIGFuZCANCnRoZSBk aWdpdGFsIHNpZ25hdHVyZXMsIHN1Y2ggYW5hbG9naWVzIG9ubHkgZ28gc28gZmFyLiBVc2luZyBz dWNoIGEgDQpib3Jyb3dlZCB0ZXJtIGhhcyBJTUhPIGxlZCB0byBtb3JlIGNvbmZ1c2lvbiB0aGFu IGNsYXJpdHkuIEkgd291bGQgcmF0aGVyIA0Kbm90IHVzZSBsZWdhbCB0ZXJtcyBpbiBwcm90b2Nv bHMgKGFsdGhvdWdoICJwcm90b2NvbCIgaXMgYWxzbyBhIGJvcnJvd2VkIA0KdGVybSkNCg0KVGhh bmtzLA0KDQpZb2F2DQoNCk9uIEphbiAyMCwgMjAxMiwgYXQgODo0MCBBTSwgPHpvbmcuemFpZmVu Z0B6dGUuY29tLmNuPiANCjx6b25nLnphaWZlbmdAenRlLmNvbS5jbj4gd3JvdGU6DQoNCj4gDQo+ IEhpIEZvbGtzOiANCj4gDQo+IFRoZXJlIGlzIGEgbmV3IGRyYWZ0IGF2YWlsYWJsZSB0aGF0IHNv bWUgb2YgeW91IG1heSBiZSBpbnRlcmVzdGVkDQo+IGluIGxvb2tpbmcgYXQuIA0KPiANCj4gVGhl IGRyYWZ0IGlzIGF2YWlsYWJsZSB2aWEgdGhlIGZvbGxvd2luZyBsaW5rOiANCj4gaHR0cDovL3d3 dy5pZXRmLm9yZy9pZC9kcmFmdC16b25nLWlwc2VjbWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0 IA0KPiANCj4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdC4gVGhhbmtzISAN Cj4gDQo+IA0KPiBCUiANCj4gWmFpZmVuZyANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KSVBzZWMgbWFpbGluZyBsaXN0DQpJUHNlY0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYw0KDQoNCg0KDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6 YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50 cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBu b3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRp b24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGgg aXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmln aW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2Fn ZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBi ZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0u DQo= --=_alternative 007E10A38825798D_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgWW9hdiwgPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5TaW5jZXJlbHkgdGhhbmtzIGZvciB5 b3VyIGtpbmQgcmVzcG9uc2VzDQp0byBteSBjb2xsZWFndWUgWmFpRmVuZy4gPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5TaW5jZSBpdCBpcyBDaGluZXNl IFNwcmluZyBGZXN0aXZhbA0KaG9saWRheSBzdGFydGluZyB0b2RheSBhbmQgd2lsbCBsYXN0IGZv ciBhbm90aGVyIHdlZWssIEkgaGF2ZSBwcm9taXNlZA0KWmFpRmVuZyB0byB0YWtlIGNhcmUgb2Yg dGhlIFEmYW1wO0EgcmVnYXJkaW5nIGhlciBJRVRGIGRyYWZ0IG9uIHRoZSBtYWlsaW5nDQpsaXN0 LiAmbmJzcDtIZW5jZSwgcGxlYXNlIGFsbG93IG1lIHRvIHJlc3BvbmQgdG8geW91ciBxdWVzdGlv bnMuIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+WW91 IGFza2VkIHVzIGV4Y2VsbGVudCBxdWVzdGlvbnMgcmVnYXJkaW5nDQp0aGUgY2xhcmlmaWNhdGlv bnMgb24gdGhlIHJvbGVzIGFuZCByZXNwb25zaWJpbGl0aWVzIGZvciB0aGUgU2VHVyBhbmQgdGhl DQpDb3JlIE5ldHdvcmsuICZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+WW9hdiBzYWlkOiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MyBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+SSB3b3VsZCB0aGluayB0aGF0IHRoZSBTZUdXIGNv dWxkDQppbnN0ZWFkIGxvb2sgYXQgdGhlIGRlY3J5cHRlZCBwcm90b2NvbCBiZXR3ZWVuIHRoZSBG QVAgYW5kIHRoZSBjb3JlIG5ldHdvcmsNCiZuYnNwOyhpdCBpcyBkZWNyeXB0aW5nIGl0IGFmdGVy IGFsbCksIGFuZCBibG9jayBpdCBpZiBpdCBjb250YWlucyAmcXVvdDtsaWVzJnF1b3Q7Lg0KQSBj aGFuZ2UgbGlrZSB0aGlzIHdvdWxkIHJlcXVpcmUgbW9kaWZ5aW5nIG9ubHkgdGhlIFNlR1cuIEkg bWF5IGJlIHNob3dpbmcNCnNvbWUgc2VyaW91cyBmaXJld2FsbCB2ZW5kb3IgYmlhcyBoZXJlLi4u PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIHJl YXNvbiB0aGF0IHdlIGRpZCBub3QgY29uc2lkZXINCnRoZSBTZUdXIHRvICZxdW90O2ludGVycHJl dCZxdW90OyB0aGUgY29udGVudHMgb2YgdGhlIENQIGluIG9yZGVyIHRvIHBlcmZvcm0NCnRoZSBp bnRlcmNlcHRpb24gYmVjYXVzZSBvZiB0aGUgZm9sbG93aW5nIHRocmVlIHJlYXNvbnM6PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4oMSkgQXMgeW91IGhhdmUgYWxy ZWFkeSBrbm93biB0aGF0LA0KdGhlIENQJ3MgY29udGVudHMgYXJlIG5vdCBleHBlY3RlZCB0byBi ZSBkZWZpbmVkIGJ5IElFVEYuICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0i c2Fucy1zZXJpZiI+KDIpIFRoZSBTZUdXIGlzIGEgZ2VuZXJpYyBuZXR3b3JrIGVsZW1lbnQNCndo aWNoIGlzIGNvbW1vbmx5IGVtcGxveWVkIGJ5IHRoZSBGZW10byBhcmNoaXRlY3R1cmUgYWNyb3Nz IHRoZSAzR1BQLCAzR1BQMiwNCldpTUFYIGFuZCBGZW10byBGb3J1bSwgYW5kIGlzIG5vdCBzcGVj aWZpYyB0byBhIHBhcnRpY3VsYXIgbW9iaWxlIHRlY2hub2xvZ3ksDQpoZW5jZSwgaW4gb3JkZXIg Zm9yIHRoZSBTZUdXIHRvIHBlcmZvcm0gdGhlIGludGVyY2VwdGlvbiwgaXQgd2lsbCBoYXZlDQp0 aGUgZnVsbCBrbm93bGVkZ2Ugb24gJnF1b3Q7aG93JnF1b3Q7IHRvIGludGVycHJldCB0aGUgQ1An cyBjb250ZW50cyBhY2NvcmRpbmcNCnRvIHRoZSAzR1BQLCAzR1BQMiBvciBXaU1BWCBkZXNpZ24g ZGVjaXNpb24gd2hpY2ggbGVhZHMgdG8gdGhlIG5leHQgcmVhc29uDQouLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+KDMpIFRoZXJlIGlzIG5vIHN0YW5kYXJkaXpl ZCBpbnRlcmZhY2UNCmJldHdlZW4gdGhlIFNlR1cgYW5kIHRoZSBNb2JpbGUgQ29yZSBOZXR3b3Jr LCBoZW5jZSwgdGhlcmUgaXMgbm8gd2F5IHRvDQphbGxvdyB0aGUgbW9iaWxlIGNvcmUgbmV0d29y ayB0byBkeW5hbWljYWxseSBjb25maWd1cmUgdGhlIGluZm8gdG8gdGhlDQpTZUdXIHRoYXQgaXMg Y29ycmVzcG9uZGluZyB0byB0aGUgZ2l2ZW4gbW9iaWxlIHRlY2hub2xvZ3k8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkdpdmVuIHRoZSBhYm92ZSB0aHJl ZSBjb25zaWRlcmF0aW9ucywNCndlIGRlY2lkZSB0aGF0IGJ5IGVtdWxhdGluZyB0b2RheSAmcXVv dDtub3RhcnkmcXVvdDsgYmVoYXZpb3IgZm9yIGFsbG93aW5nDQp0aGUgdHJ1c3RlZCBwYXJ0eSB0 byBub3Rhcml6ZSB0aGUgdW50cnVzdGVkIHBhcnR5IHdoaWNoIGlzIGNvbW11bmljYXRpbmcNCndp dGggdGhlIDNyZCBwYXJ0eSBpcyBhIGJldHRlciBhcHByb2FjaCB0byBhZGRyZXNzIHRoZSBhcmNo aXRlY3R1cmUgcmVzdHJpY3Rpb25zDQp0aGF0IEkgZXhwbGFpbmVkIGFib3ZlLiA8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPllvYXYgc2FpZDogPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPlJlZ2Fy ZGluZyB0aGUgdGVybSAmcXVvdDtub3Rhcml6ZWQmcXVvdDssDQpJIHdvdWxkIHByZWZlciBub3Qg dG8gYnJpbmcgaW4gYSBuZXcgdGVybSB0aGF0IGlzIGJ1cmRlbmVkIHdpdGggb3RoZXIgbWVhbmlu Zy4NCkJ1dCBsZWdhbCBub3RhcmllcyBhcmUgb2JzY3VyZSBlbm91Z2ggdGhhdCBpdCBkb2Vzbid0 IG1hdHRlciBtdWNoLiBQZXJoYXBzDQpzb21lIGV4cGxhbmF0aW9uIGFzIHRvIHdoYXQgaXQgbWVh bnMgaW4gdGhlIGRyYWZ0IHdvdWxkIGhlbHAuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIHJlYXNvbiB0aGF0IHdlIGJvcnJvdyB0aGUgdGVybSAm cXVvdDtub3RhcnkmcXVvdDsNCmlzIGJlY2F1c2Ugb2YgdGhlIGRlc2lnbiB0aGF0IHdlIHByb3Bv c2UgaXMgYWxtb3N0IGlkZW50aWNhbCB0byB0aGUgY29uY2VwdA0Kb2Ygbm90YXJ5IC0gaS5lLiA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPi0gRkFQIGlzIHRoZSB1 bnRydXN0ZWQgcGFydHkgZm9yIHRoZQ0KbW9iaWxlIGNvcmUgbmV0d29yayBhbmQgaXMgcmVzaWRl ZCBhdCB0aGUgY3VzdG9tZXIncyBwcmVtaXNlczwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+LSBTZUdXIGlzIHRoZSB0cnVzdGVkIHBhcnR5IGZvciB0aGUNCm1vYmls ZSBjb3JlIG5ldHdvcmsgYW5kIGlzIHJlc2lkZWQgYXQgdGhlIGdhdGV3YXkgZW50cnkgb2YgdGhl IG1vYmlsZSBjb3JlDQpuZXR3b3JrPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4tIFNlR1cgaGFzIGZ1bGwga25vd2xlZGdlIG9mIHRoZSB0cnVlDQppZGVudGl0eSBv ZiB0aGUgRkFQIGFuZCBoZW5jZSwgb25jZSBpdCBhdXRoZW50aWNhdGVzIGFuZCBhdXRob3JpemVz IHRoZQ0KRkFQLCBpdCBjYW4gdGhlbiBub3Rhcml6ZSB0aGUgaW5mb3JtYXRpb24gdGhhdCBpcyBw cmVzZW50ZWQgYnkgdGhlIEZBUDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+LSBNb2JpbGUgY29yZSBuZXR3b3JrIHRoYXQgZW50cnVzdHMNCnRvIFNlR1cgd2lsbCB2 ZXJpZnkgdGhlIG5vdGFyaXplZCBpbmZvIHByZXNlbnQgYnkgdGhlIEZBUCBpbiBvcmRlciB0byBk ZXRlcm1pbmUNCnRoZSBsZWdpdGltYWN5IG9mIHRoZSBGQVAncyBpbmZvcm1hdGlvbiA8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkhlbmNlLCBJIHdvdWxk IGxpa2UgdG8gZm9sbG93IHlvdXIgYWR2aWNlDQp0byBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgZXhw bGFuYXRpb25zIGFkZGVkIHRvIHRoZSB6b25nJ3MgZHJhZnQgJnF1b3Q7dGVybWlub2xvZ3kmcXVv dDsNCnNlY3Rpb24gZm9yIHRoZSBjb25jZXB0cyBvZiAmcXVvdDtub3Rhcml6ZWQgaW5mbyZxdW90 OyBhbmQgJnF1b3Q7bm90YXJpemVkDQpzaWduYXR1cmUmcXVvdDs6PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Ob3Rhcml6ZWQgSW5mbzwvYj4gLSBJbmZvcm1h dGlvbg0KdGhhdCBpcyBvcmlnaW5hdGVkIGJ5IHRoZSB1bnRydXN0ZWQgcGFydHkgKGUuZy4gRkFQ KSB0byB0aGUgdHJ1c3RlZCBwYXJ0eQ0KKGUuZy4gU2VHVykgZm9yIHRoZSBjZXJ0aWZpY2F0aW9u IG9mIHRoZSBpZGVudGl0eSBvZiB0aGUgdW50cnVzdGVkIHBhcnR5DQpiYXNlZCBvbiBQS0kuIDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Tm90YXJpemVkIFNp Z25hdHVyZTwvYj4gLSBTaWduYXR1cmUNCnByb3ZpZGVkIGJ5IHRoZSB0cnVzdGVkIHBhcnR5IHdo byBoYXMgdGhlIGZ1bGwgYXV0aG9yaXR5IHRvIGNlcnRpZnkgdGhlDQp0cnVlIGlkZW50aXR5IG9m IHRoZSB1bnRydXN0ZWQgcGFydHkgYmFzZWQgb24gdGhlIFBLSSwgYW5kIHVzaW5nIHRoZSBQS0kN CmluZm9ybWF0aW9uIHRvIGNlcnRpZnkgdGhlIHNwZWNpZmljIGNvbnRlbnRzIHdlcmUgb3JpZ2lu YXRlZCBieSB0aGUgdW50cnVzdGVkDQpwYXJ0eS4gJm5ic3A7IDwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+UmVnYXJkaW5nIHRvIHRoZSBzaXplcyBvZiB0 aGUgbm90YXJpemVkDQppbmZvcm1hdGlvbiBhbmQgdGhlIG5vdGFyaXplZCBzaWduYXR1cmUsIHdl IGRvbid0IGV4cGVjdCB0aGVtIHRvIGJlIHZlcnkNCmxhcmdlLiAmbmJzcDtIb3dldmVyLCBzaW5j ZSBpdCBpcyBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbiwgaXQgaXMgaGFyZCBmb3INCnVzIHRvIHJl c3BvbmQgdG8geW91IG9uIHRoZSBleGFjdCBzaXplIHJpZ2h0IG5vdy4gJm5ic3A7SWYgdGhlIHNp emUgaXMNCmEgY29uY2VybiwgY291bGQgd2UgbGltaXQgaXQgdG8gbm8gbW9yZSB0aGFuIDEwMCBi eXRlcyBpZiB0aGlzIGlzIGFjY2VwdGFibGUNCnRvIHlvdS4gJm5ic3A7IFlvdXIgdGhvdWdodCBp cyBtb3N0IGFwcHJlY2lhdGVkLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 InNhbnMtc2VyaWYiPlNpbmNlcmVseSB0aGFua3MgaW4gYWR2YW5jZSBmb3IgeW91cg0Ka2luZCBh ZHZpY2UuIENoZWVycy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PlRyaWNjaSAmbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+WW9hdiBOaXIgJmx0O3luaXJAY2hlY2twb2ludC5jb20mZ3Q7PC9i Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TZW50IGJ5OiBp cHNlYy1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjAxLzIyLzIwMTIgMDc6MDQgQU08L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlRvPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDsnem9uZy56YWlmZW5nQHp0ZS5jb20uY24nJnF1 b3Q7DQombHQ7em9uZy56YWlmZW5nQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5jYzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1 b3Q7aXBzZWNAaWV0Zi5vcmcmcXVvdDsgJmx0O2lwc2VjQGlldGYub3JnJmd0OzwvZm9udD4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+U3ViamVjdDwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+UmU6IFtJUHNlY10gW0lQU2VjXTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmb3IgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ZHJhZnQtem9uZy1pcHNlY21lLWlrZXYyLWNwZXh0NGZlbXRvLTAwLnR4dDwvZm9udD48L3Rh YmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4N Cjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9IlRhaG9tYSI+U28gaWYgSSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5LA0KdGhlIG5vdGFy aXplZCBkYXRhIGNvbnRhaW5zIHRoZSBhY2NlcHRhYmxlIG1vZGUgYW5kIHRoZSBhbGxvd2VkIG1l bWJlcg0KZ3JvdXBzLCBzaWduZWQgKGFuZCB0aW1lLWxpbWl0ZWQ/KSBieSB0aGUgU2VHVy4gPC9m b250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj5UaGUgdHVubmVsZWQgcHJv dG9jb2wgYmV0d2Vlbg0KdGhlIEZBUCBhbmQgdGhlIGNvcmUgbmV0d29yayB3b3VsZCBjaGFuZ2Us IHNvIHRoYXQgaW5zdGVhZCBvZiB0aGUgRkFQIHNlbmRpbmcNCnVuc3Vic3RhbnRpYXRlZCBjbGFp bXMsIGl0IHdvdWxkIHJlcGxheSB0aGUgbm90YXJpemVkIGRhdGEgZnJvbSB0aGUgU2VHVy4NCldv dWxkbid0IHRoaXMgcmVxdWlyZSBhbiB1cGRhdGUgb2YgYm90aCBjb3JlIG5ldHdvcmsgY29tcG9u ZW50cywgU2VHVyBhbmQNCkZBUHM/PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i VGFob21hIj5JIHdvdWxkIHRoaW5rIHRoYXQgdGhlIFNlR1cgY291bGQNCmluc3RlYWQgbG9vayBh dCB0aGUgZGVjcnlwdGVkIHByb3RvY29sIGJldHdlZW4gdGhlIEZBUCBhbmQgdGhlIGNvcmUgbmV0 d29yaw0KJm5ic3A7KGl0IGlzIGRlY3J5cHRpbmcgaXQgYWZ0ZXIgYWxsKSwgYW5kIGJsb2NrIGl0 IGlmIGl0IGNvbnRhaW5zICZxdW90O2xpZXMmcXVvdDsuDQpBIGNoYW5nZSBsaWtlIHRoaXMgd291 bGQgcmVxdWlyZSBtb2RpZnlpbmcgb25seSB0aGUgU2VHVy4gSSBtYXkgYmUgc2hvd2luZw0Kc29t ZSBzZXJpb3VzIGZpcmV3YWxsIHZlbmRvciBiaWFzIGhlcmUuLi48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPkFueXdheSwgeWVzLCB5b3VyIGNsYXJpZmljYXRpb24N CmhlbHBlZCBtZSB2ZXJ5IG11Y2guPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i VGFob21hIj5SZWdhcmRpbmcgdGhlIHRlcm0gJnF1b3Q7bm90YXJpemVkJnF1b3Q7LA0KSSB3b3Vs ZCBwcmVmZXIgbm90IHRvIGJyaW5nIGluIGEgbmV3IHRlcm0gdGhhdCBpcyBidXJkZW5lZCB3aXRo IG90aGVyIG1lYW5pbmcuDQpCdXQgbGVnYWwgbm90YXJpZXMgYXJlIG9ic2N1cmUgZW5vdWdoIHRo YXQgaXQgZG9lc24ndCBtYXR0ZXIgbXVjaC4gUGVyaGFwcw0Kc29tZSBleHBsYW5hdGlvbiBhcyB0 byB3aGF0IGl0IG1lYW5zIGluIHRoZSBkcmFmdCB3b3VsZCBoZWxwLjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+WW91IGFyZSBjb3JyZWN0IGluIHRoZSBkcmFmdCwN CnRoYXQgaXQgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGUgd29ya2luZyBncm91cCB3aGF0IHRoZSBl eGFjdCBjb250ZW50IG9mDQp0aGUgbmV3IGF0dHJpYnV0ZSBpcy4gSG93ZXZlciwgdGhlIENQIHBh eWxvYWQgaXMgY29udGFpbmVkIGluIHRoZSBiaWdnZXN0DQpwYWNrZXQgb2YgYWxsIG9mIElLRSAt IHRoZSBJS0VfQVVUSCBwYWNrZXRzLiBDYW4geW91IHRlbGwgdXMgaG93IGxhcmdlDQp0aGVzZSBh dHRyaWJ1dGVzIG1heSBiZT8gU2luY2UgSUtFIGlzIHN0aWxsIFVEUC1vbmx5LCBzaXplIG1hdHRl cnMgdmVyeQ0KbXVjaC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEi PlRoYW5rczwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+WW9hdjwv Zm9udD4NCjxicj4NCjxicj4NCjxocj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9t OjwvYj4gem9uZy56YWlmZW5nQHp0ZS5jb20uY24gWzwvZm9udD48YSBocmVmPW1haWx0bzp6b25n LnphaWZlbmdAenRlLmNvbS5jbj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5tYWlsdG86em9u Zy56YWlmZW5nQHp0ZS5jb20uY248L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEi Pl0NCjxiPjxicj4NClNlbnQ6PC9iPiAyMSBKYW51YXJ5IDIwMTIgMTE6MDg8Yj48YnI+DQpUbzo8 L2I+IFlvYXYgTmlyPGI+PGJyPg0KQ2M6PC9iPiBpcHNlY0BpZXRmLm9yZzxiPjxicj4NClN1Ympl Y3Q6PC9iPiC08Li0OiBSZTogW0lQc2VjXSBbSVBTZWNdOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yDQpkcmFmdC16b25nLWlwc2VjbWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpIFlvYXY6PC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQpUaGFuayB5b3UgZm9yIHlvdXIgZW1haWwuIFJlZ2FyZGluZyB0byB5b3Vy IHF1ZXN0aW9uIG9uICZxdW90O3doYXQgaXMgdGhlDQptYWxpY2lvdXMgRkFQIGx5aW5nIGFib3V0 JnF1b3Q7LCBJIHdvdWxkIGxpa2UgdG8gZ2l2ZSB5b3Ugc29tZSBmdXJ0aGVyDQpiYWNrZ3JvdW5k LiBJbiByZWFsIGZlbXRvIGRlcGxveW1lbnQsIG5vdCBldmVyeSBtb2JpbGUgdGVybWluYWwgaXMg YWxsb3dlZA0KdG8gYXR0YWNoIHZpYSBhbiBGQVAuIEluIGZhY3QsIGluIHRoZSByZWFsIGRlcGxv eW1lbnQsIHRoZXJlIGFyZSAzIGtpbmRzDQpvZiBGQVBzOiBvcGVuIG1vZGUgRkFQLCBjbG9zZSBt b2RlIEZBUCwgYW5kIGh5YnJpZCBtb2RlIEZBUC4gVGhlIG9wZW4gbW9kZQ0KbWVhbnMgdGhhdCB0 aGUgRkFQIGlzIG9wZW4gdG8gZXZlcnlvbmUsIGNsb3NlIG1vZGUgbWVhbnMgdGhlIEZBUCBvbmx5 IGFsbG93cw0KYSBjbG9zZWQgZ3JvdXAgb2YgbWVtYmVycyB0byBhY2Nlc3MsIGFuZCB0aGUgaHli cmlkIG1vZGUgbWVhbnMgdGhhdCB0aGUNCkZBUCBpcyBvcGVuIHRvIGV2ZXJ5b25lLCBidXQgb25s eSBhIGNsb3NlZCBncm91cCBvZiBtZW1iZXJzIHdpbGwgaGF2ZSBoaWdoZXINCnByaW9yaXR5IG9y IGhhdmUgYXV0aG9yaXR5IHRvIHZpc2l0IGNlcnRhaW4gcmVzb3VyY2VzLjwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCkFjY29yZGluZyB0byBzb21lIFNETyAoZS5nLiAzR1BQKSwgdGhl IGFjY2VzcyBjb250cm9sIG9mIHRoZSBtb2JpbGUgdGVybWluYWxzDQphdHRhY2hpbmcgdmlhIGEg RkFQIGlzIGRvbmUgaW4gY29yZSBuZXR3b3JrLCB0aHVzLCBpdCBpcyB0aGUgY29yZSBuZXR3b3Jr DQp0aGF0IGRlY2lkZSB3aGV0aGVyIHRoZSBtb2JpbGUgdGVybWluYWwgY2FuIGF0dGFjaCB0byBh biBGQVAuIEluIG9yZGVyDQp0byBoZWxwIHRoZSBjb3JlIG5ldHdvcmsgbWFrZSBkZWNpc2lvbiBv biB3aGV0aGVyIHRoZSBtb2JpbGUgdGVybWluYWwgY2FuDQphdHRhY2ggdG8gYW4gRkFQLCB0aGUg RkFQIG5lZWRzIHRvIHNlbmQgaW5mb3JtYXRpb24sIHN1Y2ggYXMgdGhlIG1vZGUgb2YNCnRoZSBG QVAsIGFuZCB0aGUgYWxsb3dlZCBtZW1iZXIgZ3JvdXAgb2YgdGhlIEZBUCwgdG8gdGhlIGNvcmUg bmV0d29yay4NCkEgY29tcHJvbWlzZWQgRkFQIGNvdWxkIHNlbmQgZmFsc2UgbW9kZSBhbmQgZmFs c2UgYWxsb3dlZCBtZW1iZXIgZ3JvdXANCnRvIHRoZSBjb3JlIG5ldHdvcmssIHNvIHRoYXQgYSBu b3QgYWxsb3dlZCBtb2JpbGUgdGVybWluYWwgY291bGQgYmUgYWxsb3dlZA0KYnkgdGhlIGNvcmUg bmV0d29yay4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkkgd2lzaCB0aGUgYWJvdmUg Y2xhcmlmaWNhdGlvbiBoZWxwcyB5b3UgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbS48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj48YnI+DQpSZWdhcmRpbmcgdG8gdGhlIHRlcm0gbm90YXJpemVkLCBz aW5jZSBJIGFtIGdyZWVuIHRvIHRoaXMgZ3JvdXAsIEkgYW0gbm90DQpzdXJlLCBkbyB5b3UgcHJl ZmVyIHRvIHJlcGxhY2UgdGhlIG5vdGFyaXplIHdpdGggc2lnbmF0dXJlPyBQbGVhc2UgbGV0DQpt ZSBrbm93LCB0aGFuayB5b3UhPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4g PGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpC UjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KWmFpZmVuZzwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPjxi cj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzxicj4NCjxi cj4NCjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lk dGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Zb2F2IE5pciAmbHQ7eW5p ckBjaGVja3BvaW50LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+MjAxMi0wMS0yMSAxNTozMDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEw MCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD04JT4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZCB3aWR0 aD05MSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90OyZsdDt6b25nLnphaWZl bmdAenRlLmNvbS5jbiZndDsNCiZsdDt6b25nLnphaWZlbmdAenRlLmNvbS5jbiZndDsmcXVvdDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3pvbmcuemFpZmVuZ0B6dGUuY29tLmNuJmd0 OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPiZxdW90O2lwc2VjQGlldGYub3JnJnF1b3Q7ICZsdDtpcHNlY0BpZXRmLm9yZyZndDs8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S ZTogW0lQc2VjXSBbSVBTZWNdOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24NCmZvciAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC16b25nLWlwc2VjbWUtaWtldjItY3BleHQ0ZmVtdG8t MDAudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPjxicj4N CkhpIFphaWZlbmc8YnI+DQo8YnI+DQpSZWFkaW5nIHlvdXIgZHJhZnQsIEknbSB0cnlpbmcgdG8g dW5kZXJzdGFuZCB0aGUgcHJvYmxlbSB5b3UgYXJlIHNvbHZpbmcuDQpJdCBpcyBhYm91dCB0aGUg RkFQIGJlaW5nIGNvbXByb21pc2VkIGFuZCBzZW5kaW5nIGZhbHNlIGluZm9ybWF0aW9uIHRocm91 Z2gNCnRoZSB0dW5uZWwuPGJyPg0KPGJyPg0KV2hhdCBpcyB0aGUgbWFsaWNpb3VzIEZBUCBseWlu ZyBhYm91dD88YnI+DQpIb3cgZG9lcyBzZW5kaW5nIHNvbWUgaW5mb3JtYXRpb24gKGRvZXMgJnF1 b3Q7bm90YXJpemVkJnF1b3Q7IG1lYW4gJnF1b3Q7c2lnbmVkJnF1b3Q7PykNCmZyb20gdGhlIFNl R1cgdG8gdGhlIChjb21wcm9taXNlZCkgRkFQIGhlbHA/PGJyPg0KPGJyPg0KT25lIGdlbmVyYWwg Y29tbWVudDogJnF1b3Q7bm90YXJpemVkJnF1b3Q7IGlzIGEgbGVnYWwgdGVybSwgc2ltaWxhciB0 bw0KJnF1b3Q7c2lnbmF0dXJlJnF1b3Q7LiBBbHRob3VnaCB0aGVyZSBpcyBzb21lIGFuYWxvZ3kg YmV0d2VlbiB0aGUgbGVnYWwNCmNvbmNlcHQgb2Ygc2lnbmF0dXJlIGFuZCB0aGUgZGlnaXRhbCBz aWduYXR1cmVzLCBzdWNoIGFuYWxvZ2llcyBvbmx5IGdvDQpzbyBmYXIuIFVzaW5nIHN1Y2ggYSBi b3Jyb3dlZCB0ZXJtIGhhcyBJTUhPIGxlZCB0byBtb3JlIGNvbmZ1c2lvbiB0aGFuDQpjbGFyaXR5 LiBJIHdvdWxkIHJhdGhlciBub3QgdXNlIGxlZ2FsIHRlcm1zIGluIHByb3RvY29scyAoYWx0aG91 Z2ggJnF1b3Q7cHJvdG9jb2wmcXVvdDsNCmlzIGFsc28gYSBib3Jyb3dlZCB0ZXJtKTxicj4NCjxi cj4NClRoYW5rcyw8YnI+DQo8YnI+DQpZb2F2PGJyPg0KPGJyPg0KT24gSmFuIDIwLCAyMDEyLCBh dCA4OjQwIEFNLCAmbHQ7em9uZy56YWlmZW5nQHp0ZS5jb20uY24mZ3Q7ICZsdDt6b25nLnphaWZl bmdAenRlLmNvbS5jbiZndDsNCndyb3RlOjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBG b2xrczogPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZXJlIGlzIGEgbmV3IGRyYWZ0IGF2YWlsYWJs ZSB0aGF0IHNvbWUgb2YgeW91IG1heSBiZSBpbnRlcmVzdGVkPGJyPg0KJmd0OyBpbiBsb29raW5n IGF0LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGRyYWZ0IGlzIGF2YWlsYWJsZSB2aWEgdGhl IGZvbGxvd2luZyBsaW5rOiA8YnI+DQomZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWQvZHJhZnQtem9uZy1pcHNlY21lLWlrZXYyLWNwZXh0NGZlbXRvLTAwLnR4 dCI+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXpvbmctaXBz ZWNtZS1pa2V2Mi1jcGV4dDRmZW10by0wMC50eHQ8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNp emU9Mj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRv IHRoZSBsaXN0LiBUaGFua3MhIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJSIDxi cj4NCiZndDsgWmFpZmVuZyA8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTMgZmFj ZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pjx0dD48Zm9udCBzaXplPTI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpJUHNlYyBtYWlsaW5nIGxp c3Q8YnI+DQpJUHNlY0BpZXRmLm9yZzxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNlYz48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWM8L2ZvbnQ+PC90dD48L2E+PHR0 Pjxmb250IHNpemU9Mj48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZu YnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7 aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5i c3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2Vu ZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5p Y2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25h bWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50 YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRl ZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5i c3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJz cDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJz cDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtp bnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3 aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZu YnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7 ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhw cmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3Nl Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNw O21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3Zp cnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0m bmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 007E10A38825798D_=-- From dharmanandana.pothulam@huawei.com Tue Jan 24 04:03:51 2012 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 636F721F8533 for ; Tue, 24 Jan 2012 04:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, 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 gsbC0YlSKTYg for ; Tue, 24 Jan 2012 04:03:50 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8817E21F852B for ; Tue, 24 Jan 2012 04:03:50 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYA00GOXXI65G@szxga03-in.huawei.com> for ipsec@ietf.org; Tue, 24 Jan 2012 20:03:42 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LYA004M5XI62V@szxga03-in.huawei.com> for ipsec@ietf.org; Tue, 24 Jan 2012 20:03:42 +0800 (CST) Received: from szxeml211-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGM80211; Tue, 24 Jan 2012 20:03:42 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml211-edg.china.huawei.com (172.24.2.182) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jan 2012 20:03:26 +0800 Received: from BLRNSHTIPL4NC (10.18.1.34) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server id 14.1.323.3; Tue, 24 Jan 2012 20:03:23 +0800 Date: Tue, 24 Jan 2012 17:34:15 +0530 From: Dharmanandana Reddy X-Originating-IP: [10.18.1.34] To: zong.zaifeng@zte.com.cn Message-id: Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4862 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_zDjEdNRmzmhOeWQwQ36+ZA)" Thread-index: AczakErnQ+mkDkGxRxutPAlNCwQ8uw== X-CFilter-Loop: Reflected Cc: ipsec@ietf.org Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dharmanandana.pothulam@huawei.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 12:03:51 -0000 --Boundary_(ID_zDjEdNRmzmhOeWQwQ36+ZA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Zaifeng, I have following questions and concerns about your proposed solution "The FAP will then send the FAP information together with the corresponding SeGW notarized signature to its mobile operator's core network. The core network verifies the FAP information by validating the SeGW notarized signature prior to the acceptance of the information". Is every ip packet carries SeGW notarized signature after server sends notarized signature to the client? if not, what's the point in returning notarized signature to the client? I believe yes, if so, It will increase percentage of overhead per packet and may impact quality of real time voice and video. if every ip packet carries SeGW notarized signature, How and where this signature carried inside ip packet? will it bring some modifications inside IPsec packet processing? Is this processing happens outside of IPsec? is it outside scope of this document? It would be great, if some of these aspects are addressed in the draft. Thanks, Dharmanandana Reddy Pothula. --Boundary_(ID_zDjEdNRmzmhOeWQwQ36+ZA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT 
Hi Zaifeng,
 
I have following questions and concerns about your proposed solution "The FAP will then send the FAP information together with the corresponding SeGW notarized signature to its mobile operator's core network. The core network verifies the FAP information by validating the SeGW notarized signature prior to the acceptance of the information".
 
Is every ip packet carries SeGW notarized signature after server sends notarized signature to the client? if not, what's the point in returning notarized signature to the client? I believe yes, if so, It will increase percentage of overhead per packet and may impact quality of real time voice and video. 
 
if every ip packet carries SeGW notarized signature, How and where this signature carried inside ip packet? will it bring some modifications inside IPsec packet processing? Is this processing happens outside of IPsec? is it outside scope of this document? It would be great, if some of these aspects are addressed in the draft.
 
Thanks,
 
Dharmanandana Reddy Pothula.
 
 

 

 

--Boundary_(ID_zDjEdNRmzmhOeWQwQ36+ZA)-- From tso@zteusa.com Tue Jan 24 23:58:54 2012 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 02EBE21F863F; Tue, 24 Jan 2012 23:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.513 X-Spam-Level: X-Spam-Status: No, score=0.513 tagged_above=-999 required=5 tests=[AWL=1.852, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76] 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 wmwaFSadSfwA; Tue, 24 Jan 2012 23:58:53 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E35AE21F863C; Tue, 24 Jan 2012 23:58:51 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690433787882; Wed, 25 Jan 2012 15:34:41 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 11923.1725263410; Wed, 25 Jan 2012 15:58:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q0P7waXn063240; Wed, 25 Jan 2012 15:58:36 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: To: dharmanandana.pothulam@huawei.com MIME-Version: 1.0 X-KeepSent: 530A809D:318F3CE4-88257990:0029FF25; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Tue, 24 Jan 2012 23:56:29 -0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-25 15:58:37, Serialize complete at 2012-01-25 15:58:37 Content-Type: multipart/alternative; boundary="=_alternative 002BD0CD88257990_=" X-MAIL: mse01.zte.com.cn q0P7waXn063240 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, zong.zaifeng@zte.com.cn, tso@zteusa.com Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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, 25 Jan 2012 07:58:54 -0000 This is a multipart message in MIME format. --=_alternative 002BD0CD88257990_= Content-Type: text/plain; charset="US-ASCII" Dear Dharmanandana, I hope that I address you correctly. If not, please pardon my ignorance. As this week is spring festival, ZaiFeng is not available. Hence, I would like to respond to you on behalf of her. Could you please kind see my responses to you inline below. Many thanks. Tricci Dharmanandana Reddy Sent by: ipsec-bounces@ietf.org 01/24/2012 04:04 AM Please respond to dharmanandana.pothulam@huawei.com To zong.zaifeng@zte.com.cn cc ipsec@ietf.org Subject Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt Hi Zaifeng, I have following questions and concerns about your proposed solution "The FAP will then send the FAP information together with the corresponding SeGW notarized signature to its mobile operator's core network. The core network verifies the FAP information by validating the SeGW notarized signature prior to the acceptance of the information". Is every ip packet carries SeGW notarized signature after server sends notarized signature to the client? if not, what's the point in returning notarized signature to the client? I believe yes, if so, It will increase percentage of overhead per packet and may impact quality of real time voice and video. Tricci > You ask a very legitimate question. May be our draft is not clear enough to explain the main motivation of this draft for target of the attack. Tricci > The main concern is not about the attack for "unauthorized FAP" to send any data to the mobile core network. The main concern is about the attack of the "unauthorized FAP" to send the "false" configuration information (e.g. such as changing the FAP from "Closed" to become "Open"), and to send the "false" access control related information (e.g. allowing a 3GPP UE which is supposed to be allowed to access the FAP and to have the access privileage to the FAP - i.e. CSG info alteration, etc.). Once the FAP's configuration and access control management are authenticated via the support of the notarization by the SeGW, then, the rest of the 3GPP UEs' access to the FAP can follow the existing access control and UE-based authentication/authorization procedures at the UE level's. Tricci > Of course, once the UE is authenticated and to allow access to the FAP, whatever the UE sends is beyond the control of the FAP just as what is happened today for any mobile device. Isn't it? if every ip packet carries SeGW notarized signature, How and where this signature carried inside ip packet? will it bring some modifications inside IPsec packet processing? Is this processing happens outside of IPsec? is it outside scope of this document? It would be great, if some of these aspects are addressed in the draft. Tricci > Since I have already explained to you that, we are not proposing to notarize every single packet sent by FAP. Hence, I don't think that I need to respond to your rest of the questions above. Tricci > THANK YOU for asking a good question. Cheers. Thanks, Dharmanandana Reddy Pothula. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 002BD0CD88257990_= Content-Type: text/html; charset="US-ASCII" Dear Dharmanandana,

I hope that I address you correctly.  If not, please pardon my ignorance.

As this week is spring festival, ZaiFeng is not available.  Hence, I would like to respond to you on behalf of her.  

Could you please kind see my responses to you inline below.  Many thanks.
Tricci




Dharmanandana Reddy <dharmanandana.pothulam@huawei.com>
Sent by: ipsec-bounces@ietf.org

01/24/2012 04:04 AM
Please respond to
dharmanandana.pothulam@huawei.com
To
zong.zaifeng@zte.com.cn
cc
ipsec@ietf.org
Subject
Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt





Hi Zaifeng,
 
I have following questions and concerns about your proposed solution "The FAP will then send the FAP information together with the corresponding SeGW notarized signature to its mobile operator's core network. The core network verifies the FAP information by validating the SeGW notarized signature prior to the acceptance of the information".
 
Is every ip packet carries SeGW notarized signature after server sends notarized signature to the client? if not, what's the point in returning notarized signature to the client? I believe yes, if so, It will increase percentage of overhead per packet and may impact quality of real time voice and video.

Tricci > You ask a very legitimate question.  May be our draft is not clear enough to explain the main motivation of this draft for target of the attack.  

Tricci > The main concern is not about the attack for "unauthorized FAP" to send any data to the mobile core network.  The main concern is about the attack of the "unauthorized FAP" to send the "false" configuration information (e.g. such as changing the FAP from "Closed" to become "Open"), and to send the "false" access control related information (e.g. allowing a 3GPP UE which is supposed to be allowed to access the FAP and to have the access privileage to the FAP - i.e. CSG info alteration, etc.).  Once the FAP's configuration and access control management are authenticated via the support of the notarization by the SeGW, then, the rest of the 3GPP UEs' access to the FAP can follow the existing access control and UE-based authentication/authorization procedures at the UE level's.  

Tricci > Of course, once the UE is authenticated and to allow access to the FAP, whatever the UE sends is beyond the control of the FAP just as what is happened today for any mobile device.  Isn't it?  
 
if every ip packet carries SeGW notarized signature, How and where this signature carried inside ip packet? will it bring some modifications inside IPsec packet processing? Is this processing happens outside of IPsec? is it outside scope of this document? It would be great, if some of these aspects are addressed in the draft.
 
Tricci > Since I have already explained to you that, we are not proposing to notarize every single packet sent by FAP.  Hence, I don't think that I need to respond to your rest of the questions above.  

Tricci > THANK YOU for asking a good question.  Cheers.

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

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 002BD0CD88257990_=-- From kent@bbn.com Thu Jan 26 10:50:39 2012 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 2BA4021F860F for ; Thu, 26 Jan 2012 10:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.433 X-Spam-Level: X-Spam-Status: No, score=-106.433 tagged_above=-999 required=5 tests=[AWL=0.166, 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 vGjL+aILfO3k for ; Thu, 26 Jan 2012 10:50:37 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id CE02221F8620 for ; Thu, 26 Jan 2012 10:50:37 -0800 (PST) Received: from dhcp89-089-066.bbn.com ([128.89.89.66]:49170) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RqUP4-000Gxy-Cn; Thu, 26 Jan 2012 13:50:34 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 26 Jan 2012 13:50:31 -0500 To: zong.zaifeng@zte.com.cn From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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, 26 Jan 2012 18:50:39 -0000 At 2:40 PM +0800 1/20/12, zong.zaifeng@zte.com.cn wrote: >Hi Folks: > >There is a new draft available that some of you may be interested >in looking at. > >The draft is available via the following link: >http://www.ietf.org/id/draft-zong-ipsecme-ikev2-cpext4femto-00.txt > >Please send your comments to the list. Thanks! > > >BR >Zaifeng Lookig very briefly at your doc, it seems that there might be a cleaner way to provide this capability, one that is more consistent with IETF standards. The term "notarization" seems a bit out of place here. The term "certifies" makes more sense, and suggests an alternative solution approach. Also, IKE is used to convey info between IPsec (note correct spelling) entities for use in key management and SA management,including access control. Having IKEv2 carry opaque info for use by an entity other than the IPsec implementation seems inappropriate. The doc suggests that the proposed new payload has minimal impact on IPsec/IKE. One must look not only at the bits on the wire, but also the IKEv2 communication paths at the endpoints. Carrying this data in IKEv2, for use by the "core network" also seems to require that IKEv2 pass the date on to external entities outside of the IPsec environment. That is a non-trivial change to what IKE does. In this case both the FAP and the SecGW are extracting signed data from IKE and passing it on to the core network, to authenticate the identify of the FAP and related FAP attributes. The SecGW is digitally signing an attestation about capabilities (including the identity) of the FAP. In PKI standards, this sort of info is usually expressed via an attribute cert. I doubt that many IKE implementations would know what to do with an attribute cert, but that's irrelevant here because IKE is not really consuming the signed data. The SecGW would seem to be acting as a CA or an AA. Why not have the SecGW issue a cert (or an attribute cert) to the FAP? Then have that cert be passed by the FAP to whatever really needs to consume it, along with signed data that establishes that the FAP is bound to the cert. That way the SecGW would not have to pass on data to the core network. One might also consider other, IETF standard mechanisms for passing around authentication and authorization data that is to be consumed by a 3rd party. Thsi sort of function is not what IKE is intended to perform. Steve From tso@zteusa.com Thu Jan 26 21:33:52 2012 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 C362711E8089; Thu, 26 Jan 2012 21:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76] 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 tXa9zz5Cdwor; Thu, 26 Jan 2012 21:33:49 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4E37011E8086; Thu, 26 Jan 2012 21:33:47 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 53829433787882; Fri, 27 Jan 2012 13:29:11 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 5467.464779275; Fri, 27 Jan 2012 13:33:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q0R5XQKR031572; Fri, 27 Jan 2012 13:33:26 +0800 (GMT-8) (envelope-from tso@zteusa.com) In-Reply-To: References: To: Stephen Kent MIME-Version: 1.0 X-KeepSent: C2C6920E:05135535-88257991:00830B10; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: tso@zteusa.com Date: Thu, 26 Jan 2012 21:31:14 -0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-27 13:33:27, Serialize complete at 2012-01-27 13:33:27 Content-Type: multipart/alternative; boundary="=_alternative 001E849388257992_=" X-MAIL: mse01.zte.com.cn q0R5XQKR031572 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, zong.zaifeng@zte.com.cn, tso@zteusa.com Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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, 27 Jan 2012 05:33:52 -0000 This is a multipart message in MIME format. --=_alternative 001E849388257992_= Content-Type: text/plain; charset="US-ASCII" Dear Stephen, Sincerely thanks for your expert advice on my colleague's (ZaiFeng's) proposal. Since she is still on Chinese Spring Festival holiday, please allow me to respond on behalf of her to get more valuable inputs from you. Please see my comments and questions inline below (sorry for the long email below). Thanks in advance. Tricci Stephen Kent Sent by: ipsec-bounces@ietf.org 01/26/2012 10:50 AM To zong.zaifeng@zte.com.cn cc ipsec@ietf.org Subject Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt At 2:40 PM +0800 1/20/12, zong.zaifeng@zte.com.cn wrote: >Hi Folks: > >There is a new draft available that some of you may be interested >in looking at. > >The draft is available via the following link: >http://www.ietf.org/id/draft-zong-ipsecme-ikev2-cpext4femto-00.txt > >Please send your comments to the list. Thanks! > > >BR >Zaifeng Lookig very briefly at your doc, it seems that there might be a cleaner way to provide this capability, one that is more consistent with IETF standards. Tricci > Fully agree with you that, we need to make a proposal to be consistent with IETF standards. In addition, I am also hoping you would agree that, as the solution is proposed to fix a generic issue for Femto network, we need to also consider the impact of the final solution towards the Femto's existing deployment as long as we did not break IKE. Would this be acceptable to you? The term "notarization" seems a bit out of place here. The term "certifies" makes more sense, and suggests an alternative solution approach. Also, IKE is used to convey info between IPsec (note correct spelling) entities for use in key management and SA management,including access control. Having IKEv2 carry opaque info for use by an entity other than the IPsec implementation seems inappropriate. Tricci > The reason that we choose the words "notarization" because the design of this proposal is to have a trusted-party (i.e. SeGW) of the target network (i.e. Mobile Core Network) to notarize the untrusted-party (i.e. FAP) so that the untrusted-party can leverage the trusted-party's notarized signature to be present to the target network to gain its trust and confident on the identity of the untrusted party as well as the info presented by the untrusted party to the target network. This approach is very similar to today notarization process in the legal process. Tricci > However, if you truly feel strongly against this word, we don't really have strong opinion on this one. We respect your expertise to suggest the better wording for us. Tricci > One important aspect that I would like to clarify is that, in our perspective, the info that is carried by the IKE is not really an opaque. In our perspective, the info is just not defined by IETF, but by the network/SDO which is responsible to utilize such solution to define the content of the info. If you think that it is necessary, we can add the note to the draft to specify that, whichever the network solution or SDO that chooses to use this solution must indicate what are the info which will be conveyed between the two IKE peers in advance. For example, if 3GPP decides to use this IKE feature as described in this draft to mitigate the FAP security issue, 3GPP should specify what and how the info is carried by the CP. The doc suggests that the proposed new payload has minimal impact on IPsec/IKE. One must look not only at the bits on the wire, but also the IKEv2 communication paths at the endpoints. Carrying this data in IKEv2, for use by the "core network" also seems to require that IKEv2 pass the date on to external entities outside of the IPsec environment. That is a non-trivial change to what IKE does. In this case both the FAP and the SecGW are extracting signed data from IKE and passing it on to the core network, to authenticate the identify of the FAP and related FAP attributes. Tricci > It is important to point out that, the SeGW does NOT pass on the CP info to the Mobile core network. What was described in the draft is that: Tricci > (1) FAP (i.e. IKE-initiator) includes the "Client Notarized Info" in the CP-Request during the mutual authentication exchange to SeGW (i.e. IKE-Responder) Tricci > (2) Once the SeGW authenticates the FAP (i.e. successful authentication), the SeGW will then notarize the info to derive "Server Notarized Signature" (algorithm is determined by network operator or standard SDO) which will then be included in the CP-Reply to the FAP. Tricci > (3) FAP will then include this Server Notarized Signature info in its own control signaling communication with the mobile core network which deploys the SeGW. The FAP's signaling contains the SeGW's Notarized Signature and they are encapsulated within the IPsec tunnel. Hence, SeGW is NOT involved in passing the CP's info to the Mobile Core Network. The SecGW is digitally signing an attestation about capabilities (including the identity) of the FAP. In PKI standards, this sort of info is usually expressed via an attribute cert. I doubt that many IKE implementations would know what to do with an attribute cert, but that's irrelevant here because IKE is not really consuming the signed data. The SecGW would seem to be acting as a CA or an AA. Why not have the SecGW issue a cert (or an attribute cert) to the FAP? Then have that cert be passed by the FAP to whatever really needs to consume it, along with signed data that establishes that the FAP is bound to the cert. That way the SecGW would not have to pass on data to the core network. Tricci > If I understand your proposal correctly, you suggested to have the SeGW to generate the additional cert to be used by the FAP to present to the target network, isn't it? Tricci > Unfortunately, this approach does not address the issue that we are trying to resolve. First of all, both FAP and SeGW already have their own certs to support their mutual authentication. Secondly, the new cert that you proposed will not contain the "specific" info that we require for the SeGW to certify/notarize for the FAP such that the FAP can present the certified/notarized info to the target mobile core network. Tricci > In summary, what we are trying to achieve is to have the SeGW, which is the trusted party of the Mobile Core network, to certify/notarize the "specific" configuration and access control info provided by the FAP to be notarized by the SeGW. This is how the Mobile Core network to verify the FAP's true identity and the associated info provided by the FAP is trust-worthy. Tricci > As for your last sentence above saying "That way the SecGW would not have to pass on data to the core network.". Again, please note that SeGW does NOT explicitly pass the CP info to the Mobile Core Network, it is the FAP to include the notarized signature in its signaling which is part of the IPsec payload to be sent to the Mobile Core network. One might also consider other, IETF standard mechanisms for passing around authentication and authorization data that is to be consumed by a 3rd party. Thsi sort of function is not what IKE is intended to perform. Tricci > I hope that you can understand that what you described above is NOT what we proposed. Thank you for your comments. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 001E849388257992_= Content-Type: text/html; charset="US-ASCII" Dear Stephen,

Sincerely thanks for your expert advice on my colleague's (ZaiFeng's) proposal.  Since she is still on Chinese Spring Festival holiday, please allow me to respond on behalf of her to get more valuable inputs from you.  

Please see my comments and questions inline below (sorry for the long email below).  Thanks in advance.  
Tricci



Stephen Kent <kent@bbn.com>
Sent by: ipsec-bounces@ietf.org

01/26/2012 10:50 AM

To
zong.zaifeng@zte.com.cn
cc
ipsec@ietf.org
Subject
Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt





At 2:40 PM +0800 1/20/12, zong.zaifeng@zte.com.cn wrote:
>Hi Folks:
>
>There is a new draft available that some of you may be interested
>in looking at.
>
>The draft is available via the following link:
>http://www.ietf.org/id/draft-zong-ipsecme-ikev2-cpext4femto-00.txt
>
>Please send your comments to the list. Thanks!
>
>
>BR
>Zaifeng

Lookig very briefly at your doc, it seems that there might be a cleaner way to
provide this capability, one that is more consistent with IETF standards.

Tricci > Fully agree with you that, we need to make a proposal to be consistent with IETF standards.  In addition, I am also hoping you would agree that, as the solution is proposed to fix a generic issue for Femto network, we need to also consider the impact of the final solution towards the Femto's existing deployment as long as we did not break IKE.  Would this be acceptable to you?  

The term "notarization" seems a bit out of place here. The term
"certifies" makes more sense, and suggests an alternative solution
approach. Also, IKE is used to convey info between IPsec (note
correct spelling) entities for use in key management and SA
management,including access control. Having IKEv2 carry opaque info
for use by an entity other than the IPsec implementation seems
inappropriate.

Tricci > The reason that we choose the words "notarization" because the design of this proposal is to have a trusted-party (i.e. SeGW) of the target network (i.e. Mobile Core Network) to notarize the untrusted-party (i.e. FAP) so that the untrusted-party can leverage the trusted-party's notarized signature to be present to the target network to gain its trust and confident on the identity of the untrusted party as well as the info presented by the untrusted party to the target network. This approach is very similar to today notarization process in the legal process.  

Tricci > However, if you truly feel strongly against this word, we don't really have strong opinion on this one.  We respect your expertise to suggest the better wording for us.
 
Tricci > One important aspect that I would like to clarify is that, in our perspective, the info that is carried by the IKE is not really an opaque.  In our perspective, the info is just not defined by IETF, but by the network/SDO which is responsible to utilize such solution to define the content of the info.   If you think that it is necessary, we can add the note to the draft to specify that, whichever the network solution or SDO that chooses to use this solution must indicate what are the info which will be conveyed between the two IKE peers in advance.  For example, if 3GPP decides to use this IKE feature as described in this draft to mitigate the FAP security issue,  3GPP should specify what and how the info is carried by the CP.      

The doc suggests that the proposed new payload has minimal impact on
IPsec/IKE. One must look not only at the bits on the wire, but also
the IKEv2 communication paths at the endpoints. Carrying this data in
IKEv2, for use  by the "core network" also seems to require that
IKEv2 pass the date on to external entities outside of the IPsec
environment. That is a non-trivial change to what IKE does. In this
case both the FAP and the SecGW are extracting signed data from IKE
and passing it on to the core network, to authenticate the identify
of the FAP and related FAP attributes.

Tricci > It is important to point out that, the SeGW does NOT pass on the CP info to the Mobile core network.  What was described in the draft is that:
Tricci > (1) FAP (i.e. IKE-initiator) includes the "Client Notarized Info" in the CP-Request during the mutual authentication exchange to SeGW (i.e. IKE-Responder)
Tricci > (2) Once the SeGW authenticates the FAP (i.e. successful authentication), the SeGW will then notarize the info to derive "Server Notarized Signature" (algorithm is determined by network operator or standard SDO) which will then be included in the CP-Reply to the FAP.  
Tricci > (3) FAP will then include this Server Notarized Signature info in its own control signaling communication with the mobile core network which deploys the SeGW.  The FAP's signaling contains the SeGW's Notarized Signature and they are encapsulated within the IPsec tunnel.  Hence, SeGW is NOT involved in passing the CP's info to the Mobile Core Network.

The SecGW is digitally signing an attestation about capabilities
(including the identity) of the FAP.  In PKI standards, this sort of
info is usually expressed via an attribute cert. I doubt that many
IKE implementations would know what to do with an attribute cert, but
that's irrelevant here because IKE is not really consuming the signed
data. The SecGW would seem to be acting as a CA or an AA.  Why not
have the SecGW issue a cert (or an attribute cert) to the FAP? Then
have that cert be passed by the FAP to whatever really needs to
consume it, along with signed data that establishes that the FAP is
bound to the cert. That way the SecGW would not have to pass on data
to the core network.

Tricci > If I understand your proposal correctly, you suggested to have the SeGW to generate the additional cert to be used by the FAP to present to the target network, isn't it?  
Tricci > Unfortunately, this approach does not address the issue that we are trying to resolve.  First of all, both FAP and SeGW already have their own certs to support their mutual authentication.  Secondly, the new cert that you proposed will not contain the "specific" info that we require for the SeGW to certify/notarize for the FAP such that the FAP can present the certified/notarized info to the target mobile core network.

Tricci > In summary, what we are trying to achieve is to have the SeGW, which is the trusted party of the Mobile Core network, to certify/notarize the "specific" configuration and access control info provided by the FAP to be notarized by the SeGW.  This is how the Mobile Core network to verify the FAP's true identity and the associated info provided by the FAP is trust-worthy.  

Tricci > As for your last sentence above saying "That way the SecGW would not have to pass on data to the core network.".  Again, please note that SeGW does NOT explicitly pass the CP info to the Mobile Core Network, it is the FAP to include the notarized signature in its signaling which is part of the IPsec payload to be sent to the Mobile Core network.

One might also consider other, IETF standard mechanisms for passing
around authentication and authorization data that is to be consumed
by a 3rd party. Thsi sort of function is not what IKE is intended to
perform.

Tricci > I hope that you can understand that what you described above is NOT what we proposed.  Thank you for your comments.

Steve

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

 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 001E849388257992_=-- From paul.hoffman@vpnc.org Fri Jan 27 08:48:33 2012 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 C4D8921F8618 for ; Fri, 27 Jan 2012 08:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 KCsnB-CSsOK9 for ; Fri, 27 Jan 2012 08:48:33 -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 5906621F85D4 for ; Fri, 27 Jan 2012 08:48:33 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0RGmV7Z050631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 27 Jan 2012 09:48:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Jan 2012 08:48:30 -0800 Message-Id: <8CAC2292-8A17-4B38-B2DC-D8A4FDB43CEB@vpnc.org> To: IPsecme WG Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [IPsec] NUDGE: Starting work on our new charter items 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, 27 Jan 2012 16:48:33 -0000 [[ There has not been enough response yet, by far. ]] We have a new charter. Do we have any volunteers to start work on the = two documents we committed to work on? Related: we should consider having a face-to-face meeting at the = upcoming IETF in Paris, but only if there is value for the = newly-chartered work. In my mind, that means both a first draft = submitted *and* interesting questions that would benefit from = face-to-face discussion instead of just work on the list. Do people = believe we will have that? --Paul Hoffman From zong.zaifeng@zte.com.cn Sun Jan 29 00:43:09 2012 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 C8FDE21F8491; Sun, 29 Jan 2012 00:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.221 X-Spam-Level: X-Spam-Status: No, score=-95.221 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 HKYhevwZIsdF; Sun, 29 Jan 2012 00:43:08 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6AE21F848B; Sun, 29 Jan 2012 00:43:07 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690433787882; Sun, 29 Jan 2012 16:18:13 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 5467.464779275; Sun, 29 Jan 2012 16:42:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q0T8gmWs027531; Sun, 29 Jan 2012 16:42:48 +0800 (GMT-8) (envelope-from zong.zaifeng@zte.com.cn) In-Reply-To: To: tso@zteusa.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zong.zaifeng@zte.com.cn Date: Sun, 29 Jan 2012 16:39:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-29 16:42:51, Serialize complete at 2012-01-29 16:42:51 Content-Type: multipart/alternative; boundary="=_alternative 002FCC2348257994_=" X-MAIL: mse02.zte.com.cn q0T8gmWs027531 Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, Stephen Kent , tso@zteusa.com Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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, 29 Jan 2012 08:43:10 -0000 This is a multipart message in MIME format. --=_alternative 002FCC2348257994_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU3RlcGhlbiwgVHJpY2NpOg0KDQpTb3JyeSB0aGF0IEkgZGlkbid0IHJlc3BvbmQgdGhpcyBl bWFpbCBvbiB0aW1lIGR1ZSB0byB0aGUgY2hpbmVzZSBzcHJpbmcgDQpmZXN0aXZhbC4gSSB3b3Vs ZCBsaWtlIHRvIHRoYW5rIFN0ZXBoZW4gZmlyc3QgZm9yIHJldmlld2luZyB0aGUgZHJhZnQgYW5k IA0KZ2l2aW5nIG1lIHlvdXIgc3VnZ2VzdGlvbnMuDQoNCkZyb20gcmVhZGluZyBTdGVwaGVuJ3Mg ZW1haWwsIGlmIG15IHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgeW91IGFzc3VtZWQgDQp0aGF0 IFNlR1cgd2lsbCBwYXNzIHNvbWUgaW5mb3JtYXRpb24gdG8gdGhlIGNvcmUgbmV0d29yayBpbiBv cmRlciB0aGF0IHRoZSANCmNvcmUgbmV0d29yayBjYW4gdmVyaWZ5IHRoZSAibm90YXJpemVkIiBG QVAgaW5mb3JtYXRpb24/IEFuZCB5b3UgdGhpbmsgDQp0aGF0IHRoZSBpbmZvcm1hdGlvbiBleGNo YW5nZSBiZXR3ZW4gU2VHVyBhbmQgdGhlIGNvcmUgbmV0d29yayBpcyBhIGJpZyANCmNoYW5nZSB0 byBJS0UsIGlzIHRoaXMgY29ycmVjdCB1bmRlcnN0YW5kaW5nIG9mIHlvdXIgZW1haWw/DQoNCklm IG15IHVuZGVyc3RhbmRpbmcgb2YgeW91ciBlbWFpbCBpcyBjb3JyZWN0LCB0aGVuIHBsZWFzZSBs ZXQgbWUgY2xhcmlmeSBhIA0KbGl0dGxlIGJpdCBtb3JlIHRvIG1ha2UgdGhlIGRyYWZ0IG1vcmUg Y2xlYXIuIEluIG91ciBkcmFmdCwgd2UgaGF2ZSBub3QgDQpleHBlY3RlZCB0byBoYXZlIGluZm9y bWF0aW9uIGV4Y2hhbmdlIGJldHdlZW4gU2VHVyBhbmQgY29yZSBuZXR3b3JrLCBpbiANCm91ciBv cmlnaW5hbCBkZXNpZ24sIHdlIGFzc3VtZWQgdGhhdCB0aGUgY29yZSBuZXR3b3JrIHdpbGwgYmUg Y29uZmlndXJlZCANCndpdGggaW5mb3JtYXRpb24gdGhhdCBpcyBuZWVkZWQgdG8gdmVyaWZ5IHRo ZSBjZXJ0aWZpY2F0ZSBzaWduZWQgYnkgdGhlIA0KU2VHVywgaS5lLiB0aGUgY29yZSBuZXR3b3Jr IGlzIGNvbmZpZ3VyZWQgd2l0aCB0aGUgYWxnb3JpdGhtIGFuZCBrZXkgdG8gYmUgDQp1c2VkIHRv IHZlcmlmeSB0aGUgc2lnbmF0dXJlIHNlbnQgZnJvbSB0aGUgRkFQIHRvIHRoZSBjb3JlIG5ldHdv cmsuDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHRoaXMgY29uZmlndXJhdGlvbiBiYXNlZCBhc3N1bXB0 aW9uIG1heSBoYXZlIHNvbWUgDQpsaW1pdHMsIEkgdGhpbmsgdGhhdCB0byBnZW5lcmF0ZSBhIGNl cnQgYnkgdGhlIFNlR1cgYW5kIHNlbmQgaXQgdG8gdGhlIEZBUCANCmFuZCB0aGVuIGZyb20gdGhl IEZBUCB0byB0aGUgY29yZSBuZXR3b3JrIGlzIGEgZ29vZCBpbXBsZW1lbnRhdGlvbiBvcHRpb24u IA0KUGVyaGFwcyBJIHNob3VsZCBtYWtlIHRoZSBDUCBmbGV4aWJsZSBlbm91Z2ggdG8gYWRhcHQg dG8gYWxsIHRoZSANCmltcGxlbWVudGF0aW9uIG9wdGlvbnMuIElmIHlvdSBoYXZlIGFueSBnb29k IGlkZWEgb24gaG93IHRoZSBDUCBzaG91bGQgYmUgDQpkZXNpZ25lZCwgY291bGQgeW91IGtpbmRs eSBnaXZlIG1lIHlvdXIgc3VnZ2VzdGlvbj8NCg0KVGhhbmtzIQ0KDQpCUg0KWmFpZmVuZw0KDQoN Cg0KIA0KDQoNCg0KVHJpY2NpU28wNTI3ODUvdXNlci96dGVfbHRkDQoyMDEyLTAxLTI3IDEzOjMx DQoNCsrVvP7Iyw0KU3RlcGhlbiBLZW50IDxrZW50QGJibi5jb20+DQqzrcvNDQppcHNlY0BpZXRm Lm9yZywgaXBzZWMtYm91bmNlc0BpZXRmLm9yZywgDQpab25nWmFpRmVuZzAwODI0Ni91c2VyL3p0 ZV9sdGRAenRlX2x0ZCwgdHNvQHp0ZXVzYS5jb20NCtb3zOINClJlOiBbSVBzZWNdIFtJUFNlY106 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQpkcmFmdC16b25nLWlwc2VjbWUtaWtldjIt Y3BleHQ0ZmVtdG8tMDAudHh0DQoNCg0KDQoNCg0KRGVhciBTdGVwaGVuLCANCg0KU2luY2VyZWx5 IHRoYW5rcyBmb3IgeW91ciBleHBlcnQgYWR2aWNlIG9uIG15IGNvbGxlYWd1ZSdzIChaYWlGZW5n J3MpIA0KcHJvcG9zYWwuICBTaW5jZSBzaGUgaXMgc3RpbGwgb24gQ2hpbmVzZSBTcHJpbmcgRmVz dGl2YWwgaG9saWRheSwgcGxlYXNlIA0KYWxsb3cgbWUgdG8gcmVzcG9uZCBvbiBiZWhhbGYgb2Yg aGVyIHRvIGdldCBtb3JlIHZhbHVhYmxlIGlucHV0cyBmcm9tIHlvdS4gDQogDQoNClBsZWFzZSBz ZWUgbXkgY29tbWVudHMgYW5kIHF1ZXN0aW9ucyBpbmxpbmUgYmVsb3cgKHNvcnJ5IGZvciB0aGUg bG9uZyANCmVtYWlsIGJlbG93KS4gIFRoYW5rcyBpbiBhZHZhbmNlLiANClRyaWNjaSANCg0KDQoN Cg0KU3RlcGhlbiBLZW50IDxrZW50QGJibi5jb20+IA0KU2VudCBieTogaXBzZWMtYm91bmNlc0Bp ZXRmLm9yZw0KMDEvMjYvMjAxMiAxMDo1MCBBTQ0KDQpUbw0Kem9uZy56YWlmZW5nQHp0ZS5jb20u Y24NCmNjDQppcHNlY0BpZXRmLm9yZw0KU3ViamVjdA0KUmU6IFtJUHNlY10gW0lQU2VjXTogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciANCmRyYWZ0LXpvbmctaXBzZWNtZS1pa2V2Mi1jcGV4 dDRmZW10by0wMC50eHQNCg0KDQoNCg0KDQoNCkF0IDI6NDAgUE0gKzA4MDAgMS8yMC8xMiwgem9u Zy56YWlmZW5nQHp0ZS5jb20uY24gd3JvdGU6DQo+SGkgRm9sa3M6DQo+DQo+VGhlcmUgaXMgYSBu ZXcgZHJhZnQgYXZhaWxhYmxlIHRoYXQgc29tZSBvZiB5b3UgbWF5IGJlIGludGVyZXN0ZWQNCj5p biBsb29raW5nIGF0Lg0KPg0KPlRoZSBkcmFmdCBpcyBhdmFpbGFibGUgdmlhIHRoZSBmb2xsb3dp bmcgbGluazoNCj5odHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXpvbmctaXBzZWNtZS1pa2V2 Mi1jcGV4dDRmZW10by0wMC50eHQNCj4NCj5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRo ZSBsaXN0LiBUaGFua3MhDQo+DQo+DQo+QlINCj5aYWlmZW5nDQoNCkxvb2tpZyB2ZXJ5IGJyaWVm bHkgYXQgeW91ciBkb2MsIGl0IHNlZW1zIHRoYXQgdGhlcmUgbWlnaHQgYmUgYSBjbGVhbmVyIA0K d2F5IHRvDQpwcm92aWRlIHRoaXMgY2FwYWJpbGl0eSwgb25lIHRoYXQgaXMgbW9yZSBjb25zaXN0 ZW50IHdpdGggSUVURiBzdGFuZGFyZHMuDQoNClRyaWNjaSA+IEZ1bGx5IGFncmVlIHdpdGggeW91 IHRoYXQsIHdlIG5lZWQgdG8gbWFrZSBhIHByb3Bvc2FsIHRvIGJlIA0KY29uc2lzdGVudCB3aXRo IElFVEYgc3RhbmRhcmRzLiAgSW4gYWRkaXRpb24sIEkgYW0gYWxzbyBob3BpbmcgeW91IHdvdWxk IA0KYWdyZWUgdGhhdCwgYXMgdGhlIHNvbHV0aW9uIGlzIHByb3Bvc2VkIHRvIGZpeCBhIGdlbmVy aWMgaXNzdWUgZm9yIEZlbXRvIA0KbmV0d29yaywgd2UgbmVlZCB0byBhbHNvIGNvbnNpZGVyIHRo ZSBpbXBhY3Qgb2YgdGhlIGZpbmFsIHNvbHV0aW9uIHRvd2FyZHMgDQp0aGUgRmVtdG8ncyBleGlz dGluZyBkZXBsb3ltZW50IGFzIGxvbmcgYXMgd2UgZGlkIG5vdCBicmVhayBJS0UuICBXb3VsZCAN CnRoaXMgYmUgYWNjZXB0YWJsZSB0byB5b3U/ICANCg0KVGhlIHRlcm0gIm5vdGFyaXphdGlvbiIg c2VlbXMgYSBiaXQgb3V0IG9mIHBsYWNlIGhlcmUuIFRoZSB0ZXJtIA0KImNlcnRpZmllcyIgbWFr ZXMgbW9yZSBzZW5zZSwgYW5kIHN1Z2dlc3RzIGFuIGFsdGVybmF0aXZlIHNvbHV0aW9uIA0KYXBw cm9hY2guIEFsc28sIElLRSBpcyB1c2VkIHRvIGNvbnZleSBpbmZvIGJldHdlZW4gSVBzZWMgKG5v dGUgDQpjb3JyZWN0IHNwZWxsaW5nKSBlbnRpdGllcyBmb3IgdXNlIGluIGtleSBtYW5hZ2VtZW50 IGFuZCBTQSANCm1hbmFnZW1lbnQsaW5jbHVkaW5nIGFjY2VzcyBjb250cm9sLiBIYXZpbmcgSUtF djIgY2Fycnkgb3BhcXVlIGluZm8gDQpmb3IgdXNlIGJ5IGFuIGVudGl0eSBvdGhlciB0aGFuIHRo ZSBJUHNlYyBpbXBsZW1lbnRhdGlvbiBzZWVtcyANCmluYXBwcm9wcmlhdGUuDQoNClRyaWNjaSA+ IFRoZSByZWFzb24gdGhhdCB3ZSBjaG9vc2UgdGhlIHdvcmRzICJub3Rhcml6YXRpb24iIGJlY2F1 c2UgdGhlIA0KZGVzaWduIG9mIHRoaXMgcHJvcG9zYWwgaXMgdG8gaGF2ZSBhIHRydXN0ZWQtcGFy dHkgKGkuZS4gU2VHVykgb2YgdGhlIA0KdGFyZ2V0IG5ldHdvcmsgKGkuZS4gTW9iaWxlIENvcmUg TmV0d29yaykgdG8gbm90YXJpemUgdGhlIHVudHJ1c3RlZC1wYXJ0eSANCihpLmUuIEZBUCkgc28g dGhhdCB0aGUgdW50cnVzdGVkLXBhcnR5IGNhbiBsZXZlcmFnZSB0aGUgdHJ1c3RlZC1wYXJ0eSdz IA0Kbm90YXJpemVkIHNpZ25hdHVyZSB0byBiZSBwcmVzZW50IHRvIHRoZSB0YXJnZXQgbmV0d29y ayB0byBnYWluIGl0cyB0cnVzdCANCmFuZCBjb25maWRlbnQgb24gdGhlIGlkZW50aXR5IG9mIHRo ZSB1bnRydXN0ZWQgcGFydHkgYXMgd2VsbCBhcyB0aGUgaW5mbyANCnByZXNlbnRlZCBieSB0aGUg dW50cnVzdGVkIHBhcnR5IHRvIHRoZSB0YXJnZXQgbmV0d29yay4gVGhpcyBhcHByb2FjaCBpcyAN CnZlcnkgc2ltaWxhciB0byB0b2RheSBub3Rhcml6YXRpb24gcHJvY2VzcyBpbiB0aGUgbGVnYWwg cHJvY2Vzcy4gDQoNClRyaWNjaSA+IEhvd2V2ZXIsIGlmIHlvdSB0cnVseSBmZWVsIHN0cm9uZ2x5 IGFnYWluc3QgdGhpcyB3b3JkLCB3ZSBkb24ndCANCnJlYWxseSBoYXZlIHN0cm9uZyBvcGluaW9u IG9uIHRoaXMgb25lLiAgV2UgcmVzcGVjdCB5b3VyIGV4cGVydGlzZSB0byANCnN1Z2dlc3QgdGhl IGJldHRlciB3b3JkaW5nIGZvciB1cy4gDQogDQpUcmljY2kgPiBPbmUgaW1wb3J0YW50IGFzcGVj dCB0aGF0IEkgd291bGQgbGlrZSB0byBjbGFyaWZ5IGlzIHRoYXQsIGluIG91ciANCnBlcnNwZWN0 aXZlLCB0aGUgaW5mbyB0aGF0IGlzIGNhcnJpZWQgYnkgdGhlIElLRSBpcyBub3QgcmVhbGx5IGFu IG9wYXF1ZS4gDQpJbiBvdXIgcGVyc3BlY3RpdmUsIHRoZSBpbmZvIGlzIGp1c3Qgbm90IGRlZmlu ZWQgYnkgSUVURiwgYnV0IGJ5IHRoZSANCm5ldHdvcmsvU0RPIHdoaWNoIGlzIHJlc3BvbnNpYmxl IHRvIHV0aWxpemUgc3VjaCBzb2x1dGlvbiB0byBkZWZpbmUgdGhlIA0KY29udGVudCBvZiB0aGUg aW5mby4gICBJZiB5b3UgdGhpbmsgdGhhdCBpdCBpcyBuZWNlc3NhcnksIHdlIGNhbiBhZGQgdGhl IA0Kbm90ZSB0byB0aGUgZHJhZnQgdG8gc3BlY2lmeSB0aGF0LCB3aGljaGV2ZXIgdGhlIG5ldHdv cmsgc29sdXRpb24gb3IgU0RPIA0KdGhhdCBjaG9vc2VzIHRvIHVzZSB0aGlzIHNvbHV0aW9uIG11 c3QgaW5kaWNhdGUgd2hhdCBhcmUgdGhlIGluZm8gd2hpY2ggDQp3aWxsIGJlIGNvbnZleWVkIGJl dHdlZW4gdGhlIHR3byBJS0UgcGVlcnMgaW4gYWR2YW5jZS4gIEZvciBleGFtcGxlLCBpZiANCjNH UFAgZGVjaWRlcyB0byB1c2UgdGhpcyBJS0UgZmVhdHVyZSBhcyBkZXNjcmliZWQgaW4gdGhpcyBk cmFmdCB0byANCm1pdGlnYXRlIHRoZSBGQVAgc2VjdXJpdHkgaXNzdWUsICAzR1BQIHNob3VsZCBz cGVjaWZ5IHdoYXQgYW5kIGhvdyB0aGUgDQppbmZvIGlzIGNhcnJpZWQgYnkgdGhlIENQLiAgICAg IA0KDQpUaGUgZG9jIHN1Z2dlc3RzIHRoYXQgdGhlIHByb3Bvc2VkIG5ldyBwYXlsb2FkIGhhcyBt aW5pbWFsIGltcGFjdCBvbiANCklQc2VjL0lLRS4gT25lIG11c3QgbG9vayBub3Qgb25seSBhdCB0 aGUgYml0cyBvbiB0aGUgd2lyZSwgYnV0IGFsc28gDQp0aGUgSUtFdjIgY29tbXVuaWNhdGlvbiBw YXRocyBhdCB0aGUgZW5kcG9pbnRzLiBDYXJyeWluZyB0aGlzIGRhdGEgaW4gDQpJS0V2MiwgZm9y IHVzZSAgYnkgdGhlICJjb3JlIG5ldHdvcmsiIGFsc28gc2VlbXMgdG8gcmVxdWlyZSB0aGF0IA0K SUtFdjIgcGFzcyB0aGUgZGF0ZSBvbiB0byBleHRlcm5hbCBlbnRpdGllcyBvdXRzaWRlIG9mIHRo ZSBJUHNlYyANCmVudmlyb25tZW50LiBUaGF0IGlzIGEgbm9uLXRyaXZpYWwgY2hhbmdlIHRvIHdo YXQgSUtFIGRvZXMuIEluIHRoaXMgDQpjYXNlIGJvdGggdGhlIEZBUCBhbmQgdGhlIFNlY0dXIGFy ZSBleHRyYWN0aW5nIHNpZ25lZCBkYXRhIGZyb20gSUtFIA0KYW5kIHBhc3NpbmcgaXQgb24gdG8g dGhlIGNvcmUgbmV0d29yaywgdG8gYXV0aGVudGljYXRlIHRoZSBpZGVudGlmeSANCm9mIHRoZSBG QVAgYW5kIHJlbGF0ZWQgRkFQIGF0dHJpYnV0ZXMuDQoNClRyaWNjaSA+IEl0IGlzIGltcG9ydGFu dCB0byBwb2ludCBvdXQgdGhhdCwgdGhlIFNlR1cgZG9lcyBOT1QgcGFzcyBvbiB0aGUgDQpDUCBp bmZvIHRvIHRoZSBNb2JpbGUgY29yZSBuZXR3b3JrLiAgV2hhdCB3YXMgZGVzY3JpYmVkIGluIHRo ZSBkcmFmdCBpcyANCnRoYXQ6DQpUcmljY2kgPiAoMSkgRkFQIChpLmUuIElLRS1pbml0aWF0b3Ip IGluY2x1ZGVzIHRoZSAiQ2xpZW50IE5vdGFyaXplZCBJbmZvIiANCmluIHRoZSBDUC1SZXF1ZXN0 IGR1cmluZyB0aGUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIGV4Y2hhbmdlIHRvIFNlR1cgKGkuZS4g DQpJS0UtUmVzcG9uZGVyKQ0KVHJpY2NpID4gKDIpIE9uY2UgdGhlIFNlR1cgYXV0aGVudGljYXRl cyB0aGUgRkFQIChpLmUuIHN1Y2Nlc3NmdWwgDQphdXRoZW50aWNhdGlvbiksIHRoZSBTZUdXIHdp bGwgdGhlbiBub3Rhcml6ZSB0aGUgaW5mbyB0byBkZXJpdmUgIlNlcnZlciANCk5vdGFyaXplZCBT aWduYXR1cmUiIChhbGdvcml0aG0gaXMgZGV0ZXJtaW5lZCBieSBuZXR3b3JrIG9wZXJhdG9yIG9y IA0Kc3RhbmRhcmQgU0RPKSB3aGljaCB3aWxsIHRoZW4gYmUgaW5jbHVkZWQgaW4gdGhlIENQLVJl cGx5IHRvIHRoZSBGQVAuIA0KVHJpY2NpID4gKDMpIEZBUCB3aWxsIHRoZW4gaW5jbHVkZSB0aGlz IFNlcnZlciBOb3Rhcml6ZWQgU2lnbmF0dXJlIGluZm8gaW4gDQppdHMgb3duIGNvbnRyb2wgc2ln bmFsaW5nIGNvbW11bmljYXRpb24gd2l0aCB0aGUgbW9iaWxlIGNvcmUgbmV0d29yayB3aGljaCAN CmRlcGxveXMgdGhlIFNlR1cuICBUaGUgRkFQJ3Mgc2lnbmFsaW5nIGNvbnRhaW5zIHRoZSBTZUdX J3MgTm90YXJpemVkIA0KU2lnbmF0dXJlIGFuZCB0aGV5IGFyZSBlbmNhcHN1bGF0ZWQgd2l0aGlu IHRoZSBJUHNlYyB0dW5uZWwuICBIZW5jZSwgU2VHVyANCmlzIE5PVCBpbnZvbHZlZCBpbiBwYXNz aW5nIHRoZSBDUCdzIGluZm8gdG8gdGhlIE1vYmlsZSBDb3JlIE5ldHdvcmsuIA0KDQpUaGUgU2Vj R1cgaXMgZGlnaXRhbGx5IHNpZ25pbmcgYW4gYXR0ZXN0YXRpb24gYWJvdXQgY2FwYWJpbGl0aWVz IA0KKGluY2x1ZGluZyB0aGUgaWRlbnRpdHkpIG9mIHRoZSBGQVAuICBJbiBQS0kgc3RhbmRhcmRz LCB0aGlzIHNvcnQgb2YgDQppbmZvIGlzIHVzdWFsbHkgZXhwcmVzc2VkIHZpYSBhbiBhdHRyaWJ1 dGUgY2VydC4gSSBkb3VidCB0aGF0IG1hbnkgDQpJS0UgaW1wbGVtZW50YXRpb25zIHdvdWxkIGtu b3cgd2hhdCB0byBkbyB3aXRoIGFuIGF0dHJpYnV0ZSBjZXJ0LCBidXQgDQp0aGF0J3MgaXJyZWxl dmFudCBoZXJlIGJlY2F1c2UgSUtFIGlzIG5vdCByZWFsbHkgY29uc3VtaW5nIHRoZSBzaWduZWQg DQpkYXRhLiBUaGUgU2VjR1cgd291bGQgc2VlbSB0byBiZSBhY3RpbmcgYXMgYSBDQSBvciBhbiBB QS4gIFdoeSBub3QgDQpoYXZlIHRoZSBTZWNHVyBpc3N1ZSBhIGNlcnQgKG9yIGFuIGF0dHJpYnV0 ZSBjZXJ0KSB0byB0aGUgRkFQPyBUaGVuIA0KaGF2ZSB0aGF0IGNlcnQgYmUgcGFzc2VkIGJ5IHRo ZSBGQVAgdG8gd2hhdGV2ZXIgcmVhbGx5IG5lZWRzIHRvIA0KY29uc3VtZSBpdCwgYWxvbmcgd2l0 aCBzaWduZWQgZGF0YSB0aGF0IGVzdGFibGlzaGVzIHRoYXQgdGhlIEZBUCBpcyANCmJvdW5kIHRv IHRoZSBjZXJ0LiBUaGF0IHdheSB0aGUgU2VjR1cgd291bGQgbm90IGhhdmUgdG8gcGFzcyBvbiBk YXRhIA0KdG8gdGhlIGNvcmUgbmV0d29yay4NCg0KVHJpY2NpID4gSWYgSSB1bmRlcnN0YW5kIHlv dXIgcHJvcG9zYWwgY29ycmVjdGx5LCB5b3Ugc3VnZ2VzdGVkIHRvIGhhdmUgDQp0aGUgU2VHVyB0 byBnZW5lcmF0ZSB0aGUgYWRkaXRpb25hbCBjZXJ0IHRvIGJlIHVzZWQgYnkgdGhlIEZBUCB0byBw cmVzZW50IA0KdG8gdGhlIHRhcmdldCBuZXR3b3JrLCBpc24ndCBpdD8gDQpUcmljY2kgPiBVbmZv cnR1bmF0ZWx5LCB0aGlzIGFwcHJvYWNoIGRvZXMgbm90IGFkZHJlc3MgdGhlIGlzc3VlIHRoYXQg d2UgDQphcmUgdHJ5aW5nIHRvIHJlc29sdmUuICBGaXJzdCBvZiBhbGwsIGJvdGggRkFQIGFuZCBT ZUdXIGFscmVhZHkgaGF2ZSB0aGVpciANCm93biBjZXJ0cyB0byBzdXBwb3J0IHRoZWlyIG11dHVh bCBhdXRoZW50aWNhdGlvbi4gIFNlY29uZGx5LCB0aGUgbmV3IGNlcnQgDQp0aGF0IHlvdSBwcm9w b3NlZCB3aWxsIG5vdCBjb250YWluIHRoZSAic3BlY2lmaWMiIGluZm8gdGhhdCB3ZSByZXF1aXJl IGZvciANCnRoZSBTZUdXIHRvIGNlcnRpZnkvbm90YXJpemUgZm9yIHRoZSBGQVAgc3VjaCB0aGF0 IHRoZSBGQVAgY2FuIHByZXNlbnQgdGhlIA0KY2VydGlmaWVkL25vdGFyaXplZCBpbmZvIHRvIHRo ZSB0YXJnZXQgbW9iaWxlIGNvcmUgbmV0d29yay4gDQoNClRyaWNjaSA+IEluIHN1bW1hcnksIHdo YXQgd2UgYXJlIHRyeWluZyB0byBhY2hpZXZlIGlzIHRvIGhhdmUgdGhlIFNlR1csIA0Kd2hpY2gg aXMgdGhlIHRydXN0ZWQgcGFydHkgb2YgdGhlIE1vYmlsZSBDb3JlIG5ldHdvcmssIHRvIGNlcnRp Znkvbm90YXJpemUgDQp0aGUgInNwZWNpZmljIiBjb25maWd1cmF0aW9uIGFuZCBhY2Nlc3MgY29u dHJvbCBpbmZvIHByb3ZpZGVkIGJ5IHRoZSBGQVAgDQp0byBiZSBub3Rhcml6ZWQgYnkgdGhlIFNl R1cuICBUaGlzIGlzIGhvdyB0aGUgTW9iaWxlIENvcmUgbmV0d29yayB0byANCnZlcmlmeSB0aGUg RkFQJ3MgdHJ1ZSBpZGVudGl0eSBhbmQgdGhlIGFzc29jaWF0ZWQgaW5mbyBwcm92aWRlZCBieSB0 aGUgRkFQIA0KaXMgdHJ1c3Qtd29ydGh5LiANCg0KVHJpY2NpID4gQXMgZm9yIHlvdXIgbGFzdCBz ZW50ZW5jZSBhYm92ZSBzYXlpbmcgIlRoYXQgd2F5IHRoZSBTZWNHVyB3b3VsZCANCm5vdCBoYXZl IHRvIHBhc3Mgb24gZGF0YSB0byB0aGUgY29yZSBuZXR3b3JrLiIuICBBZ2FpbiwgcGxlYXNlIG5v dGUgdGhhdCANClNlR1cgZG9lcyBOT1QgZXhwbGljaXRseSBwYXNzIHRoZSBDUCBpbmZvIHRvIHRo ZSBNb2JpbGUgQ29yZSBOZXR3b3JrLCBpdCANCmlzIHRoZSBGQVAgdG8gaW5jbHVkZSB0aGUgbm90 YXJpemVkIHNpZ25hdHVyZSBpbiBpdHMgc2lnbmFsaW5nIHdoaWNoIGlzIA0KcGFydCBvZiB0aGUg SVBzZWMgcGF5bG9hZCB0byBiZSBzZW50IHRvIHRoZSBNb2JpbGUgQ29yZSBuZXR3b3JrLiANCiAN Ck9uZSBtaWdodCBhbHNvIGNvbnNpZGVyIG90aGVyLCBJRVRGIHN0YW5kYXJkIG1lY2hhbmlzbXMg Zm9yIHBhc3NpbmcgDQphcm91bmQgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gZGF0 YSB0aGF0IGlzIHRvIGJlIGNvbnN1bWVkIA0KYnkgYSAzcmQgcGFydHkuIFRoc2kgc29ydCBvZiBm dW5jdGlvbiBpcyBub3Qgd2hhdCBJS0UgaXMgaW50ZW5kZWQgdG8gDQpwZXJmb3JtLg0KDQpUcmlj Y2kgPiBJIGhvcGUgdGhhdCB5b3UgY2FuIHVuZGVyc3RhbmQgdGhhdCB3aGF0IHlvdSBkZXNjcmli ZWQgYWJvdmUgaXMgDQpOT1Qgd2hhdCB3ZSBwcm9wb3NlZC4gIFRoYW5rIHlvdSBmb3IgeW91ciBj b21tZW50cy4NCg0KU3RldmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCklQc2VjIG1haWxpbmcgbGlzdA0KSVBzZWNAaWV0Zi5vcmcNCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCg0KDQoNCg0K --=_alternative 002FCC2348257994_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFN0ZXBoZW4sIFRyaWNjaTo8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlNvcnJ5IHRo YXQgSSBkaWRuJ3QgcmVzcG9uZCB0aGlzIGVtYWlsDQpvbiB0aW1lIGR1ZSB0byB0aGUgY2hpbmVz ZSBzcHJpbmcgZmVzdGl2YWwuIEkgd291bGQgbGlrZSB0byB0aGFuayBTdGVwaGVuDQpmaXJzdCBm b3IgcmV2aWV3aW5nIHRoZSBkcmFmdCBhbmQgZ2l2aW5nIG1lIHlvdXIgc3VnZ2VzdGlvbnMuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Gcm9tIHJlYWRp bmcgU3RlcGhlbidzIGVtYWlsLCBpZiBteQ0KdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCB5b3Ug YXNzdW1lZCB0aGF0IFNlR1cgd2lsbCBwYXNzIHNvbWUgaW5mb3JtYXRpb24NCnRvIHRoZSBjb3Jl IG5ldHdvcmsgaW4gb3JkZXIgdGhhdCB0aGUgY29yZSBuZXR3b3JrIGNhbiB2ZXJpZnkgdGhlICZx dW90O25vdGFyaXplZCZxdW90Ow0KRkFQIGluZm9ybWF0aW9uPyBBbmQgeW91IHRoaW5rIHRoYXQg dGhlIGluZm9ybWF0aW9uIGV4Y2hhbmdlIGJldHdlbiBTZUdXDQphbmQgdGhlIGNvcmUgbmV0d29y ayBpcyBhIGJpZyBjaGFuZ2UgdG8gSUtFLCBpcyB0aGlzIGNvcnJlY3QgdW5kZXJzdGFuZGluZw0K b2YgeW91ciBlbWFpbD88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPklmIG15IHVuZGVyc3RhbmRpbmcgb2YgeW91ciBlbWFpbCBpcw0KY29ycmVjdCwgdGhl biBwbGVhc2UgbGV0IG1lIGNsYXJpZnkgYSBsaXR0bGUgYml0IG1vcmUgdG8gbWFrZSB0aGUgZHJh ZnQNCm1vcmUgY2xlYXIuIEluIG91ciBkcmFmdCwgd2UgaGF2ZSBub3QgZXhwZWN0ZWQgdG8gaGF2 ZSBpbmZvcm1hdGlvbiBleGNoYW5nZQ0KYmV0d2VlbiBTZUdXIGFuZCBjb3JlIG5ldHdvcmssIGlu IG91ciBvcmlnaW5hbCBkZXNpZ24sIHdlIGFzc3VtZWQgdGhhdA0KdGhlIGNvcmUgbmV0d29yayB3 aWxsIGJlIGNvbmZpZ3VyZWQgd2l0aCBpbmZvcm1hdGlvbiB0aGF0IGlzIG5lZWRlZCB0bw0KdmVy aWZ5IHRoZSBjZXJ0aWZpY2F0ZSBzaWduZWQgYnkgdGhlIFNlR1csIGkuZS4gdGhlIGNvcmUgbmV0 d29yayBpcyBjb25maWd1cmVkDQp3aXRoIHRoZSBhbGdvcml0aG0gYW5kIGtleSB0byBiZSB1c2Vk IHRvIHZlcmlmeSB0aGUgc2lnbmF0dXJlIHNlbnQgZnJvbQ0KdGhlIEZBUCB0byB0aGUgY29yZSBu ZXR3b3JrLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ SSB1bmRlcnN0YW5kIHRoYXQgdGhpcyBjb25maWd1cmF0aW9uDQpiYXNlZCBhc3N1bXB0aW9uIG1h eSBoYXZlIHNvbWUgbGltaXRzLCBJIHRoaW5rIHRoYXQgdG8gZ2VuZXJhdGUgYSBjZXJ0DQpieSB0 aGUgU2VHVyBhbmQgc2VuZCBpdCB0byB0aGUgRkFQIGFuZCB0aGVuIGZyb20gdGhlIEZBUCB0byB0 aGUgY29yZSBuZXR3b3JrDQppcyBhIGdvb2QgaW1wbGVtZW50YXRpb24gb3B0aW9uLiBQZXJoYXBz IEkgc2hvdWxkIG1ha2UgdGhlIENQIGZsZXhpYmxlDQplbm91Z2ggdG8gYWRhcHQgdG8gYWxsIHRo ZSBpbXBsZW1lbnRhdGlvbiBvcHRpb25zLiBJZiB5b3UgaGF2ZSBhbnkgZ29vZA0KaWRlYSBvbiBo b3cgdGhlIENQIHNob3VsZCBiZSBkZXNpZ25lZCwgY291bGQgeW91IGtpbmRseSBnaXZlIG1lIHlv dXIgc3VnZ2VzdGlvbj88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPlRoYW5rcyE8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkJSPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5aYWlm ZW5nPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+ DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk IHdpZHRoPTQwJT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+VHJpY2NpU28wNTI3 ODUvdXNlci96dGVfbHRkPC9iPjwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4yMDEyLTAxLTI3IDEzOjMxPC9mb250Pg0KPHRkIHdpZHRoPTU5JT4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlN0ZXBoZW4gS2VudCAmbHQ7a2VudEBiYm4uY29tJmd0Ozwv Zm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+aXBzZWNAaWV0Zi5vcmcsIGlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcs DQpab25nWmFpRmVuZzAwODI0Ni91c2VyL3p0ZV9sdGRAenRlX2x0ZCwgdHNvQHp0ZXVzYS5jb208 L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbSVBzZWNdIFtJUFNlY106IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbg0KZm9yIGRyYWZ0LXpvbmctaXBzZWNtZS1pa2V2Mi1jcGV4dDRmZW10by0wMC50eHQ8 L2ZvbnQ+PGEgaHJlZj1Ob3RlczovLy80ODI1NzVGQjAwMEM0MTkyL0Y2NDJGMkQxNTJGQjQ1QjI0 ODI1NkM1MjAwNDQ3OEQ1LzI3QjdFNkQzRDg1MzUyQUE0ODI1Nzk5MTAwNjc4NERCPkxpbms8L2E+ PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFi bGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNl PSJNViBCb2xpIj5EZWFyIFN0ZXBoZW4sIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJNViBCb2xpIj5TaW5jZXJlbHkgdGhhbmtzIGZvciB5b3VyIGV4cGVy dA0KYWR2aWNlIG9uIG15IGNvbGxlYWd1ZSdzIChaYWlGZW5nJ3MpIHByb3Bvc2FsLiAmbmJzcDtT aW5jZSBzaGUgaXMgc3RpbGwNCm9uIENoaW5lc2UgU3ByaW5nIEZlc3RpdmFsIGhvbGlkYXksIHBs ZWFzZSBhbGxvdyBtZSB0byByZXNwb25kIG9uIGJlaGFsZg0Kb2YgaGVyIHRvIGdldCBtb3JlIHZh bHVhYmxlIGlucHV0cyBmcm9tIHlvdS4gJm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MyBjb2xvcj1ibHVlIGZhY2U9Ik1WIEJvbGkiPlBsZWFzZSBzZWUgbXkgY29tbWVudHMgYW5k IHF1ZXN0aW9ucw0KaW5saW5lIGJlbG93IChzb3JyeSBmb3IgdGhlIGxvbmcgZW1haWwgYmVsb3cp LiAmbmJzcDtUaGFua3MgaW4gYWR2YW5jZS4NCiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZSBmYWNlPSJNViBCb2xpIj5UcmljY2kgPC9mb250Pg0KPGJyPg0KPGJyPg0K PGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0 aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlN0ZXBoZW4gS2VudCAmbHQ7 a2VudEBiYm4uY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+U2VudCBieTogaXBzZWMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4wMS8yNi8yMDEyIDEwOjUwIEFNPC9mb250Pg0KPHRk IHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5UbzwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+em9uZy56YWlmZW5nQHp0 ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmNjPC9mb250PjwvZGl2Pg0KPHRkPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5pcHNlY0BpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+U3ViamVjdDwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+UmU6IFtJUHNlY10gW0lQU2VjXTogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uDQpmb3Ig ZHJhZnQtem9uZy1pcHNlY21lLWlrZXYyLWNwZXh0NGZlbXRvLTAwLnR4dDwvZm9udD48L3RhYmxl Pg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxi cj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTM+QXQgMjo0MCBQTSAr MDgwMCAxLzIwLzEyLCB6b25nLnphaWZlbmdAenRlLmNvbS5jbg0Kd3JvdGU6PGJyPg0KJmd0O0hp IEZvbGtzOjxicj4NCiZndDs8YnI+DQomZ3Q7VGhlcmUgaXMgYSBuZXcgZHJhZnQgYXZhaWxhYmxl IHRoYXQgc29tZSBvZiB5b3UgbWF5IGJlIGludGVyZXN0ZWQ8YnI+DQomZ3Q7aW4gbG9va2luZyBh dC48YnI+DQomZ3Q7PGJyPg0KJmd0O1RoZSBkcmFmdCBpcyBhdmFpbGFibGUgdmlhIHRoZSBmb2xs b3dpbmcgbGluazo8YnI+DQomZ3Q7aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC16b25nLWlw c2VjbWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0PGJyPg0KJmd0Ozxicj4NCiZndDtQbGVhc2Ug c2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LiBUaGFua3MhPGJyPg0KJmd0Ozxicj4NCiZn dDs8YnI+DQomZ3Q7QlI8YnI+DQomZ3Q7WmFpZmVuZzxicj4NCjxicj4NCkxvb2tpZyB2ZXJ5IGJy aWVmbHkgYXQgeW91ciBkb2MsIGl0IHNlZW1zIHRoYXQgdGhlcmUgbWlnaHQgYmUgYSBjbGVhbmVy DQp3YXkgdG88YnI+DQpwcm92aWRlIHRoaXMgY2FwYWJpbGl0eSwgb25lIHRoYXQgaXMgbW9yZSBj b25zaXN0ZW50IHdpdGggSUVURiBzdGFuZGFyZHMuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iTVYgQm9saSI+VHJpY2NpICZndDsgRnVsbHkgYWdy ZWUgd2l0aA0KeW91IHRoYXQsIHdlIG5lZWQgdG8gbWFrZSBhIHByb3Bvc2FsIHRvIGJlIGNvbnNp c3RlbnQgd2l0aCBJRVRGIHN0YW5kYXJkcy4NCiZuYnNwO0luIGFkZGl0aW9uLCBJIGFtIGFsc28g aG9waW5nIHlvdSB3b3VsZCBhZ3JlZSB0aGF0LCBhcyB0aGUgc29sdXRpb24NCmlzIHByb3Bvc2Vk IHRvIGZpeCBhIGdlbmVyaWMgaXNzdWUgZm9yIEZlbXRvIG5ldHdvcmssIHdlIG5lZWQgdG8gYWxz byBjb25zaWRlcg0KdGhlIGltcGFjdCBvZiB0aGUgZmluYWwgc29sdXRpb24gdG93YXJkcyB0aGUg RmVtdG8ncyBleGlzdGluZyBkZXBsb3ltZW50DQphcyBsb25nIGFzIHdlIGRpZCBub3QgYnJlYWsg SUtFLiAmbmJzcDtXb3VsZCB0aGlzIGJlIGFjY2VwdGFibGUgdG8geW91Pw0KJm5ic3A7PC9mb250 Pjx0dD48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0KVGhlIHRlcm0gJnF1b3Q7bm90YXJpemF0aW9u JnF1b3Q7IHNlZW1zIGEgYml0IG91dCBvZiBwbGFjZSBoZXJlLiBUaGUgdGVybQ0KPGJyPg0KJnF1 b3Q7Y2VydGlmaWVzJnF1b3Q7IG1ha2VzIG1vcmUgc2Vuc2UsIGFuZCBzdWdnZXN0cyBhbiBhbHRl cm5hdGl2ZSBzb2x1dGlvbg0KPGJyPg0KYXBwcm9hY2guIEFsc28sIElLRSBpcyB1c2VkIHRvIGNv bnZleSBpbmZvIGJldHdlZW4gSVBzZWMgKG5vdGUgPGJyPg0KY29ycmVjdCBzcGVsbGluZykgZW50 aXRpZXMgZm9yIHVzZSBpbiBrZXkgbWFuYWdlbWVudCBhbmQgU0EgPGJyPg0KbWFuYWdlbWVudCxp bmNsdWRpbmcgYWNjZXNzIGNvbnRyb2wuIEhhdmluZyBJS0V2MiBjYXJyeSBvcGFxdWUgaW5mbyA8 YnI+DQpmb3IgdXNlIGJ5IGFuIGVudGl0eSBvdGhlciB0aGFuIHRoZSBJUHNlYyBpbXBsZW1lbnRh dGlvbiBzZWVtcyA8YnI+DQppbmFwcHJvcHJpYXRlLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9Ik1WIEJvbGkiPlRyaWNjaSAmZ3Q7IFRoZSByZWFz b24gdGhhdA0Kd2UgY2hvb3NlIHRoZSB3b3JkcyAmcXVvdDtub3Rhcml6YXRpb24mcXVvdDsgYmVj YXVzZSB0aGUgZGVzaWduIG9mIHRoaXMNCnByb3Bvc2FsIGlzIHRvIGhhdmUgYSB0cnVzdGVkLXBh cnR5IChpLmUuIFNlR1cpIG9mIHRoZSB0YXJnZXQgbmV0d29yayAoaS5lLg0KTW9iaWxlIENvcmUg TmV0d29yaykgdG8gbm90YXJpemUgdGhlIHVudHJ1c3RlZC1wYXJ0eSAoaS5lLiBGQVApIHNvIHRo YXQNCnRoZSB1bnRydXN0ZWQtcGFydHkgY2FuIGxldmVyYWdlIHRoZSB0cnVzdGVkLXBhcnR5J3Mg bm90YXJpemVkIHNpZ25hdHVyZQ0KdG8gYmUgcHJlc2VudCB0byB0aGUgdGFyZ2V0IG5ldHdvcmsg dG8gZ2FpbiBpdHMgdHJ1c3QgYW5kIGNvbmZpZGVudCBvbg0KdGhlIGlkZW50aXR5IG9mIHRoZSB1 bnRydXN0ZWQgcGFydHkgYXMgd2VsbCBhcyB0aGUgaW5mbyBwcmVzZW50ZWQgYnkgdGhlDQp1bnRy dXN0ZWQgcGFydHkgdG8gdGhlIHRhcmdldCBuZXR3b3JrLiBUaGlzIGFwcHJvYWNoIGlzIHZlcnkg c2ltaWxhciB0bw0KdG9kYXkgbm90YXJpemF0aW9uIHByb2Nlc3MgaW4gdGhlIGxlZ2FsIHByb2Nl c3MuICZuYnNwOyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFj ZT0iTVYgQm9saSI+VHJpY2NpICZndDsgSG93ZXZlciwgaWYgeW91DQp0cnVseSBmZWVsIHN0cm9u Z2x5IGFnYWluc3QgdGhpcyB3b3JkLCB3ZSBkb24ndCByZWFsbHkgaGF2ZSBzdHJvbmcgb3Bpbmlv bg0Kb24gdGhpcyBvbmUuICZuYnNwO1dlIHJlc3BlY3QgeW91ciBleHBlcnRpc2UgdG8gc3VnZ2Vz dCB0aGUgYmV0dGVyIHdvcmRpbmcNCmZvciB1cy4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBj b2xvcj1ibHVlIGZhY2U9Ik1WIEJvbGkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJNViBCb2xpIj5UcmljY2kgJmd0OyBPbmUgaW1wb3J0YW50IGFzcGVj dA0KdGhhdCBJIHdvdWxkIGxpa2UgdG8gY2xhcmlmeSBpcyB0aGF0LCBpbiBvdXIgcGVyc3BlY3Rp dmUsIHRoZSBpbmZvIHRoYXQNCmlzIGNhcnJpZWQgYnkgdGhlIElLRSBpcyBub3QgcmVhbGx5IGFu IG9wYXF1ZS4gJm5ic3A7SW4gb3VyIHBlcnNwZWN0aXZlLA0KdGhlIGluZm8gaXMganVzdCBub3Qg ZGVmaW5lZCBieSBJRVRGLCBidXQgYnkgdGhlIG5ldHdvcmsvU0RPIHdoaWNoIGlzIHJlc3BvbnNp YmxlDQp0byB1dGlsaXplIHN1Y2ggc29sdXRpb24gdG8gZGVmaW5lIHRoZSBjb250ZW50IG9mIHRo ZSBpbmZvLiAmbmJzcDsgSWYgeW91DQp0aGluayB0aGF0IGl0IGlzIG5lY2Vzc2FyeSwgd2UgY2Fu IGFkZCB0aGUgbm90ZSB0byB0aGUgZHJhZnQgdG8gc3BlY2lmeQ0KdGhhdCwgd2hpY2hldmVyIHRo ZSBuZXR3b3JrIHNvbHV0aW9uIG9yIFNETyB0aGF0IGNob29zZXMgdG8gdXNlIHRoaXMgc29sdXRp b24NCm11c3QgaW5kaWNhdGUgd2hhdCBhcmUgdGhlIGluZm8gd2hpY2ggd2lsbCBiZSBjb252ZXll ZCBiZXR3ZWVuIHRoZSB0d28NCklLRSBwZWVycyBpbiBhZHZhbmNlLiAmbmJzcDtGb3IgZXhhbXBs ZSwgaWYgM0dQUCBkZWNpZGVzIHRvIHVzZSB0aGlzIElLRQ0KZmVhdHVyZSBhcyBkZXNjcmliZWQg aW4gdGhpcyBkcmFmdCB0byBtaXRpZ2F0ZSB0aGUgRkFQIHNlY3VyaXR5IGlzc3VlLA0KJm5ic3A7 M0dQUCBzaG91bGQgc3BlY2lmeSB3aGF0IGFuZCBob3cgdGhlIGluZm8gaXMgY2FycmllZCBieSB0 aGUgQ1AuICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48dHQ+PGZvbnQgc2l6ZT0zPjxicj4N Cjxicj4NClRoZSBkb2Mgc3VnZ2VzdHMgdGhhdCB0aGUgcHJvcG9zZWQgbmV3IHBheWxvYWQgaGFz IG1pbmltYWwgaW1wYWN0IG9uIDxicj4NCklQc2VjL0lLRS4gT25lIG11c3QgbG9vayBub3Qgb25s eSBhdCB0aGUgYml0cyBvbiB0aGUgd2lyZSwgYnV0IGFsc28gPGJyPg0KdGhlIElLRXYyIGNvbW11 bmljYXRpb24gcGF0aHMgYXQgdGhlIGVuZHBvaW50cy4gQ2FycnlpbmcgdGhpcyBkYXRhIGluIDxi cj4NCklLRXYyLCBmb3IgdXNlICZuYnNwO2J5IHRoZSAmcXVvdDtjb3JlIG5ldHdvcmsmcXVvdDsg YWxzbyBzZWVtcyB0byByZXF1aXJlDQp0aGF0IDxicj4NCklLRXYyIHBhc3MgdGhlIGRhdGUgb24g dG8gZXh0ZXJuYWwgZW50aXRpZXMgb3V0c2lkZSBvZiB0aGUgSVBzZWMgPGJyPg0KZW52aXJvbm1l bnQuIFRoYXQgaXMgYSBub24tdHJpdmlhbCBjaGFuZ2UgdG8gd2hhdCBJS0UgZG9lcy4gSW4gdGhp cyA8YnI+DQpjYXNlIGJvdGggdGhlIEZBUCBhbmQgdGhlIFNlY0dXIGFyZSBleHRyYWN0aW5nIHNp Z25lZCBkYXRhIGZyb20gSUtFIDxicj4NCmFuZCBwYXNzaW5nIGl0IG9uIHRvIHRoZSBjb3JlIG5l dHdvcmssIHRvIGF1dGhlbnRpY2F0ZSB0aGUgaWRlbnRpZnkgPGJyPg0Kb2YgdGhlIEZBUCBhbmQg cmVsYXRlZCBGQVAgYXR0cmlidXRlcy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZSBmYWNlPSJNViBCb2xpIj5UcmljY2kgJmd0OyBJdCBpcyBpbXBvcnRhbnQN CnRvIHBvaW50IG91dCB0aGF0LCB0aGUgU2VHVyBkb2VzIE5PVCBwYXNzIG9uIHRoZSBDUCBpbmZv IHRvIHRoZSBNb2JpbGUNCmNvcmUgbmV0d29yay4gJm5ic3A7V2hhdCB3YXMgZGVzY3JpYmVkIGlu IHRoZSBkcmFmdCBpcyB0aGF0OjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBm YWNlPSJNViBCb2xpIj5UcmljY2kgJmd0OyAoMSkgRkFQIChpLmUuIElLRS1pbml0aWF0b3IpDQpp bmNsdWRlcyB0aGUgJnF1b3Q7Q2xpZW50IE5vdGFyaXplZCBJbmZvJnF1b3Q7IGluIHRoZSBDUC1S ZXF1ZXN0IGR1cmluZw0KdGhlIG11dHVhbCBhdXRoZW50aWNhdGlvbiBleGNoYW5nZSB0byBTZUdX IChpLmUuIElLRS1SZXNwb25kZXIpPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVl IGZhY2U9Ik1WIEJvbGkiPlRyaWNjaSAmZ3Q7ICgyKSBPbmNlIHRoZSBTZUdXDQphdXRoZW50aWNh dGVzIHRoZSBGQVAgKGkuZS4gc3VjY2Vzc2Z1bCBhdXRoZW50aWNhdGlvbiksIHRoZSBTZUdXIHdp bGwgdGhlbg0Kbm90YXJpemUgdGhlIGluZm8gdG8gZGVyaXZlICZxdW90O1NlcnZlciBOb3Rhcml6 ZWQgU2lnbmF0dXJlJnF1b3Q7IChhbGdvcml0aG0NCmlzIGRldGVybWluZWQgYnkgbmV0d29yayBv cGVyYXRvciBvciBzdGFuZGFyZCBTRE8pIHdoaWNoIHdpbGwgdGhlbiBiZSBpbmNsdWRlZA0KaW4g dGhlIENQLVJlcGx5IHRvIHRoZSBGQVAuICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMg Y29sb3I9Ymx1ZSBmYWNlPSJNViBCb2xpIj5UcmljY2kgJmd0OyAoMykgRkFQIHdpbGwgdGhlbg0K aW5jbHVkZSB0aGlzIFNlcnZlciBOb3Rhcml6ZWQgU2lnbmF0dXJlIGluZm8gaW4gaXRzIG93biBj b250cm9sIHNpZ25hbGluZw0KY29tbXVuaWNhdGlvbiB3aXRoIHRoZSBtb2JpbGUgY29yZSBuZXR3 b3JrIHdoaWNoIGRlcGxveXMgdGhlIFNlR1cuICZuYnNwO1RoZQ0KRkFQJ3Mgc2lnbmFsaW5nIGNv bnRhaW5zIHRoZSBTZUdXJ3MgTm90YXJpemVkIFNpZ25hdHVyZSBhbmQgdGhleSBhcmUgZW5jYXBz dWxhdGVkDQp3aXRoaW4gdGhlIElQc2VjIHR1bm5lbC4gJm5ic3A7SGVuY2UsIFNlR1cgaXMgTk9U IGludm9sdmVkIGluIHBhc3NpbmcgdGhlDQpDUCdzIGluZm8gdG8gdGhlIE1vYmlsZSBDb3JlIE5l dHdvcmsuIDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NClRoZSBTZWNHVyBpcyBk aWdpdGFsbHkgc2lnbmluZyBhbiBhdHRlc3RhdGlvbiBhYm91dCBjYXBhYmlsaXRpZXMgPGJyPg0K KGluY2x1ZGluZyB0aGUgaWRlbnRpdHkpIG9mIHRoZSBGQVAuICZuYnNwO0luIFBLSSBzdGFuZGFy ZHMsIHRoaXMgc29ydA0Kb2YgPGJyPg0KaW5mbyBpcyB1c3VhbGx5IGV4cHJlc3NlZCB2aWEgYW4g YXR0cmlidXRlIGNlcnQuIEkgZG91YnQgdGhhdCBtYW55IDxicj4NCklLRSBpbXBsZW1lbnRhdGlv bnMgd291bGQga25vdyB3aGF0IHRvIGRvIHdpdGggYW4gYXR0cmlidXRlIGNlcnQsIGJ1dCA8YnI+ DQp0aGF0J3MgaXJyZWxldmFudCBoZXJlIGJlY2F1c2UgSUtFIGlzIG5vdCByZWFsbHkgY29uc3Vt aW5nIHRoZSBzaWduZWQgPGJyPg0KZGF0YS4gVGhlIFNlY0dXIHdvdWxkIHNlZW0gdG8gYmUgYWN0 aW5nIGFzIGEgQ0Egb3IgYW4gQUEuICZuYnNwO1doeSBub3QNCjxicj4NCmhhdmUgdGhlIFNlY0dX IGlzc3VlIGEgY2VydCAob3IgYW4gYXR0cmlidXRlIGNlcnQpIHRvIHRoZSBGQVA/IFRoZW4gPGJy Pg0KaGF2ZSB0aGF0IGNlcnQgYmUgcGFzc2VkIGJ5IHRoZSBGQVAgdG8gd2hhdGV2ZXIgcmVhbGx5 IG5lZWRzIHRvIDxicj4NCmNvbnN1bWUgaXQsIGFsb25nIHdpdGggc2lnbmVkIGRhdGEgdGhhdCBl c3RhYmxpc2hlcyB0aGF0IHRoZSBGQVAgaXMgPGJyPg0KYm91bmQgdG8gdGhlIGNlcnQuIFRoYXQg d2F5IHRoZSBTZWNHVyB3b3VsZCBub3QgaGF2ZSB0byBwYXNzIG9uIGRhdGEgPGJyPg0KdG8gdGhl IGNvcmUgbmV0d29yay48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJNViBCb2xpIj5UcmljY2kgJmd0OyBJZiBJIHVuZGVyc3RhbmQNCnlvdXIgcHJv cG9zYWwgY29ycmVjdGx5LCB5b3Ugc3VnZ2VzdGVkIHRvIGhhdmUgdGhlIFNlR1cgdG8gZ2VuZXJh dGUgdGhlDQphZGRpdGlvbmFsIGNlcnQgdG8gYmUgdXNlZCBieSB0aGUgRkFQIHRvIHByZXNlbnQg dG8gdGhlIHRhcmdldCBuZXR3b3JrLA0KaXNuJ3QgaXQ/ICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iTVYgQm9saSI+VHJpY2NpICZndDsgVW5mb3J0dW5h dGVseSwgdGhpcw0KYXBwcm9hY2ggZG9lcyBub3QgYWRkcmVzcyB0aGUgaXNzdWUgdGhhdCB3ZSBh cmUgdHJ5aW5nIHRvIHJlc29sdmUuICZuYnNwO0ZpcnN0DQpvZiBhbGwsIGJvdGggRkFQIGFuZCBT ZUdXIGFscmVhZHkgaGF2ZSB0aGVpciBvd24gY2VydHMgdG8gc3VwcG9ydCB0aGVpcg0KbXV0dWFs IGF1dGhlbnRpY2F0aW9uLiAmbmJzcDtTZWNvbmRseSwgdGhlIG5ldyBjZXJ0IHRoYXQgeW91IHBy b3Bvc2VkIHdpbGwNCm5vdCBjb250YWluIHRoZSAmcXVvdDtzcGVjaWZpYyZxdW90OyBpbmZvIHRo YXQgd2UgcmVxdWlyZSBmb3IgdGhlIFNlR1cNCnRvIGNlcnRpZnkvbm90YXJpemUgZm9yIHRoZSBG QVAgc3VjaCB0aGF0IHRoZSBGQVAgY2FuIHByZXNlbnQgdGhlIGNlcnRpZmllZC9ub3Rhcml6ZWQN CmluZm8gdG8gdGhlIHRhcmdldCBtb2JpbGUgY29yZSBuZXR3b3JrLiA8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iTVYgQm9saSI+VHJpY2NpICZndDsgSW4g c3VtbWFyeSwgd2hhdA0Kd2UgYXJlIHRyeWluZyB0byBhY2hpZXZlIGlzIHRvIGhhdmUgdGhlIFNl R1csIHdoaWNoIGlzIHRoZSB0cnVzdGVkIHBhcnR5DQpvZiB0aGUgTW9iaWxlIENvcmUgbmV0d29y aywgdG8gY2VydGlmeS9ub3Rhcml6ZSB0aGUgJnF1b3Q7c3BlY2lmaWMmcXVvdDsNCmNvbmZpZ3Vy YXRpb24gYW5kIGFjY2VzcyBjb250cm9sIGluZm8gcHJvdmlkZWQgYnkgdGhlIEZBUCB0byBiZSBu b3Rhcml6ZWQNCmJ5IHRoZSBTZUdXLiAmbmJzcDtUaGlzIGlzIGhvdyB0aGUgTW9iaWxlIENvcmUg bmV0d29yayB0byB2ZXJpZnkgdGhlIEZBUCdzDQp0cnVlIGlkZW50aXR5IGFuZCB0aGUgYXNzb2Np YXRlZCBpbmZvIHByb3ZpZGVkIGJ5IHRoZSBGQVAgaXMgdHJ1c3Qtd29ydGh5Lg0KJm5ic3A7PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9Ik1WIEJvbGkiPlRy aWNjaSAmZ3Q7IEFzIGZvciB5b3VyIGxhc3QNCnNlbnRlbmNlIGFib3ZlIHNheWluZyAmcXVvdDs8 L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mz5UaGF0IHdheSB0aGUgU2VjR1cNCndvdWxkIG5vdCBoYXZl IHRvIHBhc3Mgb24gZGF0YSB0byB0aGUgY29yZSBuZXR3b3JrLjwvZm9udD48L3R0Pjxmb250IHNp emU9MyBjb2xvcj1ibHVlIGZhY2U9Ik1WIEJvbGkiPiZxdW90Oy4NCiZuYnNwO0FnYWluLCBwbGVh c2Ugbm90ZSB0aGF0IFNlR1cgZG9lcyBOT1QgZXhwbGljaXRseSBwYXNzIHRoZSBDUCBpbmZvDQp0 byB0aGUgTW9iaWxlIENvcmUgTmV0d29yaywgaXQgaXMgdGhlIEZBUCB0byBpbmNsdWRlIHRoZSBu b3Rhcml6ZWQgc2lnbmF0dXJlDQppbiBpdHMgc2lnbmFsaW5nIHdoaWNoIGlzIHBhcnQgb2YgdGhl IElQc2VjIHBheWxvYWQgdG8gYmUgc2VudCB0byB0aGUgTW9iaWxlDQpDb3JlIG5ldHdvcmsuIDwv Zm9udD48dHQ+PGZvbnQgc2l6ZT0zPjxicj4NCiA8YnI+DQpPbmUgbWlnaHQgYWxzbyBjb25zaWRl ciBvdGhlciwgSUVURiBzdGFuZGFyZCBtZWNoYW5pc21zIGZvciBwYXNzaW5nIDxicj4NCmFyb3Vu ZCBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBkYXRhIHRoYXQgaXMgdG8gYmUgY29u c3VtZWQgPGJyPg0KYnkgYSAzcmQgcGFydHkuIFRoc2kgc29ydCBvZiBmdW5jdGlvbiBpcyBub3Qg d2hhdCBJS0UgaXMgaW50ZW5kZWQgdG8gPGJyPg0KcGVyZm9ybS48L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJNViBCb2xpIj5UcmljY2kgJmd0OyBJ IGhvcGUgdGhhdCB5b3UNCmNhbiB1bmRlcnN0YW5kIHRoYXQgd2hhdCB5b3UgZGVzY3JpYmVkIGFi b3ZlIGlzIE5PVCB3aGF0IHdlIHByb3Bvc2VkLiAmbmJzcDtUaGFuaw0KeW91IGZvciB5b3VyIGNv bW1lbnRzLjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0zPjxicj4NCjxicj4NClN0ZXZlPC9mb250Pjwv dHQ+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCklQc2VjIG1haWxpbmcgbGlzdDxicj4NCklQc2Vj QGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHNl Yzxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0K --=_alternative 002FCC2348257994_=-- From zong.zaifeng@zte.com.cn Sun Jan 29 01:30:39 2012 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 494BA21F8512 for ; Sun, 29 Jan 2012 01:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.912 X-Spam-Level: X-Spam-Status: No, score=-93.912 tagged_above=-999 required=5 tests=[AWL=1.123, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 Ouj3O-Emmhh7 for ; Sun, 29 Jan 2012 01:30:38 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 78B3C21F8510 for ; Sun, 29 Jan 2012 01:30:37 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 538295521606; Sun, 29 Jan 2012 17:26:20 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 5467.20495145; Sun, 29 Jan 2012 17:30:29 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q0T9UPEY048752; Sun, 29 Jan 2012 17:30:25 +0800 (GMT-8) (envelope-from zong.zaifeng@zte.com.cn) In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F017A59DE7E91@il-ex01.ad.checkpoint.com> To: Yoav Nir , tso@zteusa.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zong.zaifeng@zte.com.cn Date: Sun, 29 Jan 2012 17:27:22 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-01-29 17:30:28, Serialize complete at 2012-01-29 17:30:28 Content-Type: multipart/alternative; boundary="=_alternative 003427FE48257994_=" X-MAIL: mse02.zte.com.cn q0T9UPEY048752 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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, 29 Jan 2012 09:30:39 -0000 This is a multipart message in MIME format. --=_alternative 003427FE48257994_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgWW9hdjoNCg0KVGhhbmtzIGZvciB5b3VyIGVtYWlsIGFuZCBzb3JyeSBmb3IgbXkgbGF0ZSBy ZXNwb25zZS4gU2luY2UgVHJpY2NpIGhhcyANCmFuc3dlcmVkIHNvbWUgb2YgeW91ciBxdWVzdGlv bnMsIEkgd291bGQgbGlrZSB0byBmb2N1cyBvbiAidGltZS1saW1pdGVkIiANCmlzc3VlLiBGcm9t IG15IHVuZGVyc3RhbmRpbmcsIHRob3NlIEZBUCBpbmZvcm1hdGlvbiAoZS5nLiBtb2RlIGFuZCBh bGxvd2VkIA0KbWVtZWJlciBncm91cHMpIGFyZSByZWxhdGl2ZWx5IHN0YWJsZSwgaGVuY2UsIEkg YXNzdW1lIHRoZSBjaGFuZ2Ugb2YgdGhlc2UgDQppbmZvcm1hdGlvbiBpcyBxdWl0ZSByYXJlLCBv bmx5IGluIGNhc2UgdGhlIG5ldHdvcmsgaXMgcmUtY29uZmlndXJlZC4gDQpXb3VsZG4ndCB5b3Ug dGhpbmsgdGhhdCBpdCBpcyByZWFzb25hYmxlIHRvIGFzc3VtZSB0aGF0IHRoZSBGQVAgbmVlZCB0 byANCnJlc3RhcnQgd2hlbiB0aGUgbmV0d29yayBpcyByZWNvbmZpZ3VyZWQ/IFNpbmNlIHRoZXJl IGlzIHRoZSBmZW10byANCm1hbmFnZW1lbnQgc3lzdGVtLCBpdCBpcyBub3QgaGFyZCB0byByZWJv b3QgdGhlIEZBUCBieSBpc3N1aW5nIGFuIG9yZGVyIA0KZnJvbSB0aGUgZmVtdG8gbWFuYWdlbWVu dCBzeXN0ZW0gcmVtb3RlbHksIHdpdGhvdXQgdGhlIGludm9sdmVtZW50IG9mIA0KaHVtYW4gaW50 ZXJmZXJlbmNlLiBIZW5jZSwgSSBhc3N1bWVkIHRoYXQgdGhlIGNvcmUgbmV0d29yayBhbHdheXMg Z2V0IHRoZSANCmluZm9ybWF0aW9uIGZyb20gRkFQLCBhbmQgdGhlIFNlR1cgd2lsbCBub3QgbmVl ZCB0byByZXBsYXkgdGhlIG5vdGFyaXplZCANCmRhdGEgdG8gdGhlIGNvcmUgbmV0d29yay4gRG9l cyB0aGlzIG1ha2Ugc2Vuc2UgdG8geW91Pw0KDQpUaGFua3MhDQoNCkJSDQpaYWlmZW5nDQoNCg0K DQogDQoNCg0KDQpZb2F2IE5pciA8eW5pckBjaGVja3BvaW50LmNvbT4gDQoyMDEyLTAxLTIyIDIz OjA0DQoNCsrVvP7Iyw0KIid6b25nLnphaWZlbmdAenRlLmNvbS5jbiciIDx6b25nLnphaWZlbmdA enRlLmNvbS5jbj4NCrOty80NCiJpcHNlY0BpZXRmLm9yZyIgPGlwc2VjQGlldGYub3JnPg0K1vfM 4g0KUkU6IFJlOiBbSVBzZWNdIFtJUFNlY106IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig DQpkcmFmdC16b25nLWlwc2VjbWUtaWtldjItY3BleHQ0ZmVtdG8tMDAudHh0DQoNCg0KDQoNCg0K DQpTbyBpZiBJIHVuZGVyc3RhbmQgdGhpcyBjb3JyZWN0bHksIHRoZSBub3Rhcml6ZWQgZGF0YSBj b250YWlucyB0aGUgDQphY2NlcHRhYmxlIG1vZGUgYW5kIHRoZSBhbGxvd2VkIG1lbWJlciBncm91 cHMsIHNpZ25lZCAoYW5kIHRpbWUtbGltaXRlZD8pIA0KYnkgdGhlIFNlR1cuIA0KIA0KVGhlIHR1 bm5lbGVkIHByb3RvY29sIGJldHdlZW4gdGhlIEZBUCBhbmQgdGhlIGNvcmUgbmV0d29yayB3b3Vs ZCBjaGFuZ2UsIA0Kc28gdGhhdCBpbnN0ZWFkIG9mIHRoZSBGQVAgc2VuZGluZyB1bnN1YnN0YW50 aWF0ZWQgY2xhaW1zLCBpdCB3b3VsZCByZXBsYXkgDQp0aGUgbm90YXJpemVkIGRhdGEgZnJvbSB0 aGUgU2VHVy4gV291bGRuJ3QgdGhpcyByZXF1aXJlIGFuIHVwZGF0ZSBvZiBib3RoIA0KY29yZSBu ZXR3b3JrIGNvbXBvbmVudHMsIFNlR1cgYW5kIEZBUHM/DQogDQpJIHdvdWxkIHRoaW5rIHRoYXQg dGhlIFNlR1cgY291bGQgaW5zdGVhZCBsb29rIGF0IHRoZSBkZWNyeXB0ZWQgcHJvdG9jb2wgDQpi ZXR3ZWVuIHRoZSBGQVAgYW5kIHRoZSBjb3JlIG5ldHdvcmsgIChpdCBpcyBkZWNyeXB0aW5nIGl0 IGFmdGVyIGFsbCksIGFuZCANCmJsb2NrIGl0IGlmIGl0IGNvbnRhaW5zICJsaWVzIi4gQSBjaGFu Z2UgbGlrZSB0aGlzIHdvdWxkIHJlcXVpcmUgbW9kaWZ5aW5nIA0Kb25seSB0aGUgU2VHVy4gSSBt YXkgYmUgc2hvd2luZyBzb21lIHNlcmlvdXMgZmlyZXdhbGwgdmVuZG9yIGJpYXMgaGVyZS4uLg0K IA0KQW55d2F5LCB5ZXMsIHlvdXIgY2xhcmlmaWNhdGlvbiBoZWxwZWQgbWUgdmVyeSBtdWNoLg0K IA0KUmVnYXJkaW5nIHRoZSB0ZXJtICJub3Rhcml6ZWQiLCBJIHdvdWxkIHByZWZlciBub3QgdG8g YnJpbmcgaW4gYSBuZXcgdGVybSANCnRoYXQgaXMgYnVyZGVuZWQgd2l0aCBvdGhlciBtZWFuaW5n LiBCdXQgbGVnYWwgbm90YXJpZXMgYXJlIG9ic2N1cmUgZW5vdWdoIA0KdGhhdCBpdCBkb2Vzbid0 IG1hdHRlciBtdWNoLiBQZXJoYXBzIHNvbWUgZXhwbGFuYXRpb24gYXMgdG8gd2hhdCBpdCBtZWFu cyANCmluIHRoZSBkcmFmdCB3b3VsZCBoZWxwLg0KIA0KIA0KWW91IGFyZSBjb3JyZWN0IGluIHRo ZSBkcmFmdCwgdGhhdCBpdCBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSB3b3JraW5nIA0KZ3JvdXAg d2hhdCB0aGUgZXhhY3QgY29udGVudCBvZiB0aGUgbmV3IGF0dHJpYnV0ZSBpcy4gSG93ZXZlciwg dGhlIENQIA0KcGF5bG9hZCBpcyBjb250YWluZWQgaW4gdGhlIGJpZ2dlc3QgcGFja2V0IG9mIGFs bCBvZiBJS0UgLSB0aGUgSUtFX0FVVEggDQpwYWNrZXRzLiBDYW4geW91IHRlbGwgdXMgaG93IGxh cmdlIHRoZXNlIGF0dHJpYnV0ZXMgbWF5IGJlPyBTaW5jZSBJS0UgaXMgDQpzdGlsbCBVRFAtb25s eSwgc2l6ZSBtYXR0ZXJzIHZlcnkgbXVjaC4NCiANClRoYW5rcw0KIA0KWW9hdg0KDQpGcm9tOiB6 b25nLnphaWZlbmdAenRlLmNvbS5jbiBbbWFpbHRvOnpvbmcuemFpZmVuZ0B6dGUuY29tLmNuXSAN ClNlbnQ6IDIxIEphbnVhcnkgMjAxMiAxMTowOA0KVG86IFlvYXYgTmlyDQpDYzogaXBzZWNAaWV0 Zi5vcmcNClN1YmplY3Q6ILTwuLQ6IFJlOiBbSVBzZWNdIFtJUFNlY106IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgDQpkcmFmdC16b25nLWlwc2VjbWUtaWtldjItY3BleHQ0ZmVtdG8tMDAu dHh0DQoNCg0KSGkgWW9hdjogDQoNClRoYW5rIHlvdSBmb3IgeW91ciBlbWFpbC4gUmVnYXJkaW5n IHRvIHlvdXIgcXVlc3Rpb24gb24gIndoYXQgaXMgdGhlIA0KbWFsaWNpb3VzIEZBUCBseWluZyBh Ym91dCIsIEkgd291bGQgbGlrZSB0byBnaXZlIHlvdSBzb21lIGZ1cnRoZXIgDQpiYWNrZ3JvdW5k LiBJbiByZWFsIGZlbXRvIGRlcGxveW1lbnQsIG5vdCBldmVyeSBtb2JpbGUgdGVybWluYWwgaXMg YWxsb3dlZCANCnRvIGF0dGFjaCB2aWEgYW4gRkFQLiBJbiBmYWN0LCBpbiB0aGUgcmVhbCBkZXBs b3ltZW50LCB0aGVyZSBhcmUgMyBraW5kcyANCm9mIEZBUHM6IG9wZW4gbW9kZSBGQVAsIGNsb3Nl IG1vZGUgRkFQLCBhbmQgaHlicmlkIG1vZGUgRkFQLiBUaGUgb3BlbiBtb2RlIA0KbWVhbnMgdGhh dCB0aGUgRkFQIGlzIG9wZW4gdG8gZXZlcnlvbmUsIGNsb3NlIG1vZGUgbWVhbnMgdGhlIEZBUCBv bmx5IA0KYWxsb3dzIGEgY2xvc2VkIGdyb3VwIG9mIG1lbWJlcnMgdG8gYWNjZXNzLCBhbmQgdGhl IGh5YnJpZCBtb2RlIG1lYW5zIHRoYXQgDQp0aGUgRkFQIGlzIG9wZW4gdG8gZXZlcnlvbmUsIGJ1 dCBvbmx5IGEgY2xvc2VkIGdyb3VwIG9mIG1lbWJlcnMgd2lsbCBoYXZlIA0KaGlnaGVyIHByaW9y aXR5IG9yIGhhdmUgYXV0aG9yaXR5IHRvIHZpc2l0IGNlcnRhaW4gcmVzb3VyY2VzLiANCg0KQWNj b3JkaW5nIHRvIHNvbWUgU0RPIChlLmcuIDNHUFApLCB0aGUgYWNjZXNzIGNvbnRyb2wgb2YgdGhl IG1vYmlsZSANCnRlcm1pbmFscyBhdHRhY2hpbmcgdmlhIGEgRkFQIGlzIGRvbmUgaW4gY29yZSBu ZXR3b3JrLCB0aHVzLCBpdCBpcyB0aGUgDQpjb3JlIG5ldHdvcmsgdGhhdCBkZWNpZGUgd2hldGhl ciB0aGUgbW9iaWxlIHRlcm1pbmFsIGNhbiBhdHRhY2ggdG8gYW4gRkFQLiANCkluIG9yZGVyIHRv IGhlbHAgdGhlIGNvcmUgbmV0d29yayBtYWtlIGRlY2lzaW9uIG9uIHdoZXRoZXIgdGhlIG1vYmls ZSANCnRlcm1pbmFsIGNhbiBhdHRhY2ggdG8gYW4gRkFQLCB0aGUgRkFQIG5lZWRzIHRvIHNlbmQg aW5mb3JtYXRpb24sIHN1Y2ggYXMgDQp0aGUgbW9kZSBvZiB0aGUgRkFQLCBhbmQgdGhlIGFsbG93 ZWQgbWVtYmVyIGdyb3VwIG9mIHRoZSBGQVAsIHRvIHRoZSBjb3JlIA0KbmV0d29yay4gQSBjb21w cm9taXNlZCBGQVAgY291bGQgc2VuZCBmYWxzZSBtb2RlIGFuZCBmYWxzZSBhbGxvd2VkIG1lbWJl ciANCmdyb3VwIHRvIHRoZSBjb3JlIG5ldHdvcmssIHNvIHRoYXQgYSBub3QgYWxsb3dlZCBtb2Jp bGUgdGVybWluYWwgY291bGQgYmUgDQphbGxvd2VkIGJ5IHRoZSBjb3JlIG5ldHdvcmsuIA0KDQpJ IHdpc2ggdGhlIGFib3ZlIGNsYXJpZmljYXRpb24gaGVscHMgeW91IHVuZGVyc3RhbmQgdGhlIHBy b2JsZW0uIA0KDQpSZWdhcmRpbmcgdG8gdGhlIHRlcm0gbm90YXJpemVkLCBzaW5jZSBJIGFtIGdy ZWVuIHRvIHRoaXMgZ3JvdXAsIEkgYW0gbm90IA0Kc3VyZSwgZG8geW91IHByZWZlciB0byByZXBs YWNlIHRoZSBub3Rhcml6ZSB3aXRoIHNpZ25hdHVyZT8gUGxlYXNlIGxldCBtZSANCmtub3csIHRo YW5rIHlvdSEgDQoNCg0KQlIgDQpaYWlmZW5nIA0KDQogIA0KDQoNCllvYXYgTmlyIDx5bmlyQGNo ZWNrcG9pbnQuY29tPiANCjIwMTItMDEtMjEgMTU6MzAgDQoNCg0KytW8/sjLDQoiPHpvbmcuemFp ZmVuZ0B6dGUuY29tLmNuPiA8em9uZy56YWlmZW5nQHp0ZS5jb20uY24+IiANCjx6b25nLnphaWZl bmdAenRlLmNvbS5jbj4gDQqzrcvNDQoiaXBzZWNAaWV0Zi5vcmciIDxpcHNlY0BpZXRmLm9yZz4g DQrW98ziDQpSZTogW0lQc2VjXSBbSVBTZWNdOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IA0KZHJhZnQtem9uZy1pcHNlY21lLWlrZXYyLWNwZXh0NGZlbXRvLTAwLnR4dA0KDQoNCg0KDQoN Cg0KDQoNCkhpIFphaWZlbmcNCg0KUmVhZGluZyB5b3VyIGRyYWZ0LCBJJ20gdHJ5aW5nIHRvIHVu ZGVyc3RhbmQgdGhlIHByb2JsZW0geW91IGFyZSBzb2x2aW5nLiANCkl0IGlzIGFib3V0IHRoZSBG QVAgYmVpbmcgY29tcHJvbWlzZWQgYW5kIHNlbmRpbmcgZmFsc2UgaW5mb3JtYXRpb24gDQp0aHJv dWdoIHRoZSB0dW5uZWwuDQoNCldoYXQgaXMgdGhlIG1hbGljaW91cyBGQVAgbHlpbmcgYWJvdXQ/ DQpIb3cgZG9lcyBzZW5kaW5nIHNvbWUgaW5mb3JtYXRpb24gKGRvZXMgIm5vdGFyaXplZCIgbWVh biAic2lnbmVkIj8pIGZyb20gDQp0aGUgU2VHVyB0byB0aGUgKGNvbXByb21pc2VkKSBGQVAgaGVs cD8NCg0KT25lIGdlbmVyYWwgY29tbWVudDogIm5vdGFyaXplZCIgaXMgYSBsZWdhbCB0ZXJtLCBz aW1pbGFyIHRvICJzaWduYXR1cmUiLiANCkFsdGhvdWdoIHRoZXJlIGlzIHNvbWUgYW5hbG9neSBi ZXR3ZWVuIHRoZSBsZWdhbCBjb25jZXB0IG9mIHNpZ25hdHVyZSBhbmQgDQp0aGUgZGlnaXRhbCBz aWduYXR1cmVzLCBzdWNoIGFuYWxvZ2llcyBvbmx5IGdvIHNvIGZhci4gVXNpbmcgc3VjaCBhIA0K Ym9ycm93ZWQgdGVybSBoYXMgSU1ITyBsZWQgdG8gbW9yZSBjb25mdXNpb24gdGhhbiBjbGFyaXR5 LiBJIHdvdWxkIHJhdGhlciANCm5vdCB1c2UgbGVnYWwgdGVybXMgaW4gcHJvdG9jb2xzIChhbHRo b3VnaCAicHJvdG9jb2wiIGlzIGFsc28gYSBib3Jyb3dlZCANCnRlcm0pDQoNClRoYW5rcywNCg0K WW9hdg0KDQpPbiBKYW4gMjAsIDIwMTIsIGF0IDg6NDAgQU0sIDx6b25nLnphaWZlbmdAenRlLmNv bS5jbj4gDQo8em9uZy56YWlmZW5nQHp0ZS5jb20uY24+IHdyb3RlOg0KDQo+IA0KPiBIaSBGb2xr czogDQo+IA0KPiBUaGVyZSBpcyBhIG5ldyBkcmFmdCBhdmFpbGFibGUgdGhhdCBzb21lIG9mIHlv dSBtYXkgYmUgaW50ZXJlc3RlZA0KPiBpbiBsb29raW5nIGF0LiANCj4gDQo+IFRoZSBkcmFmdCBp cyBhdmFpbGFibGUgdmlhIHRoZSBmb2xsb3dpbmcgbGluazogDQo+IGh0dHA6Ly93d3cuaWV0Zi5v cmcvaWQvZHJhZnQtem9uZy1pcHNlY21lLWlrZXYyLWNwZXh0NGZlbXRvLTAwLnR4dCANCj4gDQo+ IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QuIFRoYW5rcyEgDQo+IA0KPiAN Cj4gQlIgDQo+IFphaWZlbmcgDQoNCg0KDQoNCg== --=_alternative 003427FE48257994_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFlvYXY6PC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MgZm9yIHlvdXIgZW1h aWwgYW5kIHNvcnJ5IGZvcg0KbXkgbGF0ZSByZXNwb25zZS4gU2luY2UgVHJpY2NpIGhhcyBhbnN3 ZXJlZCBzb21lIG9mIHlvdXIgcXVlc3Rpb25zLCBJIHdvdWxkDQpsaWtlIHRvIGZvY3VzIG9uICZx dW90O3RpbWUtbGltaXRlZCZxdW90OyBpc3N1ZS4gRnJvbSBteSB1bmRlcnN0YW5kaW5nLA0KdGhv c2UgRkFQIGluZm9ybWF0aW9uIChlLmcuIG1vZGUgYW5kIGFsbG93ZWQgbWVtZWJlciBncm91cHMp IGFyZSByZWxhdGl2ZWx5DQpzdGFibGUsIGhlbmNlLCBJIGFzc3VtZSB0aGUgY2hhbmdlIG9mIHRo ZXNlIGluZm9ybWF0aW9uIGlzIHF1aXRlIHJhcmUsDQpvbmx5IGluIGNhc2UgdGhlIG5ldHdvcmsg aXMgcmUtY29uZmlndXJlZC4gV291bGRuJ3QgeW91IHRoaW5rIHRoYXQgaXQgaXMNCnJlYXNvbmFi bGUgdG8gYXNzdW1lIHRoYXQgdGhlIEZBUCBuZWVkIHRvIHJlc3RhcnQgd2hlbiB0aGUgbmV0d29y ayBpcyByZWNvbmZpZ3VyZWQ/DQpTaW5jZSB0aGVyZSBpcyB0aGUgZmVtdG8gbWFuYWdlbWVudCBz eXN0ZW0sIGl0IGlzIG5vdCBoYXJkIHRvIHJlYm9vdCB0aGUNCkZBUCBieSBpc3N1aW5nIGFuIG9y ZGVyIGZyb20gdGhlIGZlbXRvIG1hbmFnZW1lbnQgc3lzdGVtIHJlbW90ZWx5LCB3aXRob3V0DQp0 aGUgaW52b2x2ZW1lbnQgb2YgaHVtYW4gaW50ZXJmZXJlbmNlLiBIZW5jZSwgSSBhc3N1bWVkIHRo YXQgdGhlIGNvcmUgbmV0d29yaw0KYWx3YXlzIGdldCB0aGUgaW5mb3JtYXRpb24gZnJvbSBGQVAs IGFuZCB0aGUgU2VHVyB3aWxsIG5vdCBuZWVkIHRvIHJlcGxheQ0KdGhlIG5vdGFyaXplZCBkYXRh IHRvIHRoZSBjb3JlIG5ldHdvcmsuIERvZXMgdGhpcyBtYWtlIHNlbnNlIHRvIHlvdT88L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyE8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJSPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5aYWlmZW5nPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0xIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+WW9hdiBOaXIgJmx0O3luaXJAY2hlY2twb2ludC5jb20m Z3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTIt MDEtMjIgMjM6MDQ8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+JnF1b3Q7J3pvbmcuemFpZmVuZ0B6dGUuY29tLmNuJyZxdW90Ow0KJmx0O3pv bmcuemFpZmVuZ0B6dGUuY29tLmNuJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7aXBzZWNA aWV0Zi5vcmcmcXVvdDsgJmx0O2lwc2VjQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ UkU6IFJlOiBbSVBzZWNdIFtJUFNlY106IE5ldyBWZXJzaW9uDQpOb3RpZmljYXRpb24gZm9yICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LXpvbmctaXBzZWNtZS1pa2V2Mi1jcGV4dDRm ZW10by0wMC50eHQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPlNvIGlmIEkgdW5kZXJzdGFuZCB0aGlz IGNvcnJlY3RseSwNCnRoZSBub3Rhcml6ZWQgZGF0YSBjb250YWlucyB0aGUgYWNjZXB0YWJsZSBt b2RlIGFuZCB0aGUgYWxsb3dlZCBtZW1iZXINCmdyb3Vwcywgc2lnbmVkIChhbmQgdGltZS1saW1p dGVkPykgYnkgdGhlIFNlR1cuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRh aG9tYSI+VGhlIHR1bm5lbGVkIHByb3RvY29sIGJldHdlZW4NCnRoZSBGQVAgYW5kIHRoZSBjb3Jl IG5ldHdvcmsgd291bGQgY2hhbmdlLCBzbyB0aGF0IGluc3RlYWQgb2YgdGhlIEZBUCBzZW5kaW5n DQp1bnN1YnN0YW50aWF0ZWQgY2xhaW1zLCBpdCB3b3VsZCByZXBsYXkgdGhlIG5vdGFyaXplZCBk YXRhIGZyb20gdGhlIFNlR1cuDQpXb3VsZG4ndCB0aGlzIHJlcXVpcmUgYW4gdXBkYXRlIG9mIGJv dGggY29yZSBuZXR3b3JrIGNvbXBvbmVudHMsIFNlR1cgYW5kDQpGQVBzPzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+SSB3b3VsZCB0aGluayB0aGF0IHRoZSBTZUdX IGNvdWxkDQppbnN0ZWFkIGxvb2sgYXQgdGhlIGRlY3J5cHRlZCBwcm90b2NvbCBiZXR3ZWVuIHRo ZSBGQVAgYW5kIHRoZSBjb3JlIG5ldHdvcmsNCiZuYnNwOyhpdCBpcyBkZWNyeXB0aW5nIGl0IGFm dGVyIGFsbCksIGFuZCBibG9jayBpdCBpZiBpdCBjb250YWlucyAmcXVvdDtsaWVzJnF1b3Q7Lg0K QSBjaGFuZ2UgbGlrZSB0aGlzIHdvdWxkIHJlcXVpcmUgbW9kaWZ5aW5nIG9ubHkgdGhlIFNlR1cu IEkgbWF5IGJlIHNob3dpbmcNCnNvbWUgc2VyaW91cyBmaXJld2FsbCB2ZW5kb3IgYmlhcyBoZXJl Li4uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj5Bbnl3YXksIHll cywgeW91ciBjbGFyaWZpY2F0aW9uDQpoZWxwZWQgbWUgdmVyeSBtdWNoLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+UmVnYXJkaW5nIHRoZSB0ZXJtICZxdW90O25v dGFyaXplZCZxdW90OywNCkkgd291bGQgcHJlZmVyIG5vdCB0byBicmluZyBpbiBhIG5ldyB0ZXJt IHRoYXQgaXMgYnVyZGVuZWQgd2l0aCBvdGhlciBtZWFuaW5nLg0KQnV0IGxlZ2FsIG5vdGFyaWVz IGFyZSBvYnNjdXJlIGVub3VnaCB0aGF0IGl0IGRvZXNuJ3QgbWF0dGVyIG11Y2guIFBlcmhhcHMN CnNvbWUgZXhwbGFuYXRpb24gYXMgdG8gd2hhdCBpdCBtZWFucyBpbiB0aGUgZHJhZnQgd291bGQg aGVscC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+WW91IGFyZSBjb3JyZWN0 IGluIHRoZSBkcmFmdCwNCnRoYXQgaXQgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGUgd29ya2luZyBn cm91cCB3aGF0IHRoZSBleGFjdCBjb250ZW50IG9mDQp0aGUgbmV3IGF0dHJpYnV0ZSBpcy4gSG93 ZXZlciwgdGhlIENQIHBheWxvYWQgaXMgY29udGFpbmVkIGluIHRoZSBiaWdnZXN0DQpwYWNrZXQg b2YgYWxsIG9mIElLRSAtIHRoZSBJS0VfQVVUSCBwYWNrZXRzLiBDYW4geW91IHRlbGwgdXMgaG93 IGxhcmdlDQp0aGVzZSBhdHRyaWJ1dGVzIG1heSBiZT8gU2luY2UgSUtFIGlzIHN0aWxsIFVEUC1v bmx5LCBzaXplIG1hdHRlcnMgdmVyeQ0KbXVjaC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPSJUYWhvbWEiPlRoYW5rczwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 IlRhaG9tYSI+WW9hdjwvZm9udD4NCjxicj4NCjxicj4NCjxocj48Zm9udCBzaXplPTIgZmFjZT0i VGFob21hIj48Yj5Gcm9tOjwvYj4gem9uZy56YWlmZW5nQHp0ZS5jb20uY24gW21haWx0bzp6b25n LnphaWZlbmdAenRlLmNvbS5jbl0NCjxiPjxicj4NClNlbnQ6PC9iPiAyMSBKYW51YXJ5IDIwMTIg MTE6MDg8Yj48YnI+DQpUbzo8L2I+IFlvYXYgTmlyPGI+PGJyPg0KQ2M6PC9iPiBpcHNlY0BpZXRm Lm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiC08Li0OiBSZTogW0lQc2VjXSBbSVBTZWNdOiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQpkcmFmdC16b25nLWlwc2VjbWUtaWtldjItY3BleHQ0 ZmVtdG8tMDAudHh0PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpIFlvYXY6 PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUaGFuayB5b3UgZm9yIHlvdXIgZW1haWwu IFJlZ2FyZGluZyB0byB5b3VyIHF1ZXN0aW9uIG9uICZxdW90O3doYXQgaXMgdGhlDQptYWxpY2lv dXMgRkFQIGx5aW5nIGFib3V0JnF1b3Q7LCBJIHdvdWxkIGxpa2UgdG8gZ2l2ZSB5b3Ugc29tZSBm dXJ0aGVyDQpiYWNrZ3JvdW5kLiBJbiByZWFsIGZlbXRvIGRlcGxveW1lbnQsIG5vdCBldmVyeSBt b2JpbGUgdGVybWluYWwgaXMgYWxsb3dlZA0KdG8gYXR0YWNoIHZpYSBhbiBGQVAuIEluIGZhY3Qs IGluIHRoZSByZWFsIGRlcGxveW1lbnQsIHRoZXJlIGFyZSAzIGtpbmRzDQpvZiBGQVBzOiBvcGVu IG1vZGUgRkFQLCBjbG9zZSBtb2RlIEZBUCwgYW5kIGh5YnJpZCBtb2RlIEZBUC4gVGhlIG9wZW4g bW9kZQ0KbWVhbnMgdGhhdCB0aGUgRkFQIGlzIG9wZW4gdG8gZXZlcnlvbmUsIGNsb3NlIG1vZGUg bWVhbnMgdGhlIEZBUCBvbmx5IGFsbG93cw0KYSBjbG9zZWQgZ3JvdXAgb2YgbWVtYmVycyB0byBh Y2Nlc3MsIGFuZCB0aGUgaHlicmlkIG1vZGUgbWVhbnMgdGhhdCB0aGUNCkZBUCBpcyBvcGVuIHRv IGV2ZXJ5b25lLCBidXQgb25seSBhIGNsb3NlZCBncm91cCBvZiBtZW1iZXJzIHdpbGwgaGF2ZSBo aWdoZXINCnByaW9yaXR5IG9yIGhhdmUgYXV0aG9yaXR5IHRvIHZpc2l0IGNlcnRhaW4gcmVzb3Vy Y2VzLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkFjY29yZGluZyB0byBzb21lIFNE TyAoZS5nLiAzR1BQKSwgdGhlIGFjY2VzcyBjb250cm9sIG9mIHRoZSBtb2JpbGUgdGVybWluYWxz DQphdHRhY2hpbmcgdmlhIGEgRkFQIGlzIGRvbmUgaW4gY29yZSBuZXR3b3JrLCB0aHVzLCBpdCBp cyB0aGUgY29yZSBuZXR3b3JrDQp0aGF0IGRlY2lkZSB3aGV0aGVyIHRoZSBtb2JpbGUgdGVybWlu YWwgY2FuIGF0dGFjaCB0byBhbiBGQVAuIEluIG9yZGVyDQp0byBoZWxwIHRoZSBjb3JlIG5ldHdv cmsgbWFrZSBkZWNpc2lvbiBvbiB3aGV0aGVyIHRoZSBtb2JpbGUgdGVybWluYWwgY2FuDQphdHRh Y2ggdG8gYW4gRkFQLCB0aGUgRkFQIG5lZWRzIHRvIHNlbmQgaW5mb3JtYXRpb24sIHN1Y2ggYXMg dGhlIG1vZGUgb2YNCnRoZSBGQVAsIGFuZCB0aGUgYWxsb3dlZCBtZW1iZXIgZ3JvdXAgb2YgdGhl IEZBUCwgdG8gdGhlIGNvcmUgbmV0d29yay4NCkEgY29tcHJvbWlzZWQgRkFQIGNvdWxkIHNlbmQg ZmFsc2UgbW9kZSBhbmQgZmFsc2UgYWxsb3dlZCBtZW1iZXIgZ3JvdXANCnRvIHRoZSBjb3JlIG5l dHdvcmssIHNvIHRoYXQgYSBub3QgYWxsb3dlZCBtb2JpbGUgdGVybWluYWwgY291bGQgYmUgYWxs b3dlZA0KYnkgdGhlIGNvcmUgbmV0d29yay4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4N Ckkgd2lzaCB0aGUgYWJvdmUgY2xhcmlmaWNhdGlvbiBoZWxwcyB5b3UgdW5kZXJzdGFuZCB0aGUg cHJvYmxlbS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpSZWdhcmRpbmcgdG8gdGhl IHRlcm0gbm90YXJpemVkLCBzaW5jZSBJIGFtIGdyZWVuIHRvIHRoaXMgZ3JvdXAsIEkgYW0gbm90 DQpzdXJlLCBkbyB5b3UgcHJlZmVyIHRvIHJlcGxhY2UgdGhlIG5vdGFyaXplIHdpdGggc2lnbmF0 dXJlPyBQbGVhc2UgbGV0DQptZSBrbm93LCB0aGFuayB5b3UhPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj48YnI+DQpCUjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KWmFpZmVuZzwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXpl PTEgZmFjZT0iQXJpYWwiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOzxicj4NCjxicj4NCjwvZm9udD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9MjUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj5Zb2F2IE5pciAmbHQ7eW5pckBjaGVja3BvaW50LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0wMS0yMSAxNTozMDwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8dGQgd2lkdGg9NzQlPg0KPGJy Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD01JT4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9u dD48L2Rpdj4NCjx0ZCB3aWR0aD05NCU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZx dW90OyZsdDt6b25nLnphaWZlbmdAenRlLmNvbS5jbiZndDsNCiZsdDt6b25nLnphaWZlbmdAenRl LmNvbS5jbiZndDsmcXVvdDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0O3pvbmcuemFp ZmVuZ0B6dGUuY29tLmNuJmd0OzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+ DQo8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O2lwc2VjQGlldGYub3JnJnF1b3Q7ICZsdDtpcHNl Y0BpZXRmLm9yZyZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5SZTogW0lQc2VjXSBbSVBTZWNdOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24NCmZvciAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC16b25nLWlwc2VjbWUt aWtldjItY3BleHQ0ZmVtdG8tMDAudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0 aD01MCU+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5z LXNlcmlmIj48YnI+DQo8YnI+DQo8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpIaSBaYWlm ZW5nPGJyPg0KPGJyPg0KUmVhZGluZyB5b3VyIGRyYWZ0LCBJJ20gdHJ5aW5nIHRvIHVuZGVyc3Rh bmQgdGhlIHByb2JsZW0geW91IGFyZSBzb2x2aW5nLg0KSXQgaXMgYWJvdXQgdGhlIEZBUCBiZWlu ZyBjb21wcm9taXNlZCBhbmQgc2VuZGluZyBmYWxzZSBpbmZvcm1hdGlvbiB0aHJvdWdoDQp0aGUg dHVubmVsLjxicj4NCjxicj4NCldoYXQgaXMgdGhlIG1hbGljaW91cyBGQVAgbHlpbmcgYWJvdXQ/ PGJyPg0KSG93IGRvZXMgc2VuZGluZyBzb21lIGluZm9ybWF0aW9uIChkb2VzICZxdW90O25vdGFy aXplZCZxdW90OyBtZWFuICZxdW90O3NpZ25lZCZxdW90Oz8pDQpmcm9tIHRoZSBTZUdXIHRvIHRo ZSAoY29tcHJvbWlzZWQpIEZBUCBoZWxwPzxicj4NCjxicj4NCk9uZSBnZW5lcmFsIGNvbW1lbnQ6 ICZxdW90O25vdGFyaXplZCZxdW90OyBpcyBhIGxlZ2FsIHRlcm0sIHNpbWlsYXIgdG8NCiZxdW90 O3NpZ25hdHVyZSZxdW90Oy4gQWx0aG91Z2ggdGhlcmUgaXMgc29tZSBhbmFsb2d5IGJldHdlZW4g dGhlIGxlZ2FsDQpjb25jZXB0IG9mIHNpZ25hdHVyZSBhbmQgdGhlIGRpZ2l0YWwgc2lnbmF0dXJl cywgc3VjaCBhbmFsb2dpZXMgb25seSBnbw0Kc28gZmFyLiBVc2luZyBzdWNoIGEgYm9ycm93ZWQg dGVybSBoYXMgSU1ITyBsZWQgdG8gbW9yZSBjb25mdXNpb24gdGhhbg0KY2xhcml0eS4gSSB3b3Vs ZCByYXRoZXIgbm90IHVzZSBsZWdhbCB0ZXJtcyBpbiBwcm90b2NvbHMgKGFsdGhvdWdoICZxdW90 O3Byb3RvY29sJnF1b3Q7DQppcyBhbHNvIGEgYm9ycm93ZWQgdGVybSk8YnI+DQo8YnI+DQpUaGFu a3MsPGJyPg0KPGJyPg0KWW9hdjxicj4NCjxicj4NCk9uIEphbiAyMCwgMjAxMiwgYXQgODo0MCBB TSwgJmx0O3pvbmcuemFpZmVuZ0B6dGUuY29tLmNuJmd0OyAmbHQ7em9uZy56YWlmZW5nQHp0ZS5j b20uY24mZ3Q7DQp3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkgRm9sa3M6IDxi cj4NCiZndDsgPGJyPg0KJmd0OyBUaGVyZSBpcyBhIG5ldyBkcmFmdCBhdmFpbGFibGUgdGhhdCBz b21lIG9mIHlvdSBtYXkgYmUgaW50ZXJlc3RlZDxicj4NCiZndDsgaW4gbG9va2luZyBhdC4gPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBkcmFmdCBpcyBhdmFpbGFibGUgdmlhIHRoZSBmb2xsb3dp bmcgbGluazogPGJyPg0KJmd0OyBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXpvbmctaXBz ZWNtZS1pa2V2Mi1jcGV4dDRmZW10by0wMC50eHQNCjxicj4NCiZndDsgPGJyPg0KJmd0OyBQbGVh c2Ugc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0LiBUaGFua3MhIDxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEJSIDxicj4NCiZndDsgWmFpZmVuZyA8YnI+DQo8YnI+DQo8L2Zv bnQ+PC90dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9mb250Pg0KPGJy Pg0K --=_alternative 003427FE48257994_=-- From conti@math.unipd.it Sat Jan 28 06:04:25 2012 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 EC40421F855F for ; Sat, 28 Jan 2012 06:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.295 X-Spam-Level: ** X-Spam-Status: No, score=2.295 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_54=0.6] 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 gHmDeON2K1Ze for ; Sat, 28 Jan 2012 06:04:24 -0800 (PST) Received: from server0.math.unipd.it (server0.math.unipd.it [147.162.22.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2862121F84AA for ; Sat, 28 Jan 2012 06:04:23 -0800 (PST) Received: from [192.168.0.2] (host28-101-dynamic.183-80-r.retail.telecomitalia.it [80.183.101.28]) (authenticated bits=0) by server0.math.unipd.it (8.14.3/8.14.3) with ESMTP id q0SE4FqU085323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Jan 2012 14:04:16 GMT Message-ID: <4F24005A.5040402@math.unipd.it> Date: Sat, 28 Jan 2012 15:04:10 +0100 From: "Dr. Mauro Conti" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 29 Jan 2012 08:23:14 -0800 Subject: [IPsec] CfP: MobiSec 2012 - 4th International Conference on Security and Privacy in Mobile Information and Communication Systems 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, 28 Jan 2012 14:26:50 -0000 (We apologize if you receive multiple copies of this email) CALL FOR PAPERS =============== The 4th International Conference on Security and Privacy in Mobile Information and Communication Systems Mobisec 2012, Frankfurt, Germany 25 - 27 June 2012 http://mobisec.org/2012 MobiSec's focus is the convergence of information and communication technology in mobile scenarios. This convergence is realised in intelligent mobile devices, accompanied by the advent of next-generation communication networks. Privacy and security aspects need to be covered at all layers of mobile networks, from mobile devices, to privacy respecting credentials and mobile identity management, up to machine-to-machine communications. In particular, mobile devices such as Smartphones and Internet Tablets have been very successful in commercialization. However, their security mechanisms are not always able to deal with the growing trend of information-stealing attacks. As mobile communication and information processing becomes a commodity, economy and society require protection of this precious resource. Mobility and trust in networking go hand in hand for future generations of users, who need privacy and security at all layers of technology. In addition, the introduction of new data collection practices and data-flows (e.g. sensing data) from the mobile device makes it more difficult to understand the new security and privacy threats introduced. MobiSec strives to bring together the leading-edge of academia and industry in mobile systems security, as well as practitioners, standards developers and policymakers. Contributions may range from architecture designs and implementations to cryptographic solutions for mobile and resource-constrained devices. TOPICS ====== Topics of interest include, but are not limited to, the following focus areas: Smartphone Security and Privacy: * Advanced Security Mechanisms * Virtualisation Solutions * Rogue Mobile Application Detection and Protection * Forensic Analysis Machine-to-Machine Secure Communication: * Device Identities and Authentication * Remote Integrity Validation and Remediation * Remote Management and Provisioning * Machine-to-Machine Application Layer Security * Secure Elements and Trusted Environments Privacy and Security in Emerging Mobile Applications and Services: * Privacy-respecting Authentication * Mobile Identity Management * Mobile Wallets, Mobile Payments * Location-based Services and Mobile Sensing Proposals for panels/demos/workshops/tutorials are solicited. Potential organisers are welcome to submit a proposal to one of the general chairs or the Workshops or Panels chair. Important Dates =============== Submission Date : Mar. 18, 2012 Notification of acceptance: Apr. 23, 2012 Camera Ready submission : May. 4, 2012 Conference dates : June 25-27, 2012 PUBLICATIONS ============ Accepted papers will be published in Springer's LNICST series and will appear in the SpringerLink, one of the largest digital libraries online that covers a variety of scientific disciplines, as well as in the ICST's own EU Digital Library (EUDL). LNICST volumes are submitted for inclusion to leading indexing services, including DBLP, Google Scholar, ACM Digital Library, ISI Proceedings, EI Engineering Index, CrossRef, Scopus. Seehttp://www.springer.com/computer/lncs?SGWID=0-164-6-1068921-0 for more information about indexing. PAPER SUBMISSION Authors are invited to submit papers of up to 12 pages for full papers, 6 pages for short papers. Steering Committee ================== * Imrich Chlamtac (Chair), President, CREATE-NET Research Consortium, Trento, Italy * Ramjee Prasad, Aalborg University, Denmark * Andreas U. Schmidt, Director, Novalyst IT AG, Karben, Germany Organising Committee ==================== General Chair / General Co-Chairs: * Neeli R. Prasad, Aalborg University, Denmark * Andreas U. Schmidt, Novalyst IT AG, Karben, Germany TPC Chair/TPC Co-Chairs: * Ioannis Krontiris, Goethe University Frankfurt, Germany * Giovanni Russello, University of Auckland, New Zealand - Publication Chair: Shiguo Lian, France Telecom R&D, Beijing, China - Publicity Chair(s): Mauro Conti, University of Padua, Italy; Rasmus Hjorth Nielsen, CTIF, Princeton, USA - Workshops Chair(s): Vincent Naessens, KaHo Sint-Lieven, Gent, Belgium - Panels Chair:Dirk Kröselberg, Siemens CERT, Munich, Germany - Web Chair: Andreas Leicher, Novalyst IT AG, Karben, Germany - Conference Coordinator: Justina Senkus, EAI/ICST Trento, Italy Program Committee ================= * Andreas Albers, Goethe University Frankfurt, Germany * Claudio Agostino Ardagna, University of Milan, Italy * Lejla Batina, Radboud University Nijmegen, The Netherlands * Zinaida Benenson, University of Erlangen-Nürnberg, Germany * Rocky Chang, Hong Kong Polytechnic University, China * Mauro Conti, University of Padua, Italy * Bruno Crispo, University of Trento, Italy * Tassos Dimitriou, Athens Information Technology, Greece * Changyu Dong, University of Strathclyde, UK * William Enck, North Carolina State University, USA * Hannes Federrath, University of Hamburg, Germany * Felix Freiling, University of Erlangen-Nürnberg, Germany * Ashish Gehani, SRI International, USA * Seda Gürses, Katholieke Universiteit Leuven, Belgium * Dogan Kesdogan, University of Siegen, Germany * Geir M. Køien, University of Adger, Norway * Marc Langheinrich, University of Lugano, Switzerland * Jiqiang Lu, Institute for Infocomm Research, Singapore * Flaminia Luccio, University Ca' Foscari of Venice, Italy * Emmanouil Magkos, Ionian University, Greece * Marco Casassa Mont, Hewlett Packard Laboratories, Bristol, UK * Raphael C.-W. Phan, Loughborough University, UK * Anand Prasad, NEC Laboratories Japan * Reijo Savola, VTT Technical Research Centre of Finland, Finland * Aubrey-Derrick Schmidt, Technical University Berlin, Germany * Jean-Pierre Seifert, TU-Berlin, T-Labs, Germany * Elaine Shi, UC Berkeley, USA * Claudio Silvestri, University Ca' Foscari of Venice, Italy * Claudio Soriente, Universidad Politecnica de Madrid, Spain * Thorsten Strufe, University of Mannheim, Germany * Allan Tomlinson, Royal Holloway, University of London, UK * Martin Werner, Ludwig-Maximilians-Universität München, Germany From shanna@juniper.net Sun Jan 29 17:11:32 2012 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 2A31A21F852C for ; Sun, 29 Jan 2012 17:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 XdFirEPIJEjB for ; Sun, 29 Jan 2012 17:11:31 -0800 (PST) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 1D77221F8526 for ; Sun, 29 Jan 2012 17:11:28 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKTyXuQDhzev5ntQZ3/UHLtL1Ci+OnOExc@postini.com; Sun, 29 Jan 2012 17:11:31 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 29 Jan 2012 17:11:26 -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; Sun, 29 Jan 2012 20:11:24 -0500 From: Stephen Hanna To: Paul Hoffman , IPsecme WG Date: Sun, 29 Jan 2012 20:11:22 -0500 Thread-Topic: [IPsec] NUDGE: Starting work on our new charter items Thread-Index: AczdE4V8AFTQmJEARwyCKM07++EOIAB1ewlA Message-ID: References: <8CAC2292-8A17-4B38-B2DC-D8A4FDB43CEB@vpnc.org> In-Reply-To: <8CAC2292-8A17-4B38-B2DC-D8A4FDB43CEB@vpnc.org> 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] NUDGE: Starting work on our new charter items 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, 30 Jan 2012 01:11:32 -0000 Paul, Sorry to be late in responding. I've been working with other Juniper folks to figure out which of us should volunteer to edit the P2P VPN problem statement. But never mind about that. I am willing to edit the P2P VPN problem statement document. I know that we need to have a draft promptly and get some serious discussion going on the email list before IETF 83. There are plenty of interesting questions related to requirements that we'll want to discuss on the list and in person at IETF 83. Praveen Sathyanarayan from Juniper has already committed to write an Informational RFC documenting our current solution. And I think it's premature to start work on the common solution before we've agreed on the problem statement or at least nailed down the main issues. Don't you agree? Thanks, Steve > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Paul Hoffman > Sent: Friday, January 27, 2012 11:49 AM > To: IPsecme WG > Subject: [IPsec] NUDGE: Starting work on our new charter items >=20 > [[ There has not been enough response yet, by far. ]] >=20 > We have a new charter. Do we have any volunteers to start work on the > two documents we committed to work on? >=20 > Related: we should consider having a face-to-face meeting at the > upcoming IETF in Paris, but only if there is value for the newly- > chartered work. In my mind, that means both a first draft submitted > *and* interesting questions that would benefit from face-to-face > discussion instead of just work on the list. Do people believe we will > have that? >=20 > --Paul Hoffman >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Mon Jan 30 04:20:09 2012 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 1D21621F85F3 for ; Mon, 30 Jan 2012 04:20:09 -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 jSPkQVDsxmVK for ; Mon, 30 Jan 2012 04:20:08 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 59F1F21F85D4 for ; Mon, 30 Jan 2012 04:20:08 -0800 (PST) Received: by wicr5 with SMTP id r5so3816136wic.31 for ; Mon, 30 Jan 2012 04:20:07 -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=DU+XDiG1VLWEWenjfiNl1vsGQxsDbohTC64stRI5sEo=; b=Db6JTLpnkqsqEc85lN9WVdJUTrrReTV0N3bkdWJthIUBRQdXheRy0RtXBcwHfW2Rh3 vdWkfeb16nH1Ox6v09y3nzc7LpIXinb1PgqitWCyyAEqnsbWp5bHNYuUj5BKgXu+o4Ec M8GOyAoRcMYDSsMkkbTlKV1nqhIuZV40/0LLE= Received: by 10.180.100.234 with SMTP id fb10mr26946126wib.8.1327926007545; Mon, 30 Jan 2012 04:20:07 -0800 (PST) Received: from [192.168.7.200] (93-173-33-113.bb.netvision.net.il. [93.173.33.113]) by mx.google.com with ESMTPS id l8sm51861763wiy.5.2012.01.30.04.20.05 (version=SSLv3 cipher=OTHER); Mon, 30 Jan 2012 04:20:06 -0800 (PST) Message-ID: <4F268AF4.3070703@gmail.com> Date: Mon, 30 Jan 2012 14:20:04 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Stephen Hanna References: <8CAC2292-8A17-4B38-B2DC-D8A4FDB43CEB@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] NUDGE: Starting work on our new charter items 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, 30 Jan 2012 12:20:09 -0000 I certainly agree. Yaron On 01/30/2012 03:11 AM, Stephen Hanna wrote: > Paul, > > Sorry to be late in responding. I've been working with other > Juniper folks to figure out which of us should volunteer to > edit the P2P VPN problem statement. But never mind about that. > > I am willing to edit the P2P VPN problem statement document. > I know that we need to have a draft promptly and get some serious > discussion going on the email list before IETF 83. There are > plenty of interesting questions related to requirements that > we'll want to discuss on the list and in person at IETF 83. > > Praveen Sathyanarayan from Juniper has already committed to > write an Informational RFC documenting our current solution. > And I think it's premature to start work on the common > solution before we've agreed on the problem statement or > at least nailed down the main issues. Don't you agree? > > Thanks, > > Steve > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Paul Hoffman >> Sent: Friday, January 27, 2012 11:49 AM >> To: IPsecme WG >> Subject: [IPsec] NUDGE: Starting work on our new charter items >> >> [[ There has not been enough response yet, by far. ]] >> >> We have a new charter. Do we have any volunteers to start work on the >> two documents we committed to work on? >> >> Related: we should consider having a face-to-face meeting at the >> upcoming IETF in Paris, but only if there is value for the newly- >> chartered work. In my mind, that means both a first draft submitted >> *and* interesting questions that would benefit from face-to-face >> discussion instead of just work on the list. Do people believe we will >> have that? >> >> --Paul Hoffman >> >> _______________________________________________ >> 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 kent@bbn.com Mon Jan 30 07:00:50 2012 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 37BC521F8716 for ; Mon, 30 Jan 2012 07:00:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.456 X-Spam-Level: X-Spam-Status: No, score=-106.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LYgn6adS0iSq for ; Mon, 30 Jan 2012 07:00:49 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id BB1E021F8715 for ; Mon, 30 Jan 2012 07:00:48 -0800 (PST) Received: from dhcp89-089-190.bbn.com ([128.89.89.190]:49176) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Rrsiq-000NgL-CR; Mon, 30 Jan 2012 10:00:44 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 30 Jan 2012 10:00:22 -0500 To: tso@zteusa.com From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-884186853==_ma============" Cc: ipsec@ietf.org, tso@zteusa.com, zong.zaifeng@zte.com.cn Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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, 30 Jan 2012 15:00:50 -0000 --============_-884186853==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 9:31 PM -0800 1/26/12, tso@zteusa.com wrote: >... > >Tricci > Fully agree with you that, we need to make a proposal to be >consistent with IETF standards. In addition, I am also hoping you >would agree that, as the solution is proposed to fix a generic issue >for Femto network, we need to also consider the impact of the final >solution towards the Femto's existing deployment as long as we did >not break IKE. Would this be acceptable to you? yes, so long as the proposed solution makes good use of existing IETF standards, or proposes new ones where existing standards are not applicable. >... > >Tricci > The reason that we choose the words "notarization" because >the design of this proposal is to have a trusted-party (i.e. SeGW) >of the target network (i.e. Mobile Core Network) to notarize the >untrusted-party (i.e. FAP) so that the untrusted-party can leverage >the trusted-party's notarized signature to be present to the target >network to gain its trust and confident on the identity of the >untrusted party as well as the info presented by the untrusted party >to the target network. This approach is very similar to today >notarization process in the legal process. There is an analogy to notarization in the legal sense, but in the technical context, the function performed by the SecGW is highly analogous to that of a CA or AA. >Tricci > However, if you truly feel strongly against this word, we >don't really have strong opinion on this one. We respect your >expertise to suggest the better wording for us. I think it is preferable to use terms that relate to existing, very relevant security technologies, when one makes a technical proposal such as this. > Tricci > One important aspect that I would like to clarify is that, >in our perspective, the info that is carried by the IKE is not >really an opaque. In our perspective, the info is just not defined >by IETF, but by the network/SDO which is responsible to utilize such >solution to define the content of the info. If you think that it >is necessary, we can add the note to the draft to specify that, >whichever the network solution or SDO that chooses to use this >solution must indicate what are the info which will be conveyed >between the two IKE peers in advance. For example, if 3GPP decides >to use this IKE feature as described in this draft to mitigate the >FAP security issue, 3GPP should specify what and how the info is >carried by the CP. If different technologies carry different data in the same IKE payload, that is questionable. The content of a payload should be evident from the payload ID. And the content should be defined in an IETF doc, if it is not vendor-specific. > ... > >Tricci > It is important to point out that, the SeGW does NOT pass >on the CP info to the Mobile core network. What was described in >the draft is that: >Tricci > (1) FAP (i.e. IKE-initiator) includes the "Client Notarized >Info" in the CP-Request during the mutual authentication exchange to >SeGW (i.e. IKE-Responder) the SecGW sends the signed data to the FAP, which passes it to the core network. So the SecGW is passing the data to the core network via the FAP. I was not clear in my comment. >Tricci > (2) Once the SeGW authenticates the FAP (i.e. successful >authentication), the SeGW will then notarize the info to derive >"Server Notarized Signature" (algorithm is determined by network >operator or standard SDO) which will then be included in the >CP-Reply to the FAP. again, this seems to be a case where the full spec of what is being carried by IKE should be defined in RFCs. Using IKE to transport arbitrary data, specified by other SDOs, is questionable. >Tricci > (3) FAP will then include this Server Notarized Signature >info in its own control signaling communication with the mobile core >network which deploys the SeGW. The FAP's signaling contains the >SeGW's Notarized Signature and they are encapsulated within the >IPsec tunnel. Hence, SeGW is NOT involved in passing the CP's info >to the Mobile Core Network. see my reply above. > >... > >Tricci > If I understand your proposal correctly, you suggested to >have the SeGW to generate the additional cert to be used by the FAP >to present to the target network, isn't it? >Tricci > Unfortunately, this approach does not address the issue >that we are trying to resolve. First of all, both FAP and SeGW >already have their own certs to support their mutual authentication. > Secondly, the new cert that you proposed will not contain the >"specific" info that we require for the SeGW to certify/notarize for >the FAP such that the FAP can present the certified/notarized info >to the target mobile core network. how can you say that a new cert, the content of which I did not describe, will not contain the "specific info" required? the intent of having the SecGW generate a cert for the FAP is to put the appropriate info into it. >Tricci > In summary, what we are trying to achieve is to have the >SeGW, which is the trusted party of the Mobile Core network, to >certify/notarize the "specific" configuration and access control >info provided by the FAP to be notarized by the SeGW. This is how >the Mobile Core network to verify the FAP's true identity and the >associated info provided by the FAP is trust-worthy. Perhaps I don't understand the term "specific" here. The SecGW must understand the data provided by the FAP, otherwise it cannot verify and sign it. Can you provide example of the data that is to be signed, for 3GPP and LTE? Maybe that would help. >Tricci > As for your last sentence above saying "That way the SecGW >would not have to pass on data to the core network.". Again, please >note that SeGW does NOT explicitly pass the CP info to the Mobile >Core Network, it is the FAP to include the notarized signature in >its signaling which is part of the IPsec payload to be sent to the >Mobile Core network. Yes, I understand. >... > >Tricci > I hope that you can understand that what you described >above is NOT what we proposed. Thank you for your comments. I understand that you propose using a single IKE payload to transport arbitrary data, data that will differ based on network context, and that the IKE entities at the SecGW and the FAP are NOT the consumers of this info. That seems like a bad use of IKE. Steve --============_-884186853==_ma============ Content-Type: text/html; charset="us-ascii" Re: [IPsec] [IPSec]: New Version Notification for draft-zo
At 9:31 PM -0800 1/26/12, tso@zteusa.com wrote:
...

Tricci > Fully agree with you that, we need to make a proposal to be consistent with IETF standards.  In addition, I am also hoping you would agree that, as the solution is proposed to fix a generic issue for Femto network, we need to also consider the impact of the final solution towards the Femto's existing deployment as long as we did not break IKE.  Would this be acceptable to you?  

yes, so long as the proposed solution makes good use of existing IETF standards,
or proposes new ones where existing standards are not applicable.

...

Tricci > The reason that we choose the words "notarization" because the design of this proposal is to have a trusted-party (i.e. SeGW) of the target network (i.e. Mobile Core Network) to notarize the untrusted-party (i.e. FAP) so that the untrusted-party can leverage the trusted-party's notarized signature to be present to the target network to gain its trust and confident on the identity of the untrusted party as well as the info presented by the untrusted party to the target network. This approach is very similar to today notarization process in the legal process.  

There is an analogy to notarization in the legal sense, but in the technical context, the function performed by the SecGW is highly analogous to that of a CA or AA.

Tricci > However, if you truly feel strongly against this word, we don't really have strong opinion on this one.  We respect your expertise to suggest the better wording for us.

I think it is preferable to use terms that relate to existing, very relevant security technologies, when one makes a technical proposal such as this.

 Tricci > One important aspect that I would like to clarify is that, in our perspective, the info that is carried by the IKE is not really an opaque.  In our perspective, the info is just not defined by IETF, but by the network/SDO which is responsible to utilize such solution to define the content of the info.   If you think that it is necessary, we can add the note to the draft to specify that, whichever the network solution or SDO that chooses to use this solution must indicate what are the info which will be conveyed between the two IKE peers in advance.  For example, if 3GPP decides to use this IKE feature as described in this draft to mitigate the FAP security issue,  3GPP should specify what and how the info is carried by the CP.    

If different technologies carry different data in the same IKE payload, that
is questionable. The content of a payload should be evident from the payload ID. And the content should be defined in an IETF doc, if it is not vendor-specific.

 ...

Tricci > It is important to point out that, the SeGW does NOT pass on the CP info to the Mobile core network.  What was described in the draft is that:
Tricci > (1) FAP (i.e. IKE-initiator) includes the "Client Notarized Info" in the CP-Request during the mutual authentication exchange to SeGW (i.e. IKE-Responder)

the SecGW sends the signed data to the FAP, which passes it to the core network. So the SecGW is passing the data to the core network via the FAP. I was not clear in my comment.

Tricci > (2) Once the SeGW authenticates the FAP (i.e. successful authentication), the SeGW will then notarize the info to derive "Server Notarized Signature" (algorithm is determined by network operator or standard SDO) which will then be included in the CP-Reply to the FAP.  

again, this seems to be a case where the full spec of what is being carried by IKE should be defined in RFCs. Using IKE to transport arbitrary data, specified by other SDOs, is questionable.

Tricci > (3) FAP will then include this Server Notarized Signature info in its own control signaling communication with the mobile core network which deploys the SeGW.  The FAP's signaling contains the SeGW's Notarized Signature and they are encapsulated within the IPsec tunnel.  Hence, SeGW is NOT involved in passing the CP's info to the Mobile Core Network.

see my reply above.


...

Tricci > If I understand your proposal correctly, you suggested to have the SeGW to generate the additional cert to be used by the FAP to present to the target network, isn't it?  
Tricci > Unfortunately, this approach does not address the issue that we are trying to resolve.  First of all, both FAP and SeGW already have their own certs to support their mutual authentication.  Secondly, the new cert that you proposed will not contain the "specific" info that we require for the SeGW to certify/notarize for the FAP such that the FAP can present the certified/notarized info to the target mobile core network.

how can you say that a new cert, the content of which I did not describe, will not contain the "specific info" required? the intent of having the SecGW generate a cert for the FAP is to put the appropriate info into it.

Tricci > In summary, what we are trying to achieve is to have the SeGW, which is the trusted party of the Mobile Core network, to certify/notarize the "specific" configuration and access control info provided by the FAP to be notarized by the SeGW.  This is how the Mobile Core network to verify the FAP's true identity and the associated info provided by the FAP is trust-worthy.  

Perhaps I don't understand the term "specific" here. The SecGW must understand the data provided by the FAP, otherwise it cannot verify and sign it. Can you provide example of the data that is to be signed, for 3GPP and LTE? Maybe that would help.

Tricci > As for your last sentence above saying "That way the SecGW would not have to pass on data to the core network.".  Again, please note that SeGW does NOT explicitly pass the CP info to the Mobile Core Network, it is the FAP to include the notarized signature in its signaling which is part of the IPsec payload to be sent to the Mobile Core network.

Yes, I understand.

...

Tricci > I hope that you can understand that what you described above is NOT what we proposed.  Thank you for your comments.

I understand that you propose using a single IKE payload to transport arbitrary data, data that will differ based on network context, and that the IKE entities at the SecGW and the FAP are NOT the consumers of this info. That seems like a bad use of IKE.

Steve
--============_-884186853==_ma============-- From paul.hoffman@vpnc.org Mon Jan 30 07:59:34 2012 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 2AC7021F865E for ; Mon, 30 Jan 2012 07:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 TaJfHKFMX+rX for ; Mon, 30 Jan 2012 07:59:33 -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 9439621F8572 for ; Mon, 30 Jan 2012 07:59:33 -0800 (PST) Received: from [10.20.30.103] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q0UFxWQq091213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 30 Jan 2012 08:59:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 30 Jan 2012 07:59:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8CAC2292-8A17-4B38-B2DC-D8A4FDB43CEB@vpnc.org> To: Stephen Hanna X-Mailer: Apple Mail (2.1251.1) Cc: IPsecme WG Subject: Re: [IPsec] NUDGE: Starting work on our new charter items 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, 30 Jan 2012 15:59:34 -0000 On Jan 29, 2012, at 5:11 PM, Stephen Hanna wrote: > Sorry to be late in responding. I've been working with other > Juniper folks to figure out which of us should volunteer to > edit the P2P VPN problem statement. But never mind about that. >=20 > I am willing to edit the P2P VPN problem statement document. > I know that we need to have a draft promptly and get some serious > discussion going on the email list before IETF 83. There are > plenty of interesting questions related to requirements that > we'll want to discuss on the list and in person at IETF 83. >=20 > Praveen Sathyanarayan from Juniper has already committed to > write an Informational RFC documenting our current solution. > And I think it's premature to start work on the common > solution before we've agreed on the problem statement or > at least nailed down the main issues. Don't you agree? Indeed. But we need to be sure there is enough interest in even nailing = down the main issues. So, thank you for your willingness to edit the = problem statement: that gets it going. How many people here will commit publicly to review drafts of the = problem statement and contribute ideas such as "this should be a = requirement" and "that thing there should not be a requirement"? --Paul Hoffman From kent@bbn.com Mon Jan 30 13:59:32 2012 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 BCCDC11E80BA; Mon, 30 Jan 2012 13:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.508 X-Spam-Level: X-Spam-Status: No, score=-106.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 lXwbJOyULTPO; Mon, 30 Jan 2012 13:59:32 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4224F11E80B5; Mon, 30 Jan 2012 13:59:32 -0800 (PST) Received: from dhcp89-089-190.bbn.com ([128.89.89.190]:49203) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1RrzG0-000JE2-Sr; Mon, 30 Jan 2012 16:59:25 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 30 Jan 2012 16:59:21 -0500 To: zong.zaifeng@zte.com.cn From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: ipsec@ietf.org, tso@zteusa.com, ipsec-bounces@ietf.org Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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, 30 Jan 2012 21:59:32 -0000 At 4:39 PM +0800 1/29/12, zong.zaifeng@zte.com.cn wrote: >Hi Stephen, Tricci: > >Sorry that I didn't respond this email on time due to the chinese >spring festival. I would like to thank Stephen first for reviewing >the draft and giving me your suggestions. no problem. Happy New Year. >From reading Stephen's email, if my understanding is correct, you >assumed that SeGW will pass some information to the core network in >order that the core network can verify the "notarized" FAP >information? And you think that the information exchange betwen SeGW >and the core network is a big change to IKE, is this correct >understanding of your email? not quite. I was wrong to suggest that the SecGW sent the signed data directly to the core network. The data that the SecGW signs is presented by the FAP to the core network. My principle concern is that it is inappropriate to use an IKE payload to transport data to be signed, and then the signed data, when the consumer of this data is not IPsec. IKE payloads are used to convey data needed to create and manage SAs, including key material, data for authentication, etc. This signed data appears to be for authorization decisions effected by some element of the core network, outside of the IPsec SA itself. >I understand that this configuration based assumption may have some >limits, I think that to generate a cert by the SeGW and send it to >the FAP and then from the FAP to the core network is a good >implementation option. Perhaps I should make the CP flexible enough >to adapt to all the implementation options. If you have any good >idea on how the CP should be designed, could you kindly give me your >suggestion? I don't want to suggest design options for you, as I am not familiar with the environment in which you are working. Also, lots of flexibility may not be a good ideas in a secruity context. I'm merely suggesting that using IKE payloads seems inappropriate for what I believe you are trying to do, based on reading one very brief document. Steve From dharmanandana.pothulam@huawei.com Tue Jan 31 02:43:47 2012 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 A7C9A21F8664; Tue, 31 Jan 2012 02:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.923 X-Spam-Level: X-Spam-Status: No, score=-5.923 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 OHb60sw7NFsV; Tue, 31 Jan 2012 02:43:46 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3F121F8669; Tue, 31 Jan 2012 02:43:45 -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 <0LYN008OJSGKG6@szxga04-in.huawei.com>; Tue, 31 Jan 2012 18:43:33 +0800 (CST) Received: from szxrg02-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 <0LYN00BC4SGK33@szxga04-in.huawei.com>; Tue, 31 Jan 2012 18:43:32 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGQ89815; Tue, 31 Jan 2012 18:43:32 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jan 2012 18:43:27 +0800 Received: from blrprnc06ns (10.18.96.95) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server id 14.1.323.3; Tue, 31 Jan 2012 18:43:24 +0800 Date: Tue, 31 Jan 2012 16:13:22 +0530 From: Dharmanandana Reddy Pothula In-reply-to: X-Originating-IP: [10.18.96.95] To: tso@zteusa.com Message-id: <000001cce005$2833bf40$789b3dc0$%pothulam@huawei.com> Organization: HTIPL MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_O1cCSBk27N/2Ce1p2/vlRw)" Content-language: en-us Thread-index: AczbNyse63T7/8FtQMK8pef+WFlTVAEwDB7Q X-CFilter-Loop: Reflected References: Cc: ipsec@ietf.org, ipsec-bounces@ietf.org, zong.zaifeng@zte.com.cn Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dharmanandana.pothulam@huawei.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 10:43:47 -0000 --Boundary_(ID_O1cCSBk27N/2Ce1p2/vlRw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Tricci, Thanks for your explanation. I get your point why notarized signature required, but my question is not about notarizing every packet. Let me ask my question in different way, Is FAP sends notarized signature in every IPSec packet to core network? As I understand from the draft that before accepting every IPSec packet, core network validate the notarized signature. Where is this notarized signature placed in every IPSec packet? Thanks, Dharmanandana Reddy Pothula From: tso@zteusa.com [mailto:tso@zteusa.com] Sent: Wednesday, January 25, 2012 1:26 PM To: dharmanandana.pothulam@huawei.com Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; zong.zaifeng@zte.com.cn; tso@zteusa.com Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt Dear Dharmanandana, I hope that I address you correctly. If not, please pardon my ignorance. As this week is spring festival, ZaiFeng is not available. Hence, I would like to respond to you on behalf of her. Could you please kind see my responses to you inline below. Many thanks. Tricci Dharmanandana Reddy Sent by: ipsec-bounces@ietf.org 01/24/2012 04:04 AM Please respond to dharmanandana.pothulam@huawei.com To zong.zaifeng@zte.com.cn cc ipsec@ietf.org Subject Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt Hi Zaifeng, I have following questions and concerns about your proposed solution "The FAP will then send the FAP information together with the corresponding SeGW notarized signature to its mobile operator's core network. The core network verifies the FAP information by validating the SeGW notarized signature prior to the acceptance of the information". Is every ip packet carries SeGW notarized signature after server sends notarized signature to the client? if not, what's the point in returning notarized signature to the client? I believe yes, if so, It will increase percentage of overhead per packet and may impact quality of real time voice and video. Tricci > You ask a very legitimate question. May be our draft is not clear enough to explain the main motivation of this draft for target of the attack. Tricci > The main concern is not about the attack for "unauthorized FAP" to send any data to the mobile core network. The main concern is about the attack of the "unauthorized FAP" to send the "false" configuration information (e.g. such as changing the FAP from "Closed" to become "Open"), and to send the "false" access control related information (e.g. allowing a 3GPP UE which is supposed to be allowed to access the FAP and to have the access privileage to the FAP - i.e. CSG info alteration, etc.). Once the FAP's configuration and access control management are authenticated via the support of the notarization by the SeGW, then, the rest of the 3GPP UEs' access to the FAP can follow the existing access control and UE-based authentication/authorization procedures at the UE level's. Tricci > Of course, once the UE is authenticated and to allow access to the FAP, whatever the UE sends is beyond the control of the FAP just as what is happened today for any mobile device. Isn't it? if every ip packet carries SeGW notarized signature, How and where this signature carried inside ip packet? will it bring some modifications inside IPsec packet processing? Is this processing happens outside of IPsec? is it outside scope of this document? It would be great, if some of these aspects are addressed in the draft. Tricci > Since I have already explained to you that, we are not proposing to notarize every single packet sent by FAP. Hence, I don't think that I need to respond to your rest of the questions above. Tricci > THANK YOU for asking a good question. Cheers. Thanks, Dharmanandana Reddy Pothula. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --Boundary_(ID_O1cCSBk27N/2Ce1p2/vlRw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Tricci,

 

Thanks for your explanation. I get your point why notarized signature required, but my question is not about notarizing every packet. Let me ask my question in different way, Is FAP sends notarized signature in every IPSec packet to core network? As I understand from the draft that before accepting every IPSec packet, core network validate the notarized signature. Where is this notarized signature placed in every IPSec packet?

Thanks,

Dharmanandana Reddy Pothula

 

From: tso@zteusa.com [mailto:tso@zteusa.com]
Sent: Wednesday, January 25, 2012 1:26 PM
To: dharmanandana.pothulam@huawei.com
Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; zong.zaifeng@zte.com.cn; tso@zteusa.com
Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipse cme-ikev

 

Dear Dharmanandana,

I hope that I address you correctly.  If not, please pardon my ignorance.

As this week is spring festival, ZaiFeng is not available.  Hence, I would like to respond to you on behalf of her.  

Could you please kind see my responses to you inline below.  Many thanks.
Tricci



5pt;font-family:"Arial","sans-serif"'>Dharmanandana Reddy <dharmanandana.pothulam@huawei.com>
Sent by: ipsec-bounces@ietf.org

01/24/2012 04:04 AM

Please respond to
dharmanandana.pothulam@huawei.com

To

zong.zaifeng@zte.com.cn

cc

ipsec@ietf.org

Subject

Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt

 




Hi Zaifeng,
 
I have following questions and concerns about your proposed solution "The FAP will then send the FAP information together with the corresponding SeGW notarized signature to its mobile operator's core network. The core network verifies the FAP information by validating the SeGW notarized signature prior to the acceptance of the information".
Is every ip packet carries SeGW notarized signature after server sends notarized signature to the client? if not, what's the point in returning notarized signature to the client? I believe yes, if so, It will increase percentage of overhead per packet and may impact quality of real time voice and video.

Tricci > You ask a very legitimate question.  May be our draft is not clear enough to explain the main motivation of this draft for target of the attack.  

Tricci > The main concern is not about the attack for "unauthorized FAP" to send any data to the mobile core network.  The main concern is about the attack of the "unauthorized FAP" to send the "false" configuration information (e.g. such as changing the FAP from "Closed" to become "O pen" ;false" access control related information (e.g. allowing a 3GPP UE which is supposed to be allowed to access the FAP and to have the access privileage to the FAP - i.e. CSG info alteration, etc.).  Once the FAP's configuration and access control management are authenticated via the support of the notarization by the SeGW, then, the rest of the 3GPP UEs' access to the FAP can follow the existing access control and UE-based authentication/authorization procedures at the UE level's.  

Tricci > Of course, once the UE is authenticated and to allow access to the FAP, whatever the UE sends is beyond the control of the FAP just as what is happened today for any mobile device.  Isn't it?  
 
if every ip packet carries SeGW notarized signature, How and where this signature carried inside ip packet? cations inside IPsec packet processing? Is this processing happens outside of IPsec? is it outside scope of this document? It would be great, if some of these aspects are addressed in the draft.
 
Tricci > Since I have already explained to you that, we are not proposing to notarize every single packet sent by FAP.  Hence, I don't think that I need to respond to your rest of the questions above.  

Tricci > THANK YOU for asking a good question.  Cheers.

Thanks,
 
Dharmanandana Reddy Pothula.
 
& yle='font-size:10.0pt;font-family:"Arial","sans-serif"'> 
 _______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. R
 ecipient
bsp;are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--Boundary_(ID_O1cCSBk27N/2Ce1p2/vlRw)-- From Chris.Ulliott@cesg.gsi.gov.uk Tue Jan 31 04:12:23 2012 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 3490B21F8486 for ; Tue, 31 Jan 2012 04:12:23 -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 tL8OomCNmJJh for ; Tue, 31 Jan 2012 04:12:22 -0800 (PST) Received: from mail89.messagelabs.com (mail89.messagelabs.com [194.106.220.3]) by ietfa.amsl.com (Postfix) with SMTP id 48B7E21F8474 for ; Tue, 31 Jan 2012 04:12:21 -0800 (PST) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-4.tower-89.messagelabs.com!1328011940!48015833!1 X-Originating-IP: [195.92.40.48] X-StarScan-Version: 6.4.3; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 634 invoked from network); 31 Jan 2012 12:12:20 -0000 Received: from gateway-201.energis.gsi.gov.uk (HELO mx.hosting-e.gsi.gov.uk) (195.92.40.48) by server-4.tower-89.messagelabs.com with SMTP; 31 Jan 2012 12:12:20 -0000 From: "Ulliott, Chris" To: 'Paul Hoffman' , IPsecme WG Date: Tue, 31 Jan 2012 12:11:05 +0000 Thread-Topic: [IPsec] NUDGE: Starting work on our new charter items Thread-Index: AczfSCoRuQhkKJ5jTNa3gxtTE0b+xQAyLBlw Message-ID: <20549DD10769DA47A86F0F0FAF8012DD031BF75CC0@PIACHEVEX00.GCHQ.GOV.UK> In-Reply-To: <8CAC2292-8A17-4B38-B2DC-D8A4FDB43CEB@vpnc.org> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] NUDGE: Starting work on our new charter items 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, 31 Jan 2012 12:12:23 -0000 Paul - count me in, am more than happy to contribute and help review draft= s. Unfortunately getting to Paris could be challenging, but I'll go and t= alk nicely to the folk who control the purse strings! Chris -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Paul Hoffman Sent: Friday, January 27, 2012 4:49 PM To: IPsecme WG Subject: [IPsec] NUDGE: Starting work on our new charter items [[ There has not been enough response yet, by far. ]] We have a new charter. Do we have any volunteers to start work on the two = documents we committed to work on? Related: we should consider having a face-to-face meeting at the upcoming = IETF in Paris, but only if there is value for the newly-chartered work. In= my mind, that means both a first draft submitted *and* interesting questi= ons that would benefit from face-to-face discussion instead of just work o= n the list. Do people believe we will have that? --Paul Hoffman _______________________________________________ IPsec=20mailing 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 weiyinxing@gmail.com Tue Jan 31 16:59:02 2012 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 91ABD21F8547; Tue, 31 Jan 2012 16:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.348 X-Spam-Level: * X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396, 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 faYnWn-mpko2; Tue, 31 Jan 2012 16:59:01 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 76DC121F8543; Tue, 31 Jan 2012 16:59:01 -0800 (PST) Received: by pbdy7 with SMTP id y7so748683pbd.31 for ; Tue, 31 Jan 2012 16:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=JWh/CvNmR+DT6AMmAtBj9i4CbHf4ttWQ4LcBvtceL14=; b=tVChcFT6CtkkhOGGEVDOS1vVH+/8iMmc51BokJ99aHS+0MkeY44witkpZp0otVQ1T9 LI8ze+AQGi6Zq4TOO/SZH15gSCisJR8ebWCJyP2FkPYpid5rbP5gRDOmBZbK+VA2gXpn kVVHq7VpnvgrHTyg/w6Oz6VLrADy1C0DqGCtE= Received: by 10.68.73.4 with SMTP id h4mr54878605pbv.27.1328057941248; Tue, 31 Jan 2012 16:59:01 -0800 (PST) Received: from [172.25.129.39] ([122.194.2.20]) by mx.google.com with ESMTPS id o7sm59516894pbq.8.2012.01.31.16.58.54 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jan 2012 16:58:59 -0800 (PST) References: <000001cce005$2833bf40$789b3dc0$%pothulam@huawei.com> In-Reply-To: <000001cce005$2833bf40$789b3dc0$%pothulam@huawei.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-88B99B20-436E-4367-8749-64437798D242 Message-Id: X-Mailer: iPad Mail (9A405) From: Yinxing Wei Date: Wed, 1 Feb 2012 09:01:14 +0800 To: "dharmanandana.pothulam@huawei.com" Cc: "ipsec@ietf.org" , "tso@zteusa.com" , "zong.zaifeng@zte.com.cn" , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2-cpext4femto-00.txt 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, 01 Feb 2012 00:59:02 -0000 --Apple-Mail-88B99B20-436E-4367-8749-64437798D242 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=GB2312 Hi, My understanding is that the notarized signature is carried by IKE. Aft= er IKE's procedure is done, the following packet can be protected by IPsec(e.g. ESP). ---------------- Yinxing Wei =D4=DA 2012-1-31=A3=AC=CF=C2=CE=E76:43=A3=ACDharmanandana Reddy Pothula =D0=B4=B5=C0=A3=BA > Hi Tricci, > =20 > Thanks for your explanation. I get your point why notarized signature requ= ired, but my question is not about notarizing every packet. Let me ask my qu= estion in different way, Is FAP sends notarized signature in every IPSec pac= ket to core network? As I understand from the draft that before accepting ev= ery IPSec packet, core network validate the notarized signature. Where is th= is notarized signature placed in every IPSec packet? > Thanks, > Dharmanandana Reddy Pothula > =20 > From: tso@zteusa.com [mailto:tso@zteusa.com]=20 > Sent: Wednesday, January 25, 2012 1:26 PM > To: dharmanandana.pothulam@huawei.com > Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; zong.zaifeng@zte.com.cn; tso@z= teusa.com > Subject: Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipse= cme-ikev > =20 > Dear Dharmanandana,=20 >=20 > I hope that I address you correctly. If not, please pardon my ignorance.=20= >=20 > As this week is spring festival, ZaiFeng is not available. Hence, I would= like to respond to you on behalf of her. =20 >=20 > Could you please kind see my responses to you inline below. Many thanks.=20= > Tricci=20 >=20 >=20 >=20 >=20 > 5pt;font-family:"Arial","sans-serif"'>Dharmanandana Reddy =20 > Sent by: ipsec-bounces@ietf.org >=20 > 01/24/2012 04:04 AM >=20 > Please respond to > dharmanandana.pothulam@huawei.com > To >=20 > zong.zaifeng@zte.com.cn > cc > ipsec@ietf.org > Subject > Re: [IPsec] [IPSec]: New Version Notification for draft-zong-ipsecme-ikev2= -cpext4femto-00.txt > =20 >=20 >=20 >=20 > Hi Zaifeng,=20 > =20 > I have following questions and concerns about your proposed solution "The = FAP will then send the FAP information together with the corresponding SeGW n= otarized signature to its mobile operator's core network. The core network v= erifies the FAP information by validating the SeGW notarized signature prior= to the acceptance of the information".=20 > Is every ip packet carries SeGW notarized signature after server sends not= arized signature to the client? if not, what's the point in returning notari= zed signature to the client? I believe yes, if so, It will increase percenta= ge of overhead per packet and may impact quality of real time voice and vide= o.=20 >=20 > Tricci > You ask a very legitimate question. May be our draft is not clea= r enough to explain the main motivation of this draft for target of the atta= ck. =20 >=20 > Tricci > The main concern is not about the attack for "unauthorized FAP" t= o send any data to the mobile core network. The main concern is about the a= ttack of the "unauthorized FAP" to send the "false" configuration informatio= n (e.g. such as changing the FAP from "Closed" to become "O pen" ;false" acc= ess control related information (e.g. allowing a 3GPP UE which is supposed t= o be allowed to access the FAP and to have the access privileage to the FAP -= i.e. CSG info alteration, etc.). Once the FAP's configuration and access c= ontrol management are authenticated via the support of the notarization by t= he SeGW, then, the rest of the 3GPP UEs' access to the FAP can follow the ex= isting access control and UE-based authentication/authorization procedures a= t the UE level's. =20 >=20 > Tricci > Of course, once the UE is authenticated and to allow access to th= e FAP, whatever the UE sends is beyond the control of the FAP just as what i= s happened today for any mobile device. Isn't it? =20 > =20 > if every ip packet carries SeGW notarized signature, How and where this si= gnature carried inside ip packet? cations inside IPsec packet processing? Is= this processing happens outside of IPsec? is it outside scope of this docum= ent? It would be great, if some of these aspects are addressed in the draft.= =20 > =20 > Tricci > Since I have already explained to you that, we are not proposing t= o notarize every single packet sent by FAP. Hence, I don't think that I nee= d to respond to your rest of the questions above. =20 >=20 > Tricci > THANK YOU for asking a good question. Cheers.=20 >=20 > Thanks,=20 > =20 > Dharmanandana Reddy Pothula.=20 > =20 > & yle=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'> =20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 > =20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is= solely property of the sender's organization. This mail communication is co= nfidential. R > ecipient > bsp;are obligated to maintain secrecy and are not permitted to disclose th= e contents of this communication to others. > This email and any files transmitted with it are confidential and intended= solely for the use of the individual or entity to whom they are addressed. I= f you have received this email in error please notify the originator of the m= essage. Any views expressed in this message are those of the individual send= er. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system= . > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-88B99B20-436E-4367-8749-64437798D242 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,
   = ;  My understanding is that the notarized signature is carried by IKE. A= fter IKE's procedure is done,
the following packet can be protec= ted by IPsec(e.g. ESP).

----------------
Yinxing We= i

=E5=9C=A8 2012-1-31=EF=BC=8C=E4=B8=8B=E5=8D=886:43=EF=BC= =8CDharmanandana Reddy Pothula <dharmanandana.pothulam@huawei.com> =E5=86=99=E9=81=93=EF=BC= =9A

Hi Tricci,

 

Thanks for your explanation. I get you= r point why notarized signature required, but my question is not about notar= izing every packet. Let me ask my question in different way, Is FAP sends no= tarized signature in every IPSec packet to core network? As I understand fro= m the draft that before accepting every IPSec packet, core network validate t= he notarized signature. Where is this notarized signature placed in every IP= Sec packet?

Thanks,

Dharmanandana Reddy Pothula

=  

From: tso@zteusa.com [mailto:tso@zteusa.com]
Sent: Wednesd= ay, January 25, 2012 1:26 PM
To: dharmanandana.pothulam@huawei.com
Cc: ipsec@ietf.org; ipsec-bounces@ietf.org; zong.zaifeng@zte.com.cn; ts= o@zteusa.com
Subject: Re: [IPsec] [IPSec]: New Version Notific= ation for draft-zong-ipse cme-ikev

 

Dear Dharmanandana,
I hope that I address you correctly.  If not, please pardon my ig= norance.

As this week is spring festival, ZaiFeng is not a= vailable.  Hence, I would like to respond to you on behalf of her. &nbs= p;

Could you please kind see my responses to you inline b= elow.  Many thanks.
Tricci



<= /o:p>

<= /table>




Hi Zaifeng,
 
I have following questions and con= cerns about your proposed solution "The FAP will then send the FAP informati= on together with the corresponding SeGW notarized signature to its mobile op= erator's core network. The core network verifies the FAP information by vali= dating the SeGW notarized signature prior to the acceptance of the informati= on".
Is every ip packet carries SeGW notarized signature after server sends= notarized signature to the client? if not, what's the point in returning no= tarized signature to the client? I believe yes, if so, It will increase perc= entage of overhead per packet and may impact quality of real time voice and v= ideo.

Tricci > You ask a very legitimate question.  May be our draft i= s not clear enough to explain the main motivation of this draft for target o= f the attack.  

Tricci > The main concern is not about the attack for "= unauthorized FAP" to send any data to the mobile core network.  The mai= n concern is about the attack of the "unauthorized FAP" to send the "false" c= onfiguration information (e.g. such as changing the FAP from "Closed" to bec= ome "O pen" ;false" access control related information (e.g. allowing a 3GPP UE which is= supposed to be allowed to access the FAP and to have the access privileage t= o the FAP - i.e. CSG info alteration, etc.).  Once the FAP's configurat= ion and access control management are authenticated via the support of the n= otarization by the SeGW, then, the rest of the 3GPP UEs' access to the FAP c= an follow the existing access control and UE-based authentication/authorizat= ion procedures at the UE level's.  

Tricci > Of course, once the UE is= authenticated and to allow access to the FAP, whatever the UE sends is beyo= nd the control of the FAP just as what is happened today for any mobile devi= ce.  Isn't it?  
 
if every ip packet carries SeGW notarized signature, How and where t= his signature carried inside ip=20 packet?=20 cations inside IPsec packet processing? Is this processing happens outside o= f IPsec? is it outside scope of this document? It would be great, if some of= these aspects are addressed in the draft.
 
Tricci > Since I have already explained to= you that, we are not proposing to notarize every single packet sent by FAP.=  Hence, I don't think that I need to respond to your rest of the quest= ions above.  

Tricci > THANK YOU for asking a good question.  Che= ers.

Than= ks,
 
Dharmanandana R= eddy Pothula.
 
& yle=3D'font-size:10.0pt;font-family:"Arial","sans-serif"'>  <= br> _____________= __________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

 
---------------------------=
-----------------------------
ZTE Information =
;Security Notice: The information contained in =
;this mail is solely property of the send=
er's organization. This mail communication is =
confidential. R
 ecipient
bsp;are obligated to maintain secrecy and are&=
nbsp;not permitted to disclose the contents of=
 this communication to others.
This=
 email and any files transmitted with it&=
nbsp;are confidential and intended solely for =
the use of the individual or entity to&nb=
sp;whom they are addressed. If you have r=
eceived this email in error please notify =
;the originator of the message. Any views =
;expressed in this message are those of t=
he individual sender.
This message =
has been scanned for viruses and Spam by&=
nbsp;ZTE Anti-Spam system.
____________________= ___________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mai= lman/listinfo/ipsec
= --Apple-Mail-88B99B20-436E-4367-8749-64437798D242--

5pt;font-family:"Arial","sans-serif"'>Dharmanandana Reddy <dharmanandana.pothulam@huawei.com<= /a>>
Sent by: ipsec-bounces@ietf.org

01/24/2012 04:04 AM

Please respond to
dharmanandana.pothulam@huawei.com<= /a>

To=

zong.zaifeng@zte.com.cn

cc

<= /td>

ipsec@ietf.org

Subject

Re: [IPsec] [IPSec]: New Version Notification for d= raft-zong-ipsecme-ikev2-cpext4femto-00.txt