From paul.hoffman@vpnc.org Sun Apr 1 17:21: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 B2C3811E8085 for ; Sun, 1 Apr 2012 17:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 4MBG7KNZdg9W for ; Sun, 1 Apr 2012 17:21:11 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7D95F11E80A3 for ; Sun, 1 Apr 2012 17:21:10 -0700 (PDT) Received: from [10.20.30.101] (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 q320L6uG040751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 1 Apr 2012 17:21:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 1 Apr 2012 17:21:05 -0700 Message-Id: To: IPsecme WG Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [IPsec] Proposed minutes from last week 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 Apr 2012 00:21:12 -0000 Let me know if you think I got anything wrong. If you were one of the = people whose names I missed, by all means let me know. If you want to = discuss anything that was said, do *not* reply to this message, but use = a new thread. --Paul Hoffman IPsecME WG IETF 83, Paris Monday, March 26, 2012 Minutes taken by Paul Hoffman Text from the slides is not reproduced here See = https://datatracker.ietf.org/meeting/83/materials.html#wg-ipsecme Agenda was bashed, no additional issues WG status Last IETF was just an informal meeting One current doc: P2P VPN use cases and requirements doc We know that protocols are already out there, but that doesn't = matter now P2P VPN problem statement doc Steve Hanna draft-ietf-ipsecme-p2p-vpn-problem-00 Need a new name for the protocol Current draft is use cases only, will get to requirements soon # 210 Postponed until after we have all the requirements # 211 Add some new text about why this is difficult Will know more when we do the requirements # 212 Give examples of why gateway-to-gateway might be useful Two branch offices, videoconferencing Paul Hoffman: this is why we postponed 210 People were thinking that the topic was only = individual-to-individual Naming issue started restricting what we were = talking about # 213 Need to mention challenges in use cases section Paul: reminded that there will be a separate requirement = section # 214 Core gateway configuring is a solution, so premature Also in #213 # 215 Should be a requirement Michael Richardson: must be a requirement We don't have all the tunnels pre-configured, so = we need to deal with flowing traffic You can't pre-configure because of capacity = issues on the gateway Steve: does this need to be a use case because it is so = fundamental? David Black: VoIP isn't the only traffic on the Internet Is OK with dropping a packet sometimes Tero Kivinen: This will be needed after you notice that = you need it, when packets are flowing Steve: Mention in use cases that packet loss is highly = undesirable, but add it more in the requirements Brian Weiss: Nervous about talking too much about voice (?): Not saying that no packets should be lost, but (?) Michael: Voice packets also being late is bad Might have a policy to only use this for media, = not for regular data # 216 Solution-specific or requirement Tero: Is there a use case where the end point moves from = outside the gateway to inside Paul: Mobility is a use case, but not just for multiple = interfaces Steve: Either a new use case, or within the existing = ones # 217 Requirement: it's a "how", not a use case David: Authorization is out of scope # 218 Explain that this doesn't scale in 3.1. Tero: It is also proprietary and can't be interoperable Brian: We can push out configs if needed Paul: Remember the massive failure of the IPS WG Also issue with NATs if the endpoint hasn't = talked first # 219 People don't need to use this if they don't want to Say this in the security considerations Yoav Nir: Has to be a requirement that any solution can = implement different policies Yaron Sheffer: Agrees with Yoav, maybe becomes a use case Take this to the list # 220 Deleted paragraph # 221 Add text, proprietary approaches don't always implement = all of the IPsec architecture Paul: wants a name that is properly descriptive, maybe also = creative Next steps Steve will issue new I-D with new name Spend April writing requirements Then ask people to propose solutions Yaron: Requirements go in this draft in a different = section Paul: Wants to see "the right amount" of interaction on = this document We have no idea if existing solutions will meet = requirements because the requirements section is blank May have some proposed solutions befor Vancouver More raw public keys Tero draft-kivinen-ipsecme-oob-pubkey-00.txt Similar to what is happening TLS WG If we adopt this, what do we do with the old format? Michael: Should say, don't be silent Yaron: Needs to be Standards Track Paul: We need to discuss this on the mailing list even if it is = not a WG document Brian: The document doesn't describe the encoding of the keys Paul: It comes from PKIX SubjectPublicKeyInfo definition ERP for IKEv2 Yoav draft-nir-ipsecme-erx Minor change to protocol so that you don't have to renegotiate = when you move around Doesn't deal with multiple AAA domains Will be on the list IANA Issue in IKEv1 ipsec-registry Tero Everything is a mess Will ask on the list, silence means that he can go ahead Use of config payload for 3GPP and Femtocell Tricci So draft-so-ipsecme-ikev2-cpext-01 Femto is on many technologies, not just 3GPP Fixed wireline operator needs to apply a policy to the Femto = device Need to know the location of the Fembto AP, based on IP = address Reuses Config payload to let SG pass back the address Tero: This is the completely wrong way to do this It's not config information, and it can't be trusted Maybe use an SNMP MIB instead (?): Also thought this is the wrong thing to do Paul: Not clear the process is, but it should be discussed more = on the mailing list From xiangyang.zhang@huawei.com Mon Apr 2 18:13: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 CA6CC21F8705 for ; Mon, 2 Apr 2012 18:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LUqs-TJXfpE for ; Mon, 2 Apr 2012 18:13:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3232921F856F for ; Mon, 2 Apr 2012 18:13:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEX24520; Mon, 02 Apr 2012 21:13:21 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 2 Apr 2012 18:13:02 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.128]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Mon, 2 Apr 2012 18:12:59 -0700 From: Xiangyang zhang To: "ipsec@ietf.org" Thread-Topic: draft-zhang-ipsecme-multi-path-ipsec Thread-Index: AQHNETbnWY8qptfHo0+ep8QVvtAqKA== Date: Tue, 3 Apr 2012 01:12:58 +0000 Message-ID: <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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 Apr 2012 01:13:22 -0000 A new version of I-D, draft-zhang-ipsecme-multi-path-ipsec-00.txt has been = successfully submitted by Xiangyang Zhang and posted to the IETF repository= . Filename: draft-zhang-ipsecme-multi-path-ipsec Revision: 00 Title: Multiple Path IP Security Creation date: 2012-04-02 WG ID: Individual Submission Number of pages: 7 Abstract: This document presents one approach to enhance data protection when transmitting IPsec datagrams across the insecure networks. The method affords the stronger protection to the traffic by splitting it among a set of sub-tunnels. All the Security Associations (SAs) are set up independently for all sub-tunnels. Both the sending and receiving entity combine all the sub-tunnels to one clustered tunnel. As different sub-tunnel uses different crypto key materials and processing parameters, it may achieve the stronger protection of the traffic across the insecure networks. In addition, it could possibly bring more benefits in terms of the network control. From smoonen@us.ibm.com Wed Apr 4 06:18: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 615AA21F86DA for ; Wed, 4 Apr 2012 06:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 8VFqdl3yvDIo for ; Wed, 4 Apr 2012 06:18:46 -0700 (PDT) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id A8B4C21F86D9 for ; Wed, 4 Apr 2012 06:18:46 -0700 (PDT) Received: from /spool/local by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 4 Apr 2012 07:18:45 -0600 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 4 Apr 2012 07:18:39 -0600 Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 0DD4619D804C for ; Wed, 4 Apr 2012 07:18:31 -0600 (MDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q34DIABl137094 for ; Wed, 4 Apr 2012 07:18:12 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q34DIZvA017377 for ; Wed, 4 Apr 2012 07:18:35 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.63.40.219]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id q34DIZGZ017365 for ; Wed, 4 Apr 2012 07:18:35 -0600 X-KeepSent: 87C95C32:699E206F-852579D6:00480355; type=4; name=$KeepSent To: ipsec@ietf.org X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Wed, 4 Apr 2012 09:17:56 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.3 ZX853HP5|January 12, 2012) at 04/04/2012 07:18:08 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12040413-3270-0000-0000-00000550DF71 Subject: [IPsec] IKEv2-only implementation question 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 Apr 2012 13:18:47 -0000 I'm curious how IKEv2-only implementations have approached the problem of dealing with IKEv1 proposals. IKEv2 defines an INVALID_MAJOR_VERSION notify, but it only carries a maximum version and not a minimum version. (I wonder if that is an oversight.) IKEv1 (in RFC 2408) defines an INVALID-MAJOR-VERSION notify which MAY be sent. The RFC does not discuss whether the notify carries any data. If I wanted to send an "IKEv1 not supported" indication from an IKEv2-only daemon, I think I would use the IKEv1 INVALID-MAJOR-VERSION notify and not send any SPI or notification data in the payload. How have existing IKEv2-only implementations approached this? Do you ignore IKEv1 messages, or do you send an error notification in response? Thanks, Scott Moonen (smoonen@us.ibm.com) Secure Hybrid Cloud and z/OS Communications Server http://www.linkedin.com/in/smoonen From dharmanandana.pothulam@huawei.com Thu Apr 5 09:19:35 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 39A1721F86E5 for ; Thu, 5 Apr 2012 09:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.271 X-Spam-Level: X-Spam-Status: No, score=0.271 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, SARE_GIF_ATTACH=1.42] 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 lv1bcz+A1IYq for ; Thu, 5 Apr 2012 09:19:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9637121F86F0 for ; Thu, 5 Apr 2012 09:19:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEZ47095; Thu, 05 Apr 2012 12:19:33 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Apr 2012 09:18:43 -0700 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Apr 2012 09:18:41 -0700 Received: from blrprnc06ns (10.18.96.95) by szxeml401-hub.china.huawei.com (10.82.67.31) with Microsoft SMTP Server id 14.1.323.3; Fri, 6 Apr 2012 00:18:32 +0800 From: Dharmanandana Reddy Pothula To: Date: Thu, 5 Apr 2012 21:48:30 +0530 Organization: HTIPL Message-ID: <000c01cd1347$bdf8b010$39ea1030$@pothulam@huawei.com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_000D_01CD1375.D7B0EC10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0TR7mc/q4ozb+pT+e5kQr05tjGvQ== Content-Language: en-us x-cr-hashedpuzzle: CbBd C+pX DboS HB4H IcOy JraM KQqY LWbW MCnh MSD/ NvR0 PsRc QPEp QlxC U2oP V3nH; 2; aQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAeABpAGEAbgBnAHkAYQBuAGcALgB6AGgAYQBuAGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Sosha1_v1; 7; {052D6994-903D-4912-9F38-B2B932AD1B0E}; ZABoAGEAcgBtAGEAbgBhAG4AZABhAG4AYQAuAHAAbwB0AGgAdQBsAGEAbQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Thu, 05 Apr 2012 16:18:24 GMT; WwBJAFAAUwBlAGMAXQA6ACAATQB1AGwAdABpAHAAbABlACAAcABhAHQAaAAgAEkAUAAgAFMAZQBjAHUAcgBpAHQAeQAgAGYAbwByACAAZAByAGEAZgB0AC0AegBoAGEAbgBnAC0AaQBwAHMAZQBjAG0AZQAtAG0AdQBsAHQAaQAtAHAAYQB0AGgALQBpAHAAcwBlAGMALQAwADAA x-cr-puzzleid: {052D6994-903D-4912-9F38-B2B932AD1B0E} X-Originating-IP: [10.18.96.95] X-CFilter-Loop: Reflected Cc: ipsec@ietf.org Subject: [IPsec] [IPSec]: Multiple path IP Security for draft-zhang-ipsecme-multi-path-ipsec-00 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: Thu, 05 Apr 2012 16:19:35 -0000 ------=_NextPart_000_000D_01CD1375.D7B0EC10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01CD1375.D7B0EC10" ------=_NextPart_001_000E_01CD1375.D7B0EC10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Zhang, I am confused about the statement in your draft "Unlike SA bundle, one IP packet is still protected by one single SA instead of nested SAs". Does single SA means cluster SA? Or sub-SA? If it is cluster SA, what exactly it meant from SAD point of view? For example, Let us consider the following header, the host is tunneling a packet to the gateway using ESP but is authenticating to the end host B. How do we address this using your proposed solution SA clustering? If multiple packets goes through two different sub-SA's. here my understanding is two different sub-SA's means two separate SA's are ESP SA and AH SA. Does this mean packet go through either ESP SA or AH SA? Please correct me , if I misunderstood. Bb726946.f4_14(en-us,TechNet.10).gif Second point, About SA cluster feature support, Does both parties need to exchange vendor ID to express support and use of SA cluster feature? It would be better to address this in draft including proposed vendor id values, if vendor id used in IKE negotiation. Third point, about name of the draft, I feel multiple path sounds like multiple routes, it does not implies multiple SA's. Regards, Dharmanandana Reddy Pothula. This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ------=_NextPart_001_000E_01CD1375.D7B0EC10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Zhang,

 

I am confused about the statement in your draft =  “Unlike SA bundle, one IP packet is still protected by one = single SA instead of nested SAs”. Does single SA means cluster SA? = Or sub-SA? If it is cluster SA, what exactly it meant from SAD point of = view?

 

For example, Let us consider the following header, the = host is tunneling a packet to the gateway using ESP but is = authenticating to the end host B. How do we address this using your = proposed solution SA clustering? If  multiple packets goes through = two different sub-SA’s. here my understanding is two different = sub-SA’s means two separate SA’s are ESP SA and AH SA. Does = this mean packet go through either ESP SA or AH SA? Please correct me , = if I misunderstood.

=

3D"Bb726946.f4_14(en-us,TechNet.10).gif"

 

Second = point,  About SA cluster feature support, Does both parties need to = exchange vendor ID to express support and use of SA cluster feature? It = would be better to address this in draft including proposed vendor id = values, if vendor id used in IKE negotiation.

 

Third point, = about name of the draft, I feel multiple path sounds like multiple = routes, it does not implies multiple SA’s.

 

Regards,

Dharmanandana Reddy Pothula.

 

=

 

 

 

&n= bsp;  This e-mail and attachments contain confidential = information from HUAWEI, which is intended only for the person or entity = whose address is listed above. Any use of the information contained = herein in any way (including, but not limited to, total or partial = disclosure, reproduction, or dissemination) by persons other than the = intended recipient's) is prohibited. If you receive this e-mail in = error, please notify the sender by phone or email immediately and delete = it!=

 

------=_NextPart_001_000E_01CD1375.D7B0EC10-- ------=_NextPart_000_000D_01CD1375.D7B0EC10 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: R0lGODdhTwFEAN0AAPz+/AQCBAQGBPz6/ERCRLy6vAwKDGxqbNTS1JyanExKTDQyNMTCxLSytISC hNza3JyenCwqLFxaXGRiZKSipMzKzDw6PISGhHRydJSSlFRWVNTW1ExOTGRmZLS2tFRSVKyqrCwu LIyKjGxubHx+fMzOzPT29Hx6fERGRKSmpNze3JSWlLy+vCQiJCQmJDQ2NDw+PAwODKyurOTi5MTG xOzq7BwaHFxeXIyOjOzu7HR2dPTy9BweHOTm5BQSFBQWFCwAAAAATwFEAAAG/0CAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMNg4C6LR6zW673/C4fE6v2+/4vH7P7/v/bEMmBmVbAwKFWwGJ WouMWI6PVgIDQgOEklWXmZOcVZGeUYihUgaVAIOkUZuqUKOtTqCwS69HDyFEDARgBAxNlJaYs0y1 w0nFxkeyyUbIRA8BuEK6SBAHVr1NwiYxzEms3kfO4QDL5ADjQhsRCAvTu0cJ11XZxKfg50PC+ULp 3ubk/D2IUMIdAGoAPKCRAIACmgMZMAhx4EAIhgwADqChIORDAwUFCLAQsgBBElNCuPEbgo+fP2YA w/lbB6DEi4O7CigQkoIhhP8OACJOrAjg4oEEQm6AAMAhgAcABGgAeFFCCTAALc8dWjnkZbKY3gRG AIDgJgMYAHQKAeFzHg4dF0iQuHBCRMYVQiSkAOBRSC8LFZagRNWNa9ZzXo2BZSZWSAUL1BSmuQFA nhARJxyQoKgDB4ARSAFIWPrhKQAYaAJbvbePX+t8iYctTtYYQIUXNHZ52Enkp5C3cefW/Rz6xt6+ UH1RVTJYpeHXiLkKmW1s5lghNALk5LCWsuXLJ4QMzxh6NNMGQmD4Krk6GJEZLgBAUwOPSIoJVxSM hLJ1Cgg2EgHggBoYAdDBGuhNUUsNPAAwwxoWGCEDQ1ZwUIAU1DmxQoATXUD/xAEQYCGQNNOgBUAD aGggBAQBzIOZeB4KcWAAHPGVYFQkmYREc4UJMUMLZJEIAAu8DUEBftj4wh90TfR0xAVEWYTXBDUK YaGCRNRgg3zxDZFbEWzld2EUGTIhj1BCzPVhiFfENstV+PwIwAYGCcFCfTxRZgUK+0HBJBNhGhEX ESNgNAGbVpomSpZbqtAldhESMeEVHCj6RJlLyIMDhxR9GFon0vH4HpA0DcEACkUcmUAAIwxxARp2 CaERjUN8EEBISr6AxgNCtDCDDTkUcViTehbRqRFUEgESlkP00Oh1jpk4BFsOAfUbGlFigManEgTw 0ZioBaBjBCq00IMRmCqx/wJEnMYoI6JVuAkLnPvISScRLKBqXwD4CfUiAMNdlNReGqCHQgAjASZE BLzyEMC5wspLxH9rBDhgALG+S0SlzAqhJQCOEkFDpNMGwJBlaHZ6gmcGhmgcU04llyMALgQwgzJZ WPNbeACQwMan8YIhAglTWFDVSac4J0S5ZK2BZ55CZNDqvzpkLMQEx8kgBJ8AKAwAwwDwALGwfy7h pBI6BFDgBAhSsWCjEBoBgoqVXYPmZkWAKNpSACxbTwgmuaACEuki8d1babrbsohgHBsFe8ew9l58 Gwh5xH1CbAiACGrEOEIaHBW8tS8WqLEBAL7uSEWgS4yAVwfwBj3ExyErMf8pAL5loAbRRaWBlF6J QqVGVWDjfIVDa4TnOHmMfzGoFMshnVKPDgLZzhJHRt0qXUUIDMDLyKFw4QuqDSH2EcMycXYRUBKB wZRVgipEDw0OtESglm1axMoaKyXEsuopguAIhwUIIEkI3FPTEGDXvCTQqQQBIJlk6EYBawmlfQBI WwDwkhQ0JEh4FYAcEug1qjlZzggp0JPm/jWcQgGAbaHTWt8Sphqwpc4MEpsWhdjHOyG4kIENBADt HoWEua0IKCmrSNUyEoDf7YUpT6kHe4qHritgjn2asdpRgniEDQTAHTRAi1oAEKbsBUUigxrPFpNl oxl2LQBH21HSqCen6yn/wYxSQyAa3KURCLyML2nIFRpOF7axESF9ZgPQRAh0tfjJzmP1g1YRKXQ4 NPRQWysAYrfQAC40HG2AxquCGYmgGbwNQW9tWkLlsPM0/B1gBa0SUEXUCLTzAIBrU4mjOCQXKumg w5eFI8VLbuGYSBUgDXT7CZraNx7XddCDfRvTC3Qkx+lJB5GMAaYvX2LHMKZFX67MIwDSGKs11ogD 6JGiLpvBy5X0hys5JEUwQ/ESL7rjMUPaCYroVrchDA1gnoMfADTgrVvux2jMmeM1y5ZN6czTE/UM AQQlGAAOsG5dQziWBjkomgCAgGPCQwM1d+meXkonnqF4KCfqWadMzUMM/6J6zja1edIlIOCEhoul GEhoGJRClKbwXAIxsRcAa40hpu5kKG2AuhKfrvQegIiqVKdK1apa9apYzSogTuHLrnr1q2ANq1jH StaymvWsaE2rWtfK1ra69a1wjatc50rXutr1rnjNq173ytcl1EANkswCG600JiFM0607UAOQuLDF IYhuCDAoX1+HkYMfEOFeW+hA/K4kBMCIMK0DoJ4KAnsF0BDhsckh32SN8bEhrHILg43mEAADOLbu wAdEqJ0WGtuRD6rHa6uFRQ62ZITHUOOYAeBn5tiguBfCC6Rdo8EC1nlWpRGhHfhkABq40xs29FBW HB2oDFNL3eCGogdoIP9iBQIgRt6wzglsWwO4pAKABRBSrYkNQIOGAEGzwKMBH4jC59pmUMOO1Lyt UEEAroPPb1YBiP8zDY4AEIL7svVBi7UjQqbgTMfKUD+GlSyCYXGvBo/RCLpbg9VeGD+/sYFXbx1t TQyy4SKwaA1RkhXQ+nKwNRx4xI8Y7mVxcRshFEBfU4AwFKHSp6/BGK0mwO0QmKZhaUnBtB6W7RCm C2RP1MCyQ7heCYzp3h3Ct8VHbrIQQHnW2z5jLBr+b4ChwFsbLasIIXhylx/x1zQwmGTIVa4TNLsx XBmBim1WrBBuOgQWbFcKddaADBRgqZnt+dKYzrSmN83pTnv606AOtaj/R03qUpv61GrNAWC9EN80 SHgNeq6uorsQafQowMeo1kJlh2A/JDRA0E1Qst+ajGizKo1pSCgAd6GAZSFIum+W+myuqdDaRbdU UnOGQmz9Rt81x7qsbp4yaY287CfUmceFpfCPpx2FXbtWGusNAKokY+YVMLcISuZYPYSQZ7VaV8ZN Y29a0JBt3Hk3b+EV3Z0tzW5qE9fatiEzAGQAbCZs+0LhSoOF2yxlITwgPnFOSJGeMGA1aK3HaShv w5/gbnUQ+SZEALAUZpSGGylpYd8ma5QnF6QinJjk4f2A1hZe33WvvAnVnpNBshMA3lC8CClWw4oP 1ZHx7tvJ+O24fK4Dg0HtCMED5TY4jvMGNNGJjwi1PboUWm5Cn6NK5lEgdG/9Quycj/XfRMRJWkbu hGaLV8sMV/sTqt1rE+uz4ksYbGn80m2spzXc1YP4kHQT9iac22DplrbgmaDqNKgXDfpCkZmbQPUh uNh0azWBGvYrhK6b6JgFt3zZbb0GlW/+9rj/ahAAADs= ------=_NextPart_000_000D_01CD1375.D7B0EC10-- From mglt.ietf@gmail.com Thu Apr 5 11:22: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 9D6AD21F86BE for ; Thu, 5 Apr 2012 11:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWH1SF-IqUUW for ; Thu, 5 Apr 2012 11:22:52 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99A4C21F86BB for ; Thu, 5 Apr 2012 11:22:40 -0700 (PDT) Received: by iazz13 with SMTP id z13so2535803iaz.31 for ; Thu, 05 Apr 2012 11:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=XFdjv7a/fqaRyn+1HqMHIJcoxa8OC9d8t+iiMuFm2IA=; b=Rzfq8QQQfVnak+oFpq8myAzuaLeHtLctgQ0LB8RFEWNrJ0I0yjLOV3NUjiVxBa6QIF 4hDiBSmoFK/nVgMX9kPZ5d7DlFps4QfaHJaJE3TVhfachmQzrliv4w5siX/o4Cw8ee26 xLOCgsWBzk8Xk2OfZ97RkwXvpVKSXXERHd4AVNxax/Ny7xIVVjZgV6YVsvAsZphtvyE2 zUVUidT0nxzf37U+6xW5r+JbjlvexA3Qwx+reDEjUXXfSWyaozbKhtOJV/agAoRNxBh+ ZOOf+y6XalG6kXd3u9nR8V3/fkmqd2/Nb4vT9Ha1jeTwGCNAsgOpVNCfO/fdIKE7jl4P DMGw== MIME-Version: 1.0 Received: by 10.50.183.137 with SMTP id em9mr6793982igc.58.1333650160179; Thu, 05 Apr 2012 11:22:40 -0700 (PDT) Received: by 10.231.170.138 with HTTP; Thu, 5 Apr 2012 11:22:40 -0700 (PDT) Date: Thu, 5 Apr 2012 20:22:40 +0200 Message-ID: From: Daniel Migault To: IPsecme WG Content-Type: multipart/alternative; boundary=14dae93408f70d5a9d04bcf2a08b Subject: [IPsec] SPI Collision X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 18:22:52 -0000 --14dae93408f70d5a9d04bcf2a08b Content-Type: text/plain; charset=ISO-8859-1 Hi, I am wondering how SPI collision is considered by IKEv2, and have not found any documentation on it, so if there are some, please let me know. My current understanding is that when an CREATE_CHILD_SA exchange is performed the Initiator and Responder announce the SPI in the SA payload. If the Initiator announces an SPI that is already used by the Responder (with another peer), the Responder cannot accept this proposition and must send an error message. I haven't found anything like this in RFC5996. Am I missing something ? Furthermore I cannot find any message for this error. INVALID_SPI does not seems to be used for the creating of an SPI, but only if an ESP/AH/IKE packet comes with an unrecognized SPI. In addition it seems the Notify Payload MUST be sent out of the IKE_SA.... Can anyone tell me which error message is used? BR Daniel -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --14dae93408f70d5a9d04bcf2a08b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I am wondering how SPI collision is considered by IKEv2, and ha= ve not found any documentation on it, so if there are some, please let me k= now.

My current understanding is that when an CREATE_CHILD_SA exchan= ge is performed the Initiator and Responder announce the SPI in the SA payl= oad. If the Initiator announces an SPI that is already used by the Responde= r (with another peer), the Responder cannot accept this proposition and mus= t send an error message. I haven't found anything like this in RFC5996.= Am I missing something ?

Furthermore I cannot find any message for this error. INVALID_SPI does = not seems to be used for the creating of an SPI, but only if an ESP/AH/IKE = packet comes with an unrecognized SPI. In addition it seems the Notify Payl= oad MUST be sent out of the IKE_SA.... Can anyone tell me which error messa= ge is used?

BR
Daniel

--
Daniel Migault
Orange Labs= -- Security
+33 6 70 72 69 58
--14dae93408f70d5a9d04bcf2a08b-- From ynir@checkpoint.com Thu Apr 5 12:16: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 C264421F85D5 for ; Thu, 5 Apr 2012 12:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 Udv5pgw4ExUo for ; Thu, 5 Apr 2012 12:16:00 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C1D0821F85D4 for ; Thu, 5 Apr 2012 12:15:59 -0700 (PDT) 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 q35JFuuj021800; Thu, 5 Apr 2012 22:15:56 +0300 X-CheckPoint: {4F7DFD01-0-1B221DC2-5FFFF} 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; Thu, 5 Apr 2012 22:15:56 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 5 Apr 2012 22:15:54 +0300 From: Yoav Nir To: Daniel Migault Date: Thu, 5 Apr 2012 22:15:53 +0300 Thread-Topic: [IPsec] SPI Collision Thread-Index: Ac0TYIVEHtcm9fenTUCI3kqo0pqPYg== 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IPsecme WG Subject: Re: [IPsec] SPI Collision X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 19:16:01 -0000 Hi Daniel On Apr 5, 2012, at 9:22 PM, Daniel Migault wrote: > Hi,=20 >=20 > I am wondering how SPI collision is considered by IKEv2, and have not fou= nd any documentation on it, so if there are some, please let me know. >=20 > My current understanding is that when an CREATE_CHILD_SA exchange is perf= ormed the Initiator and Responder announce the SPI in the SA payload. If th= e Initiator announces an SPI that is already used by the Responder (with an= other peer), the Responder cannot accept this proposition and must send an = error message. I haven't found anything like this in RFC5996. Am I missing = something ? >=20 > Furthermore I cannot find any message for this error. INVALID_SPI does no= t seems to be used for the creating of an SPI, but only if an ESP/AH/IKE pa= cket comes with an unrecognized SPI. In addition it seems the Notify Payloa= d MUST be sent out of the IKE_SA.... Can anyone tell me which error message= is used?=20 >=20 > BR=20 > Daniel In IKE (both v1 and v2) it's always two IPsec SAs that are negotiated at th= e same time. Each side sends in its CCSA message the SPI for the inbound SA= . So for traffic going from the initiator to the responder, it's the respon= der that chooses the SPI, while for traffic going from the responder to the= initiator, the initiator chooses the SPI. This allows both peers to make s= ure that inbound SAs have unique SPIs. The same guarantee cannot be made for outbound traffic. The SPI for outboun= d traffic is chosen by the peer, and one particular implementation that I'm= aware of assigns them serially, so with many peers like that, you have a h= igh chance of collision. The fact is that it is usually not a problem. In o= utbound IPsec processing the stack sees the cleartext packet, chooses an SA= based on attributes of the packet, and constructs the protected packet bas= ed on encryption keys, MAC keys, the replay counter and the SPI which are p= art of the SA. The SPI is a value, not a key in the table of outbound SAs, = so there's no harm done even if all the outbound SAs have the same SPI.=20 This is different from the inbound case, where the SPI is used as a key to = the SA table, and therefore has to be unique. Hope this helps Yoav From kent@bbn.com Thu Apr 5 12:29: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 6A2B821F8665 for ; Thu, 5 Apr 2012 12:29:17 -0700 (PDT) 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 Y3uC-n7kiHdw for ; Thu, 5 Apr 2012 12:29:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E676821F865D for ; Thu, 5 Apr 2012 12:29:16 -0700 (PDT) Received: from dhcp89-089-180.bbn.com ([128.89.89.180]:49265) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SFsMY-000Hpc-3H; Thu, 05 Apr 2012 15:28:54 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> Date: Thu, 5 Apr 2012 15:29:08 -0400 To: Xiangyang zhang From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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 Apr 2012 19:29:17 -0000 At 1:12 AM +0000 4/3/12, Xiangyang zhang wrote: >A new version of I-D, draft-zhang-ipsecme-multi-path-ipsec-00.txt >has been successfully submitted by Xiangyang Zhang and posted to the >IETF repository. > >Filename: draft-zhang-ipsecme-multi-path-ipsec >Revision: 00 >Title: Multiple Path IP Security >Creation date: 2012-04-02 >WG ID: Individual Submission >Number of pages: 7 > >Abstract: > This document presents one approach to enhance data protection when > transmitting IPsec datagrams across the insecure networks. The method > affords the stronger protection to the traffic by splitting it among > a set of sub-tunnels. All the Security Associations (SAs) are set up > independently for all sub-tunnels. Both the sending and receiving > entity combine all the sub-tunnels to one clustered tunnel. As > different sub-tunnel uses different crypto key materials and > processing parameters, it may achieve the stronger protection of the > traffic across the insecure networks. In addition, it could possibly > bring more benefits in terms of the network control. This seems like a potentially very complex feature that creates added opportunities for packet arrival reordering (of added jitter) without a good analysis of the security rationale. Also, as others have noted, this is not a "multi-path" feature, but a multi=-tunnel feature, so the doc name is inappropriate. The comment on multiple paths in the secruity considerations section is also in error. Steve From xiangyang.zhang@huawei.com Thu Apr 5 21:38:29 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 C192311E8094 for ; Thu, 5 Apr 2012 21:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=-1.211, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] 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 rfqNnC5kNX1r for ; Thu, 5 Apr 2012 21:38:27 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD6011E8083 for ; Thu, 5 Apr 2012 21:38:27 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AER79964; Fri, 06 Apr 2012 00:38:27 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Apr 2012 21:37:27 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.128]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Thu, 5 Apr 2012 21:37:15 -0700 From: Xiangyang zhang To: dharmanandana pothulam Thread-Topic: [IPSec]: Multiple path IP Security for draft-zhang-ipsecme-multi-path-ipsec-00 Thread-Index: Ac0TR7mc/q4ozb+pT+e5kQr05tjGvQAYioeg Date: Fri, 6 Apr 2012 04:37:25 +0000 Message-ID: <00E6CDB229A4CF4487D6E0326EDE5A0320A0F555@dfweml511-mbx.china.huawei.com> References: <000c01cd1347$bdf8b010$39ea1030$@pothulam@huawei.com> In-Reply-To: <000c01cd1347$bdf8b010$39ea1030$@pothulam@huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.56] Content-Type: multipart/related; boundary="_004_00E6CDB229A4CF4487D6E0326EDE5A0320A0F555dfweml511mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [IPSec]: Multiple path IP Security for draft-zhang-ipsecme-multi-path-ipsec-00 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, 06 Apr 2012 04:38:30 -0000 --_004_00E6CDB229A4CF4487D6E0326EDE5A0320A0F555dfweml511mbxchi_ Content-Type: multipart/alternative; boundary="_000_00E6CDB229A4CF4487D6E0326EDE5A0320A0F555dfweml511mbxchi_" --_000_00E6CDB229A4CF4487D6E0326EDE5A0320A0F555dfweml511mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dharmanandana, 1. SA bundle is the ordered list of SAs. For SA cluster, it contains a se= t of SA. Which SA is used for traffic protection is purely implementation = dependent. The SA cluster means only one SA is used while SA bundle means = all SAs are used. Single SA can be viewed as cluster SA with only one sub-= SA. In your example, your understanding is correct. Either SA can be used, but= not necessarily both. 2. If IPsec supports SA cluster, IKE should be extended to support SA nego= tiation. We can work out the details if SA cluster can be supported. IKE = extension will solve the interoperability problem. 3. That is true. It implies different paths. Different paths may use the = same or different routes. But the different paths have used different SA t= o protect it. Thanks, Victor From: dharmanandana pothulam Sent: Thursday, April 05, 2012 9:18 AM To: Xiangyang zhang Cc: ipsec@ietf.org Subject: [IPSec]: Multiple path IP Security for draft-zhang-ipsecme-multi-p= ath-ipsec-00 Hi Zhang, I am confused about the statement in your draft "Unlike SA bundle, one IP = packet is still protected by one single SA instead of nested SAs". Does sin= gle SA means cluster SA? Or sub-SA? If it is cluster SA, what exactly it me= ant from SAD point of view? For example, Let us consider the following header, the host is tunneling a = packet to the gateway using ESP but is authenticating to the end host B. Ho= w do we address this using your proposed solution SA clustering? If multip= le packets goes through two different sub-SA's. here my understanding is tw= o different sub-SA's means two separate SA's are ESP SA and AH SA. Does thi= s mean packet go through either ESP SA or AH SA? Please correct me , if I m= isunderstood. [Bb726946.f4_14(en-us,TechNet.10).gif] Second point, About SA cluster feature support, Does both parties need to = exchange vendor ID to express support and use of SA cluster feature? It wou= ld be better to address this in draft including proposed vendor id values, = if vendor id used in IKE negotiation. Third point, about name of the draft, I feel multiple path sounds like mult= iple routes, it does not implies multiple SA's. Regards, Dharmanandana Reddy Pothula. This e-mail and attachments contain confidential information from HUAWEI= , which is intended only for the person or entity whose address is listed a= bove. Any use of the information contained herein in any way (including, bu= t not limited to, total or partial disclosure, reproduction, or disseminati= on) by persons other than the intended recipient's) is prohibited. If you r= eceive this e-mail in error, please notify the sender by phone or email imm= ediately and delete it! --_000_00E6CDB229A4CF4487D6E0326EDE5A0320A0F555dfweml511mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dharmanandana,

 

1.  SA bundle is = the ordered list of SAs.  For SA cluster, it contains a set of SA.&nbs= p; Which SA is used for traffic protection is purely implementation depende= nt.  The SA cluster means only one SA is used while SA bundle means all SAs are used.  Single SA can be viewed as cluster= SA with only one sub-SA.

 

In your example, your = understanding is correct.  Either SA can be used, but not necessarily = both.

 

2.  If IPsec supp= orts SA cluster, IKE should be extended to support SA negotiation.  We= can work out the details if SA cluster can be supported.  IKE extensi= on will solve the interoperability problem.

 

3. That is true. = It implies different paths.  Different paths may use the same or diff= erent routes.  But the different paths have used different SA to prote= ct it.

 

Thanks,

 

Victor

 

From: dharmana= ndana pothulam
Sent: Thursday, April 05, 2012 9:18 AM
To: Xiangyang zhang
Cc: ipsec@ietf.org
Subject: [IPSec]: Multiple path IP Security for draft-zhang-ipsecme-= multi-path-ipsec-00

 

Hi Zhang,

 

I am confused about the statement in your draft &nbs= p;“Unlike SA bundle, one IP packet is still protected by one single S= A instead of nested SAs”. Does single SA means cluster SA? Or sub-SA?= If it is cluster SA, what exactly it meant from SAD point of view?

 

For example, Let us consider the following header, t= he host is tunneling a packet to the gateway using ESP but is authenticatin= g to the end host B. How do we address this using your proposed solution SA= clustering? If  multiple packets goes through two different sub-SA’s. here my understanding is two di= fferent sub-SA’s means two separate SA’s are ESP SA and AH SA. = Does this mean packet go through either ESP SA or AH SA? Please correct me = , if I misunderstood.

 

3D"Bb726946.f4_14(=

 

Second point,  About SA cluster feature support= , Does both parties need to exchange vendor ID to express support and use o= f SA cluster feature? It would be better to address this in draft including= proposed vendor id values, if vendor id used in IKE negotiation.

 

Third point, about name of the draft, I feel multipl= e path sounds like multiple routes, it does not implies multiple SA’s= .

 

Regards,

Dharmanandana Reddy Pothula.

 

 

 

 

 

=    This e-mail and attachments contain confidential informat= ion from HUAWEI, which is intended only for the person or entity whose addr= ess is listed above. Any use of the information contained herein in any way (i= ncluding, but not limited to, total or partial disclosure, reproduction, or= dissemination) by persons other than the intended recipient's) is prohibit= ed. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete i= t!

 

--_000_00E6CDB229A4CF4487D6E0326EDE5A0320A0F555dfweml511mbxchi_-- --_004_00E6CDB229A4CF4487D6E0326EDE5A0320A0F555dfweml511mbxchi_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2654; creation-date="Fri, 06 Apr 2012 04:37:25 GMT"; modification-date="Fri, 06 Apr 2012 04:37:25 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODdhTwFEAN0AAPz+/AQCBAQGBPz6/ERCRLy6vAwKDGxqbNTS1JyanExKTDQyNMTCxLSytISC hNza3JyenCwqLFxaXGRiZKSipMzKzDw6PISGhHRydJSSlFRWVNTW1ExOTGRmZLS2tFRSVKyqrCwu LIyKjGxubHx+fMzOzPT29Hx6fERGRKSmpNze3JSWlLy+vCQiJCQmJDQ2NDw+PAwODKyurOTi5MTG xOzq7BwaHFxeXIyOjOzu7HR2dPTy9BweHOTm5BQSFBQWFCwAAAAATwFEAAAG/0CAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMNg4C6LR6zW673/C4fE6v2+/4vH7P7/v/bEMmBmVbAwKFWwGJ WouMWI6PVgIDQgOEklWXmZOcVZGeUYihUgaVAIOkUZuqUKOtTqCwS69HDyFEDARgBAxNlJaYs0y1 w0nFxkeyyUbIRA8BuEK6SBAHVr1NwiYxzEms3kfO4QDL5ADjQhsRCAvTu0cJ11XZxKfg50PC+ULp 3ubk/D2IUMIdAGoAPKCRAIACmgMZMAhx4EAIhgwADqChIORDAwUFCLAQsgBBElNCuPEbgo+fP2YA w/lbB6DEi4O7CigQkoIhhP8OACJOrAjg4oEEQm6AAMAhgAcABGgAeFFCCTAALc8dWjnkZbKY3gRG AIDgJgMYAHQKAeFzHg4dF0iQuHBCRMYVQiSkAOBRSC8LFZagRNWNa9ZzXo2BZSZWSAUL1BSmuQFA nhARJxyQoKgDB4ARSAFIWPrhKQAYaAJbvbePX+t8iYctTtYYQIUXNHZ52Enkp5C3cefW/Rz6xt6+ UH1RVTJYpeHXiLkKmW1s5lghNALk5LCWsuXLJ4QMzxh6NNMGQmD4Krk6GJEZLgBAUwOPSIoJVxSM hLJ1Cgg2EgHggBoYAdDBGuhNUUsNPAAwwxoWGCEDQ1ZwUIAU1DmxQoATXUD/xAEQYCGQNNOgBUAD aGggBAQBzIOZeB4KcWAAHPGVYFQkmYREc4UJMUMLZJEIAAu8DUEBftj4wh90TfR0xAVEWYTXBDUK YaGCRNRgg3zxDZFbEWzld2EUGTIhj1BCzPVhiFfENstV+PwIwAYGCcFCfTxRZgUK+0HBJBNhGhEX ESNgNAGbVpomSpZbqtAldhESMeEVHCj6RJlLyIMDhxR9GFon0vH4HpA0DcEACkUcmUAAIwxxARp2 CaERjUN8EEBISr6AxgNCtDCDDTkUcViTehbRqRFUEgESlkP00Oh1jpk4BFsOAfUbGlFigManEgTw 0ZioBaBjBCq00IMRmCqx/wJEnMYoI6JVuAkLnPvISScRLKBqXwD4CfUiAMNdlNReGqCHQgAjASZE BLzyEMC5wspLxH9rBDhgALG+S0SlzAqhJQCOEkFDpNMGwJBlaHZ6gmcGhmgcU04llyMALgQwgzJZ WPNbeACQwMan8YIhAglTWFDVSac4J0S5ZK2BZ55CZNDqvzpkLMQEx8kgBJ8AKAwAwwDwALGwfy7h pBI6BFDgBAhSsWCjEBoBgoqVXYPmZkWAKNpSACxbTwgmuaACEuki8d1babrbsohgHBsFe8ew9l58 Gwh5xH1CbAiACGrEOEIaHBW8tS8WqLEBAL7uSEWgS4yAVwfwBj3ExyErMf8pAL5loAbRRaWBlF6J QqVGVWDjfIVDa4TnOHmMfzGoFMshnVKPDgLZzhJHRt0qXUUIDMDLyKFw4QuqDSH2EcMycXYRUBKB wZRVgipEDw0OtESglm1axMoaKyXEsuopguAIhwUIIEkI3FPTEGDXvCTQqQQBIJlk6EYBawmlfQBI WwDwkhQ0JEh4FYAcEug1qjlZzggp0JPm/jWcQgGAbaHTWt8Sphqwpc4MEpsWhdjHOyG4kIENBADt HoWEua0IKCmrSNUyEoDf7YUpT6kHe4qHritgjn2asdpRgniEDQTAHTRAi1oAEKbsBUUigxrPFpNl oxl2LQBH21HSqCen6yn/wYxSQyAa3KURCLyML2nIFRpOF7axESF9ZgPQRAh0tfjJzmP1g1YRKXQ4 NPRQWysAYrfQAC40HG2AxquCGYmgGbwNQW9tWkLlsPM0/B1gBa0SUEXUCLTzAIBrU4mjOCQXKumg w5eFI8VLbuGYSBUgDXT7CZraNx7XddCDfRvTC3Qkx+lJB5GMAaYvX2LHMKZFX67MIwDSGKs11ogD 6JGiLpvBy5X0hys5JEUwQ/ESL7rjMUPaCYroVrchDA1gnoMfADTgrVvux2jMmeM1y5ZN6czTE/UM AQQlGAAOsG5dQziWBjkomgCAgGPCQwM1d+meXkonnqF4KCfqWadMzUMM/6J6zja1edIlIOCEhoul GEhoGJRClKbwXAIxsRcAa40hpu5kKG2AuhKfrvQegIiqVKdK1apa9apYzSogTuHLrnr1q2ANq1jH StaymvWsaE2rWtfK1ra69a1wjatc50rXutr1rnjNq173ytcl1EANkswCG600JiFM0607UAOQuLDF IYhuCDAoX1+HkYMfEOFeW+hA/K4kBMCIMK0DoJ4KAnsF0BDhsckh32SN8bEhrHILg43mEAADOLbu wAdEqJ0WGtuRD6rHa6uFRQ62ZITHUOOYAeBn5tiguBfCC6Rdo8EC1nlWpRGhHfhkABq40xs29FBW HB2oDFNL3eCGogdoIP9iBQIgRt6wzglsWwO4pAKABRBSrYkNQIOGAEGzwKMBH4jC59pmUMOO1Lyt UEEAroPPb1YBiP8zDY4AEIL7svVBi7UjQqbgTMfKUD+GlSyCYXGvBo/RCLpbg9VeGD+/sYFXbx1t TQyy4SKwaA1RkhXQ+nKwNRx4xI8Y7mVxcRshFEBfU4AwFKHSp6/BGK0mwO0QmKZhaUnBtB6W7RCm C2RP1MCyQ7heCYzp3h3Ct8VHbrIQQHnW2z5jLBr+b4ChwFsbLasIIXhylx/x1zQwmGTIVa4TNLsx XBmBim1WrBBuOgQWbFcKddaADBRgqZnt+dKYzrSmN83pTnv606AOtaj/R03qUpv61GrNAWC9EN80 SHgNeq6uorsQafQowMeo1kJlh2A/JDRA0E1Qst+ajGizKo1pSCgAd6GAZSFIum+W+myuqdDaRbdU UnOGQmz9Rt81x7qsbp4yaY287CfUmceFpfCPpx2FXbtWGusNAKokY+YVMLcISuZYPYSQZ7VaV8ZN Y29a0JBt3Hk3b+EV3Z0tzW5qE9fatiEzAGQAbCZs+0LhSoOF2yxlITwgPnFOSJGeMGA1aK3HaShv w5/gbnUQ+SZEALAUZpSGGylpYd8ma5QnF6QinJjk4f2A1hZe33WvvAnVnpNBshMA3lC8CClWw4oP 1ZHx7tvJ+O24fK4Dg0HtCMED5TY4jvMGNNGJjwi1PboUWm5Cn6NK5lEgdG/9Quycj/XfRMRJWkbu hGaLV8sMV/sTqt1rE+uz4ksYbGn80m2spzXc1YP4kHQT9iac22DplrbgmaDqNKgXDfpCkZmbQPUh uNh0azWBGvYrhK6b6JgFt3zZbb0GlW/+9rj/ahAAADs= --_004_00E6CDB229A4CF4487D6E0326EDE5A0320A0F555dfweml511mbxchi_-- From xiangyang.zhang@huawei.com Thu Apr 5 21:44: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 3306411E8083 for ; Thu, 5 Apr 2012 21:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.783 X-Spam-Level: X-Spam-Status: No, score=-0.783 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] 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 wz6OkNUrEX0k for ; Thu, 5 Apr 2012 21:44:19 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A010111E8072 for ; Thu, 5 Apr 2012 21:44:18 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEZ78653; Fri, 06 Apr 2012 00:44:18 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Apr 2012 21:44:18 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.128]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Thu, 5 Apr 2012 21:44:07 -0700 From: Xiangyang zhang To: Nasir Bhutta , dharmanandana pothulam Thread-Topic: [IPsec] [IPSec]: Multiple path IP Security for draft-zhang-ipsecme-multi-path-ipsec-00 Thread-Index: AQHNE1YtQJSENgO4ekqI9Fu+R8E+j5aNNNzw Date: Fri, 6 Apr 2012 04:44:06 +0000 Message-ID: <00E6CDB229A4CF4487D6E0326EDE5A0320A0F572@dfweml511-mbx.china.huawei.com> References: <4f7dc624.2623440a.15df.7339SMTPIN_ADDED@mx.google.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.56] Content-Type: multipart/related; boundary="_004_00E6CDB229A4CF4487D6E0326EDE5A0320A0F572dfweml511mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipsec@ietf.org" Subject: Re: [IPsec] [IPSec]: Multiple path IP Security for draft-zhang-ipsecme-multi-path-ipsec-00 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, 06 Apr 2012 04:44:21 -0000 --_004_00E6CDB229A4CF4487D6E0326EDE5A0320A0F572dfweml511mbxchi_ Content-Type: multipart/alternative; boundary="_000_00E6CDB229A4CF4487D6E0326EDE5A0320A0F572dfweml511mbxchi_" --_000_00E6CDB229A4CF4487D6E0326EDE5A0320A0F572dfweml511mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nasir, I will read this paper later. For multi-path SA, a multi-homed device or device with multiple interfaces = can take advantage of it. Maybe multi-path TCP could provide some other cl= ue. Thanks, Victor From: Nasir Bhutta [mailto:mnmbhutta1@gmail.com] Sent: Thursday, April 05, 2012 11:01 AM To: dharmanandana pothulam Cc: Xiangyang zhang; ipsec@ietf.org Subject: Re: [IPsec] [IPSec]: Multiple path IP Security for draft-zhang-ips= ecme-multi-path-ipsec-00 Hi All, What are good applications and/or importance in Industry for Multi-path IPs= ec and Multilayer-IPsec? We have also modified the previous ML-IPsec to support for dynamic break do= wn of IP datagram into different Zones. A paper of dynamic ML-IPsec is atta= ched with this email. All critical questions and comments are welcome. With thanks. Kind Regards, Nasir On Thu, Apr 5, 2012 at 5:18 PM, Dharmanandana Reddy Pothula > wrote: Hi Zhang, I am confused about the statement in your draft "Unlike SA bundle, one IP = packet is still protected by one single SA instead of nested SAs". Does sin= gle SA means cluster SA? Or sub-SA? If it is cluster SA, what exactly it me= ant from SAD point of view? For example, Let us consider the following header, the host is tunneling a = packet to the gateway using ESP but is authenticating to the end host B. Ho= w do we address this using your proposed solution SA clustering? If multip= le packets goes through two different sub-SA's. here my understanding is tw= o different sub-SA's means two separate SA's are ESP SA and AH SA. Does thi= s mean packet go through either ESP SA or AH SA? Please correct me , if I m= isunderstood. [Bb726946.f4_14(en-us,TechNet.10).gif] Second point, About SA cluster feature support, Does both parties need to = exchange vendor ID to express support and use of SA cluster feature? It wou= ld be better to address this in draft including proposed vendor id values, = if vendor id used in IKE negotiation. Third point, about name of the draft, I feel multiple path sounds like mult= iple routes, it does not implies multiple SA's. Regards, Dharmanandana Reddy Pothula. This e-mail and attachments contain confidential information from HUAWEI= , which is intended only for the person or entity whose address is listed a= bove. Any use of the information contained herein in any way (including, bu= t not limited to, total or partial disclosure, reproduction, or disseminati= on) by persons other than the intended recipient's) is prohibited. If you r= eceive this e-mail in error, please notify the sender by phone or email imm= ediately and delete it! _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_00E6CDB229A4CF4487D6E0326EDE5A0320A0F572dfweml511mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nasir,<= /p>

 <= /p>

I will read this paper la= ter.

 <= /p>

For multi-path SA, a mult= i-homed device or device with multiple interfaces can take advantage of it.=   Maybe multi-path TCP could provide some other clue.

 <= /p>

Thanks,=

 <= /p>

Victor<= /p>

 <= /p>

From: Nasir Bh= utta [mailto:mnmbhutta1@gmail.com]
Sent: Thursday, April 05, 2012 11:01 AM
To: dharmanandana pothulam
Cc: Xiangyang zhang; ipsec@ietf.org
Subject: Re: [IPsec] [IPSec]: Multiple path IP Security for draft-zh= ang-ipsecme-multi-path-ipsec-00

 

Hi All, 

What are good applications and/or importance in Indu= stry for Multi-path IPsec and Multilayer-IPsec? 

 

We have also modified the previous ML-IPsec to suppo= rt for dynamic break down of IP datagram into different Zones. A paper= of dynamic ML-IPsec is attached with this email. All critical questions an= d comments are welcome. 

 

With thanks. 

 

Kind Regards,

Nasir

 

On Thu, Apr 5, 2012 at 5:18 PM, Dharmanandana Reddy = Pothula <dharmanand= ana.pothulam@huawei.com> wrote:

Hi Zhang,

 

I am confused about the statement in your draft  “Unlik= e SA bundle, one IP packet is still protected by one single SA instead of n= ested SAs”. Does single SA means cluster SA? Or sub-SA? If it is cluster SA, what exactly it meant from SAD point of view?=

 

For example, Let us consider the following header, the host is tun= neling a packet to the gateway using ESP but is authenticating to the end h= ost B. How do we address this using your proposed solution SA clustering? If  multiple packets goes throu= gh two different sub-SA’s. here my understanding is two different sub= -SA’s means two separate SA’s are ESP SA and AH SA. Does this m= ean packet go through either ESP SA or AH SA? Please correct me , if I misunderstood.

3D"Bb726946.f4_14=

 

Second point,  About SA cluster feature support, Does both pa= rties need to exchange vendor ID to express support and use of SA cluster f= eature? It would be better to address this in draft including proposed vendor id values, if vendor id used in IKE neg= otiation.

 

Third point, about name of the draft, I feel multiple path sounds = like multiple routes, it does not implies multiple SA’s.

 

Regards,

Dharmanandana Reddy Pothula.

 

 

 

 

   This e-mail and attachments contain co= nfidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contai= ned herein in any way (including, but not limited to, total or partial disc= losure, reproduction, or dissemination) by persons other than the intended = recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email i= mmediately and delete it!

 


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

 

--_000_00E6CDB229A4CF4487D6E0326EDE5A0320A0F572dfweml511mbxchi_-- --_004_00E6CDB229A4CF4487D6E0326EDE5A0320A0F572dfweml511mbxchi_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=2654; creation-date="Fri, 06 Apr 2012 04:44:05 GMT"; modification-date="Fri, 06 Apr 2012 04:44:05 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODdhTwFEAN0AAPz+/AQCBAQGBPz6/ERCRLy6vAwKDGxqbNTS1JyanExKTDQyNMTCxLSytISC hNza3JyenCwqLFxaXGRiZKSipMzKzDw6PISGhHRydJSSlFRWVNTW1ExOTGRmZLS2tFRSVKyqrCwu LIyKjGxubHx+fMzOzPT29Hx6fERGRKSmpNze3JSWlLy+vCQiJCQmJDQ2NDw+PAwODKyurOTi5MTG xOzq7BwaHFxeXIyOjOzu7HR2dPTy9BweHOTm5BQSFBQWFCwAAAAATwFEAAAG/0CAcEgsGo/IpHLJ bDqf0Kh0Sq1ar9isdsvter/gsHhMNg4C6LR6zW673/C4fE6v2+/4vH7P7/v/bEMmBmVbAwKFWwGJ WouMWI6PVgIDQgOEklWXmZOcVZGeUYihUgaVAIOkUZuqUKOtTqCwS69HDyFEDARgBAxNlJaYs0y1 w0nFxkeyyUbIRA8BuEK6SBAHVr1NwiYxzEms3kfO4QDL5ADjQhsRCAvTu0cJ11XZxKfg50PC+ULp 3ubk/D2IUMIdAGoAPKCRAIACmgMZMAhx4EAIhgwADqChIORDAwUFCLAQsgBBElNCuPEbgo+fP2YA w/lbB6DEi4O7CigQkoIhhP8OACJOrAjg4oEEQm6AAMAhgAcABGgAeFFCCTAALc8dWjnkZbKY3gRG AIDgJgMYAHQKAeFzHg4dF0iQuHBCRMYVQiSkAOBRSC8LFZagRNWNa9ZzXo2BZSZWSAUL1BSmuQFA nhARJxyQoKgDB4ARSAFIWPrhKQAYaAJbvbePX+t8iYctTtYYQIUXNHZ52Enkp5C3cefW/Rz6xt6+ UH1RVTJYpeHXiLkKmW1s5lghNALk5LCWsuXLJ4QMzxh6NNMGQmD4Krk6GJEZLgBAUwOPSIoJVxSM hLJ1Cgg2EgHggBoYAdDBGuhNUUsNPAAwwxoWGCEDQ1ZwUIAU1DmxQoATXUD/xAEQYCGQNNOgBUAD aGggBAQBzIOZeB4KcWAAHPGVYFQkmYREc4UJMUMLZJEIAAu8DUEBftj4wh90TfR0xAVEWYTXBDUK YaGCRNRgg3zxDZFbEWzld2EUGTIhj1BCzPVhiFfENstV+PwIwAYGCcFCfTxRZgUK+0HBJBNhGhEX ESNgNAGbVpomSpZbqtAldhESMeEVHCj6RJlLyIMDhxR9GFon0vH4HpA0DcEACkUcmUAAIwxxARp2 CaERjUN8EEBISr6AxgNCtDCDDTkUcViTehbRqRFUEgESlkP00Oh1jpk4BFsOAfUbGlFigManEgTw 0ZioBaBjBCq00IMRmCqx/wJEnMYoI6JVuAkLnPvISScRLKBqXwD4CfUiAMNdlNReGqCHQgAjASZE BLzyEMC5wspLxH9rBDhgALG+S0SlzAqhJQCOEkFDpNMGwJBlaHZ6gmcGhmgcU04llyMALgQwgzJZ WPNbeACQwMan8YIhAglTWFDVSac4J0S5ZK2BZ55CZNDqvzpkLMQEx8kgBJ8AKAwAwwDwALGwfy7h pBI6BFDgBAhSsWCjEBoBgoqVXYPmZkWAKNpSACxbTwgmuaACEuki8d1babrbsohgHBsFe8ew9l58 Gwh5xH1CbAiACGrEOEIaHBW8tS8WqLEBAL7uSEWgS4yAVwfwBj3ExyErMf8pAL5loAbRRaWBlF6J QqVGVWDjfIVDa4TnOHmMfzGoFMshnVKPDgLZzhJHRt0qXUUIDMDLyKFw4QuqDSH2EcMycXYRUBKB wZRVgipEDw0OtESglm1axMoaKyXEsuopguAIhwUIIEkI3FPTEGDXvCTQqQQBIJlk6EYBawmlfQBI WwDwkhQ0JEh4FYAcEug1qjlZzggp0JPm/jWcQgGAbaHTWt8Sphqwpc4MEpsWhdjHOyG4kIENBADt HoWEua0IKCmrSNUyEoDf7YUpT6kHe4qHritgjn2asdpRgniEDQTAHTRAi1oAEKbsBUUigxrPFpNl oxl2LQBH21HSqCen6yn/wYxSQyAa3KURCLyML2nIFRpOF7axESF9ZgPQRAh0tfjJzmP1g1YRKXQ4 NPRQWysAYrfQAC40HG2AxquCGYmgGbwNQW9tWkLlsPM0/B1gBa0SUEXUCLTzAIBrU4mjOCQXKumg w5eFI8VLbuGYSBUgDXT7CZraNx7XddCDfRvTC3Qkx+lJB5GMAaYvX2LHMKZFX67MIwDSGKs11ogD 6JGiLpvBy5X0hys5JEUwQ/ESL7rjMUPaCYroVrchDA1gnoMfADTgrVvux2jMmeM1y5ZN6czTE/UM AQQlGAAOsG5dQziWBjkomgCAgGPCQwM1d+meXkonnqF4KCfqWadMzUMM/6J6zja1edIlIOCEhoul GEhoGJRClKbwXAIxsRcAa40hpu5kKG2AuhKfrvQegIiqVKdK1apa9apYzSogTuHLrnr1q2ANq1jH StaymvWsaE2rWtfK1ra69a1wjatc50rXutr1rnjNq173ytcl1EANkswCG600JiFM0607UAOQuLDF IYhuCDAoX1+HkYMfEOFeW+hA/K4kBMCIMK0DoJ4KAnsF0BDhsckh32SN8bEhrHILg43mEAADOLbu wAdEqJ0WGtuRD6rHa6uFRQ62ZITHUOOYAeBn5tiguBfCC6Rdo8EC1nlWpRGhHfhkABq40xs29FBW HB2oDFNL3eCGogdoIP9iBQIgRt6wzglsWwO4pAKABRBSrYkNQIOGAEGzwKMBH4jC59pmUMOO1Lyt UEEAroPPb1YBiP8zDY4AEIL7svVBi7UjQqbgTMfKUD+GlSyCYXGvBo/RCLpbg9VeGD+/sYFXbx1t TQyy4SKwaA1RkhXQ+nKwNRx4xI8Y7mVxcRshFEBfU4AwFKHSp6/BGK0mwO0QmKZhaUnBtB6W7RCm C2RP1MCyQ7heCYzp3h3Ct8VHbrIQQHnW2z5jLBr+b4ChwFsbLasIIXhylx/x1zQwmGTIVa4TNLsx XBmBim1WrBBuOgQWbFcKddaADBRgqZnt+dKYzrSmN83pTnv606AOtaj/R03qUpv61GrNAWC9EN80 SHgNeq6uorsQafQowMeo1kJlh2A/JDRA0E1Qst+ajGizKo1pSCgAd6GAZSFIum+W+myuqdDaRbdU UnOGQmz9Rt81x7qsbp4yaY287CfUmceFpfCPpx2FXbtWGusNAKokY+YVMLcISuZYPYSQZ7VaV8ZN Y29a0JBt3Hk3b+EV3Z0tzW5qE9fatiEzAGQAbCZs+0LhSoOF2yxlITwgPnFOSJGeMGA1aK3HaShv w5/gbnUQ+SZEALAUZpSGGylpYd8ma5QnF6QinJjk4f2A1hZe33WvvAnVnpNBshMA3lC8CClWw4oP 1ZHx7tvJ+O24fK4Dg0HtCMED5TY4jvMGNNGJjwi1PboUWm5Cn6NK5lEgdG/9Quycj/XfRMRJWkbu hGaLV8sMV/sTqt1rE+uz4ksYbGn80m2spzXc1YP4kHQT9iac22DplrbgmaDqNKgXDfpCkZmbQPUh uNh0azWBGvYrhK6b6JgFt3zZbb0GlW/+9rj/ahAAADs= --_004_00E6CDB229A4CF4487D6E0326EDE5A0320A0F572dfweml511mbxchi_-- From xiangyang.zhang@huawei.com Thu Apr 5 21:44:37 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 0F8B211E80A3 for ; Thu, 5 Apr 2012 21:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=0.807, 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 9II0pkwxxZ7V for ; Thu, 5 Apr 2012 21:44:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAB111E809A for ; Thu, 5 Apr 2012 21:44:35 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEZ78664; Fri, 06 Apr 2012 00:44:35 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 5 Apr 2012 21:44:36 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.128]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.003; Thu, 5 Apr 2012 21:44:32 -0700 From: Xiangyang zhang To: Stephen Kent Thread-Topic: [IPsec] draft-zhang-ipsecme-multi-path-ipsec Thread-Index: AQHNETbnWY8qptfHo0+ep8QVvtAqKJaNF6gAgAAfBWA= Date: Fri, 6 Apr 2012 04:44:31 +0000 Message-ID: <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.142.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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, 06 Apr 2012 04:44:37 -0000 Steve, Your understanding is partially right. Only that anti-replay window could = possibly be bigger if two paths go along the different routes. If two path= s go along the same route, it is no difference from the traditional single = SA. But the attacker does not know two paths carry the same flow of traffi= c. =20 For security consideration, could you point out what is in error? Thanks, Victor -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= tephen Kent Sent: Thursday, April 05, 2012 12:29 PM To: Xiangyang zhang Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec At 1:12 AM +0000 4/3/12, Xiangyang zhang wrote: >A new version of I-D, draft-zhang-ipsecme-multi-path-ipsec-00.txt >has been successfully submitted by Xiangyang Zhang and posted to the=20 >IETF repository. > >Filename: draft-zhang-ipsecme-multi-path-ipsec >Revision: 00 >Title: Multiple Path IP Security >Creation date: 2012-04-02 >WG ID: Individual Submission >Number of pages: 7 > >Abstract: > This document presents one approach to enhance data protection when > transmitting IPsec datagrams across the insecure networks. The method > affords the stronger protection to the traffic by splitting it among > a set of sub-tunnels. All the Security Associations (SAs) are set up > independently for all sub-tunnels. Both the sending and receiving > entity combine all the sub-tunnels to one clustered tunnel. As > different sub-tunnel uses different crypto key materials and > processing parameters, it may achieve the stronger protection of the > traffic across the insecure networks. In addition, it could possibly > bring more benefits in terms of the network control. This seems like a potentially very complex feature that creates added oppor= tunities for packet arrival reordering (of added jitter) without a good ana= lysis of the security rationale. Also, as others have noted, this is not a = "multi-path" feature, but a multi=3D-tunnel feature, so the doc name is ina= ppropriate. The comment on multiple paths in the secruity considerations se= ction is also in error. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From kent@bbn.com Fri Apr 6 07:42: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 BC68F21F855D for ; Fri, 6 Apr 2012 07:42:55 -0700 (PDT) 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 qTUs-lJGVJxn for ; Fri, 6 Apr 2012 07:42:54 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C1F6421F84D6 for ; Fri, 6 Apr 2012 07:42:54 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:46614 helo=[192.168.1.6]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SGAN2-0006tX-1e; Fri, 06 Apr 2012 10:42:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com> Date: Fri, 6 Apr 2012 10:39:22 -0400 To: Xiangyang zhang From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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, 06 Apr 2012 14:42:55 -0000 At 4:44 AM +0000 4/6/12, Xiangyang zhang wrote: >Steve, > >Your understanding is partially right. Only that anti-replay window >could possibly be bigger if two paths go along the different routes. >If two paths go along the same route, it is no difference from the >traditional single SA. But the attacker does not know two paths >carry the same flow of traffic. when you take a sequence of packets and spread them over multiple SAs, you create new opportunities for the packets to arrive out of order at the destination. They have to be merged at the destination, either at the host or at an SG. If they are merged at an SG, new functionality is required to buffer the packets and re-order them. If not, then variances in traffic handling at each end creates new opportunities for reordering or traffic, and/or added jitter. OOO arrival is not good for TCP connections, irrespective of the IPsec anti-replay window. Jitter is also not great, especially for some realtime apps that run over UDP. > For security consideration, could you point out what is in error? your text refers to multiple paths, when you mean multiple SAs. >Thanks, > >Victor From xiangyang.zhang@huawei.com Fri Apr 6 09:50:27 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 13BB021F85C0 for ; Fri, 6 Apr 2012 09:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.605, 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 SvnpfQyXb42y for ; Fri, 6 Apr 2012 09:50:26 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6524121F8531 for ; Fri, 6 Apr 2012 09:50:26 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFA06880; Fri, 06 Apr 2012 12:50:26 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Apr 2012 09:50:16 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.128]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Fri, 6 Apr 2012 09:50:07 -0700 From: Xiangyang zhang To: Stephen Kent Thread-Topic: [IPsec] draft-zhang-ipsecme-multi-path-ipsec Thread-Index: AQHNETbnWY8qptfHo0+ep8QVvtAqKJaNF6gAgAAfBWCAASJaAP//qN3g Date: Fri, 6 Apr 2012 16:50:20 +0000 Message-ID: <00E6CDB229A4CF4487D6E0326EDE5A0320A0F648@dfweml511-mbx.china.huawei.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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, 06 Apr 2012 16:50:27 -0000 Stephen, You understand this method very well. The disadvantage is the possible sev= erity of out of order delivery. Even with single SA, it can also cause the= out of order problem. As for re-order, just like TCP reorder or IP reasse= mbly, it can be done at intermediate node or end host. If it is done at SG= W, RFC 6471 may help to mitigate the issue. In your previous mail, this is potentially very complex feature. As a matt= er of fact, it is simpler comparing with SA bundle in implementation. For = SA bundle with two SAs, it must go through the processing two times. For S= A cluster, packet just needs to be processed one time. Here I do not inten= d to deny the out of order claim.=20 This is another option comparing with SA or SA cluster. The product develo= pers can choose what method they need, or it can be configurable. I submit= ted the draft to see if it exhibits some benefit. It does not intend to be= necessarily absolute better or replace the existing method. Thanks, Victor -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= tephen Kent Sent: Friday, April 06, 2012 7:39 AM To: Xiangyang zhang Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec At 4:44 AM +0000 4/6/12, Xiangyang zhang wrote: >Steve, > >Your understanding is partially right. Only that anti-replay window=20 >could possibly be bigger if two paths go along the different routes. >If two paths go along the same route, it is no difference from the=20 >traditional single SA. But the attacker does not know two paths carry=20 >the same flow of traffic. when you take a sequence of packets and spread them over multiple SAs, you = create new opportunities for the packets to arrive out of order at the dest= ination. They have to be merged at the destination, either at the host or a= t an SG. If they are merged at an SG, new functionality is required to buff= er the packets and re-order them. If not, then variances in traffic handlin= g at each end creates new opportunities for reordering or traffic, and/or a= dded jitter. OOO arrival is not good for TCP connections, irrespective of t= he IPsec anti-replay window. Jitter is also not great, especially for some = realtime apps that run over UDP. > For security consideration, could you point out what is in error? your text refers to multiple paths, when you mean multiple SAs. >Thanks, > >Victor _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From xiangyang.zhang@huawei.com Fri Apr 6 10:06: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 112A021F84F6 for ; Fri, 6 Apr 2012 10:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.484, 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 gYJgNSD-MneQ for ; Fri, 6 Apr 2012 10:06:51 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 356F821F84DD for ; Fri, 6 Apr 2012 10:06:51 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFA07512; Fri, 06 Apr 2012 13:06:50 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 6 Apr 2012 10:04:29 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.128]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Fri, 6 Apr 2012 10:04:13 -0700 From: Xiangyang zhang To: Xiangyang zhang , Stephen Kent Thread-Topic: [IPsec] draft-zhang-ipsecme-multi-path-ipsec Thread-Index: AQHNETbnWY8qptfHo0+ep8QVvtAqKJaNF6gAgAAfBWCAASJaAP//qN3ggAAJsJA= Date: Fri, 6 Apr 2012 17:04:25 +0000 Message-ID: <00E6CDB229A4CF4487D6E0326EDE5A0320A0F676@dfweml511-mbx.china.huawei.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F648@dfweml511-mbx.china.huawei.com> In-Reply-To: <00E6CDB229A4CF4487D6E0326EDE5A0320A0F648@dfweml511-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.34.152] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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, 06 Apr 2012 17:06:52 -0000 Stephen, Your comments arouse my interest in multi-path TCP connection (one connecti= on but multiple paths). I will check the out-of-order issues in that case. Thanks, Victor -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of X= iangyang zhang Sent: Friday, April 06, 2012 9:50 AM To: Stephen Kent Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec Stephen, You understand this method very well. The disadvantage is the possible sev= erity of out of order delivery. Even with single SA, it can also cause the= out of order problem. As for re-order, just like TCP reorder or IP reasse= mbly, it can be done at intermediate node or end host. If it is done at SG= W, RFC 6471 may help to mitigate the issue. In your previous mail, this is potentially very complex feature. As a matt= er of fact, it is simpler comparing with SA bundle in implementation. For = SA bundle with two SAs, it must go through the processing two times. For S= A cluster, packet just needs to be processed one time. Here I do not inten= d to deny the out of order claim.=20 This is another option comparing with SA or SA cluster. The product develo= pers can choose what method they need, or it can be configurable. I submit= ted the draft to see if it exhibits some benefit. It does not intend to be= necessarily absolute better or replace the existing method. Thanks, Victor -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= tephen Kent Sent: Friday, April 06, 2012 7:39 AM To: Xiangyang zhang Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec At 4:44 AM +0000 4/6/12, Xiangyang zhang wrote: >Steve, > >Your understanding is partially right. Only that anti-replay window=20 >could possibly be bigger if two paths go along the different routes. >If two paths go along the same route, it is no difference from the=20 >traditional single SA. But the attacker does not know two paths carry=20 >the same flow of traffic. when you take a sequence of packets and spread them over multiple SAs, you = create new opportunities for the packets to arrive out of order at the dest= ination. They have to be merged at the destination, either at the host or a= t an SG. If they are merged at an SG, new functionality is required to buff= er the packets and re-order them. If not, then variances in traffic handlin= g at each end creates new opportunities for reordering or traffic, and/or a= dded jitter. OOO arrival is not good for TCP connections, irrespective of t= he IPsec anti-replay window. Jitter is also not great, especially for some = realtime apps that run over UDP. > For security consideration, could you point out what is in error? your text refers to multiple paths, when you mean multiple SAs. >Thanks, > >Victor _______________________________________________ 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 Apr 9 04:23: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 4F12F21F865B for ; Mon, 9 Apr 2012 04:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.103 X-Spam-Level: X-Spam-Status: No, score=-106.103 tagged_above=-999 required=5 tests=[AWL=-0.496, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, 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 T2NW261in1vc for ; Mon, 9 Apr 2012 04:23:43 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id CE19621F865A for ; Mon, 9 Apr 2012 04:23:43 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:60966 helo=[10.5.22.111]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHCgs-000G9N-G1; Mon, 09 Apr 2012 07:23:22 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <00E6CDB229A4CF4487D6E0326EDE5A0320A0F648@dfweml511-mbx.china.huawei.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F648@dfweml511-mbx.china.huawei.com> Date: Sun, 8 Apr 2012 10:27:19 -0400 To: Xiangyang zhang From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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 Apr 2012 11:23:44 -0000 At 4:50 PM +0000 4/6/12, Xiangyang zhang wrote: >Stephen, > >You understand this method very well. The disadvantage is the >possible severity of out of order delivery. Even with single SA, it >can also cause the out of order problem. As for re-order, just like >TCP reorder or IP reassembly, it can be done at intermediate node or >end host. The TCP and IP specs do not envision an intermediary trying to put packets back in order or performing reassembly. When middle bioxes do this performance often suffers. > If it is done at SGW, RFC 6471 may help to mitigate the issue. >In your previous mail, this is potentially very complex feature. As >a matter of fact, it is simpler comparing with SA bundle in >implementation. For SA bundle with two SAs, it must go through the >processing two times. For SA cluster, packet just needs to be >processed one time. Here I do not intend to deny the out of order >claim. note that 4301 removed the requirement to support SA bundles, so the comparison seems out of place. >This is another option comparing with SA or SA cluster. The product >developers can choose what method they need, or it can be >configurable. I submitted the draft to see if it exhibits some >benefit. It does not intend to be necessarily absolute better or >replace the existing method. as I noted in prior messages, this seems awfully complex and has the potential to degrade performance, so a very string secruity argument needs to be made to justify considering this proposal. I have not seen that argument. Steve From Paul_Koning@Dell.com Mon Apr 9 07:49: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 2C59A21F873D for ; Mon, 9 Apr 2012 07:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 VUEq4iJ-ZojW for ; Mon, 9 Apr 2012 07:49:37 -0700 (PDT) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id A551821F873C for ; Mon, 9 Apr 2012 07:49:37 -0700 (PDT) X-Loopcount0: from 10.175.216.249 From: To: , Date: Mon, 9 Apr 2012 09:49:34 -0500 Thread-Topic: [IPsec] draft-zhang-ipsecme-multi-path-ipsec Thread-Index: Ac0WQzvt7tgnciOuREmUMvjoHij5jQAHIzjg Message-ID: <09787EF419216C41A903FD14EE5506DD0313D9EB11@AUSX7MCPC103.AMER.DELL.COM> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F648@dfweml511-mbx.china.huawei.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 Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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 Apr 2012 14:49:38 -0000 >At 4:50 PM +0000 4/6/12, Xiangyang zhang wrote: >>>Stephen, >> >>You understand this method very well. The disadvantage is the possible=20 >>severity of out of order delivery. Even with single SA, it can also=20 >>cause the out of order problem. As for re-order, just like TCP reorder=20 >>or IP reassembly, it can be done at intermediate node or end host. > >The TCP and IP specs do not envision an intermediary trying to put packets= back in order or performing reassembly. When middle bioxes do this perform= ance often suffers. In fact, reassembly at intermediate nodes is not possible at all, because I= P can route packets on several routes. The full stream of packets is only = available at the end points, so that is the only place where reassembly can= be done. paul From mglt.ietf@gmail.com Mon Apr 9 11:08: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 3213B21F875E for ; Mon, 9 Apr 2012 11:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ge+yMzacmL7 for ; Mon, 9 Apr 2012 11:08:43 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2008821F879C for ; Mon, 9 Apr 2012 11:08:43 -0700 (PDT) Received: by iazz13 with SMTP id z13so7467601iaz.31 for ; Mon, 09 Apr 2012 11:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HGBZS2P9r8saInLey8cLZ4uc3F7YRw3bPPTpj/r4DLc=; b=ofdWItA+qNwkH2TvICNKTo1DoI0SmmmZQOHPmGFTopgWSouhkOtFdcm50cX4x1HL12 bmEuORoxHHJlYg5uU8bWCGyiILOF6z7WZDQ9GUHeD/UCuoKsK3p22SsnYlyvW+aWW7vS eoDuBhyftCYNHyi+NLFy5bbzZYIxVgqf0I/4osCPqzaVBtbF/udvXU6pf2U6FjI7XXO1 I9+78YTY17cNrTaGDdjJJ1qJJlXtRFfQ7m3Y1cneSnOESWUjL8brTFncTNJo5CUxfcQo yAZl7JPvWItJP+DNlEPLRKb+yYk97Fn34DDmPwCVOXYoCJQTZID6xyqF6i2e9mL1N20B 1HtA== MIME-Version: 1.0 Received: by 10.42.157.65 with SMTP id c1mr4834290icx.6.1333994922769; Mon, 09 Apr 2012 11:08:42 -0700 (PDT) Received: by 10.231.170.138 with HTTP; Mon, 9 Apr 2012 11:08:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Apr 2012 20:08:42 +0200 Message-ID: From: Daniel Migault To: Yoav Nir Content-Type: multipart/alternative; boundary=90e6ba6e8d3a80fea504bd42e5da Cc: IPsecme WG Subject: Re: [IPsec] SPI Collision X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 18:08:44 -0000 --90e6ba6e8d3a80fea504bd42e5da Content-Type: text/plain; charset=ISO-8859-1 Hi Yoav, Thank you very much for your answer. It does fully answer my question! BR, Daniel On Thu, Apr 5, 2012 at 9:15 PM, Yoav Nir wrote: > Hi Daniel > > On Apr 5, 2012, at 9:22 PM, Daniel Migault wrote: > > > Hi, > > > > I am wondering how SPI collision is considered by IKEv2, and have not > found any documentation on it, so if there are some, please let me know. > > > > My current understanding is that when an CREATE_CHILD_SA exchange is > performed the Initiator and Responder announce the SPI in the SA payload. > If the Initiator announces an SPI that is already used by the Responder > (with another peer), the Responder cannot accept this proposition and must > send an error message. I haven't found anything like this in RFC5996. Am I > missing something ? > > > > Furthermore I cannot find any message for this error. INVALID_SPI does > not seems to be used for the creating of an SPI, but only if an ESP/AH/IKE > packet comes with an unrecognized SPI. In addition it seems the Notify > Payload MUST be sent out of the IKE_SA.... Can anyone tell me which error > message is used? > > > > BR > > Daniel > > In IKE (both v1 and v2) it's always two IPsec SAs that are negotiated at > the same time. Each side sends in its CCSA message the SPI for the inbound > SA. So for traffic going from the initiator to the responder, it's the > responder that chooses the SPI, while for traffic going from the responder > to the initiator, the initiator chooses the SPI. This allows both peers to > make sure that inbound SAs have unique SPIs. > > The same guarantee cannot be made for outbound traffic. The SPI for > outbound traffic is chosen by the peer, and one particular implementation > that I'm aware of assigns them serially, so with many peers like that, you > have a high chance of collision. The fact is that it is usually not a > problem. In outbound IPsec processing the stack sees the cleartext packet, > chooses an SA based on attributes of the packet, and constructs the > protected packet based on encryption keys, MAC keys, the replay counter and > the SPI which are part of the SA. The SPI is a value, not a key in the > table of outbound SAs, so there's no harm done even if all the outbound SAs > have the same SPI. > > This is different from the inbound case, where the SPI is used as a key to > the SA table, and therefore has to be unique. > > Hope this helps > > Yoav > > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --90e6ba6e8d3a80fea504bd42e5da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yoav,

Thank you very much for your answer. It does fully answer = my question!

BR,

Daniel

On= Thu, Apr 5, 2012 at 9:15 PM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi Daniel

On Apr 5, 2012, at 9:22 PM, Daniel Migault wrote:

> Hi,
>
> I am wondering how SPI collision is considered by IKEv2, and have not = found any documentation on it, so if there are some, please let me know. >
> My current understanding is that when an CREATE_CHILD_SA exchange is p= erformed the Initiator and Responder announce the SPI in the SA payload. If= the Initiator announces an SPI that is already used by the Responder (with= another peer), the Responder cannot accept this proposition and must send = an error message. I haven't found anything like this in RFC5996. Am I m= issing something ?
>
> Furthermore I cannot find any message for this error. INVALID_SPI does= not seems to be used for the creating of an SPI, but only if an ESP/AH/IKE= packet comes with an unrecognized SPI. In addition it seems the Notify Pay= load MUST be sent out of the IKE_SA.... Can anyone tell me which error mess= age is used?
>
> BR
> Daniel

In IKE (both v1 and v2) it's always two IPsec SAs that are = negotiated at the same time. Each side sends in its CCSA message the SPI fo= r the inbound SA. So for traffic going from the initiator to the responder,= it's the responder that chooses the SPI, while for traffic going from = the responder to the initiator, the initiator chooses the SPI. This allows = both peers to make sure that inbound SAs have unique SPIs.

The same guarantee cannot be made for outbound traffic. The SPI for outboun= d traffic is chosen by the peer, and one particular implementation that I&#= 39;m aware of assigns them serially, so with many peers like that, you have= a high chance of collision. The fact is that it is usually not a problem. = In outbound IPsec processing the stack sees the cleartext packet, chooses a= n SA based on attributes of the packet, and constructs the protected packet= based on encryption keys, MAC keys, the replay counter and the SPI which a= re part of the SA. The SPI is a value, not a key in the table of outbound S= As, so there's no harm done even if all the outbound SAs have the same = SPI.

This is different from the inbound case, where the SPI is used as a key to = the SA table, and therefore has to be unique.

Hope this helps

Yoav




--
Daniel Mi= gault
Orange Labs -- Security
+33 6 70 72 69 58
--90e6ba6e8d3a80fea504bd42e5da-- From kent@bbn.com Mon Apr 9 14:53: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 9075221F87EF for ; Mon, 9 Apr 2012 14:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.475 X-Spam-Level: X-Spam-Status: No, score=-106.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 yGERWx6eVXvn for ; Mon, 9 Apr 2012 14:53:12 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A8CFA21F87E3 for ; Mon, 9 Apr 2012 14:53:12 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:34952 helo=[10.5.23.166]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHMW2-0006SN-Qw; Mon, 09 Apr 2012 17:52:51 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <09787EF419216C41A903FD14EE5506DD0313D9EB11@AUSX7MCPC103.AMER.DELL.COM> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F648@dfweml511-mbx.china.huawei.com> <09787EF419216C41A903FD14EE5506DD0313D9EB11@AUSX7MCPC103.AMER.DELL.COM> Date: Mon, 9 Apr 2012 17:50:28 -0400 To: From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: xiangyang.zhang@huawei.com, ipsec@ietf.org Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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 Apr 2012 21:53:13 -0000 At 9:49 AM -0500 4/9/12, wrote: > >At 4:50 PM +0000 4/6/12, Xiangyang zhang wrote: >>>>Stephen, >>> >>>You understand this method very well. The disadvantage is the possible >>>severity of out of order delivery. Even with single SA, it can also >>>cause the out of order problem. As for re-order, just like TCP reorder >>>or IP reassembly, it can be done at intermediate node or end host. >> >>The TCP and IP specs do not envision an intermediary trying to put >>packets back in order or performing reassembly. When middle bioxes >>do this performance often suffers. > >In fact, reassembly at intermediate nodes is not possible at all, >because IP can route packets on several routes. The full stream of >packets is only available at the end points, so that is the only >place where reassembly can be done. > > paul Paul, I agree in general, but I was considering the case where the intermediate node is very enough to the destination. Steve From xiangyang.zhang@huawei.com Mon Apr 9 15:12: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 9B53121F87CF for ; Mon, 9 Apr 2012 15:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.196 X-Spam-Level: X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.404, 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 4eeoCrOoaG+y for ; Mon, 9 Apr 2012 15:12:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA5321F87AE for ; Mon, 9 Apr 2012 15:12:37 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFB89894; Mon, 09 Apr 2012 18:12:36 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 15:11:35 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.128]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 15:11:23 -0700 From: Xiangyang zhang To: Stephen Kent Thread-Topic: [IPsec] draft-zhang-ipsecme-multi-path-ipsec Thread-Index: AQHNETbnWY8qptfHo0+ep8QVvtAqKJaNF6gAgAAfBWCAASJaAP//qN3ggAN4b4CAAX3SsA== Date: Mon, 9 Apr 2012 22:11:22 +0000 Message-ID: <00E6CDB229A4CF4487D6E0326EDE5A0320A0FAD1@dfweml511-mbx.china.huawei.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F648@dfweml511-mbx.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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 Apr 2012 22:12:44 -0000 Steve Even though TCP or IP does not envision it, the ordered processing is very = common now. In an intermediary node, IP reassembly and TCP reorder must be= done some time. In flow-based technology (for example, stateful firewall)= , without IP reassembly, it could not work. You know flow is based on 5 tu= ples, non-first fragments has no TCP or UDP port information in it. Withou= t IP reassembly, the only way is to drop the packet. No customer will acce= pt this kind of network product.=20 In NAT device, no matter it is large scale (LSN) or others, it could break = some application like FTP, VOIP etc. TCP payload must be extracted. If TC= P segments do not arrive in order, it must wait for it. In our GGSN produc= t, there are also some cases where TCP reorder must be done. Just like TCP/IP, the ordered arrival is not a requirement. This is simila= r to IPsec. Please check my comments inline starting with "victor>". Thanks, Victor -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= tephen Kent Sent: Sunday, April 08, 2012 7:27 AM To: Xiangyang zhang Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec At 4:50 PM +0000 4/6/12, Xiangyang zhang wrote: >Stephen, > >You understand this method very well. The disadvantage is the possible=20 >severity of out of order delivery. Even with single SA, it can also=20 >cause the out of order problem. As for re-order, just like TCP reorder=20 >or IP reassembly, it can be done at intermediate node or end host. The TCP and IP specs do not envision an intermediary trying to put packets = back in order or performing reassembly. When middle bioxes do this performa= nce often suffers. Victor> Current network is much more complicated than old one. It could no= t be avoided in some situation even though you do not want to do that. =20 > If it is done at SGW, RFC 6471 may help to mitigate the issue. >In your previous mail, this is potentially very complex feature. As a=20 >matter of fact, it is simpler comparing with SA bundle in=20 >implementation. For SA bundle with two SAs, it must go through the=20 >processing two times. For SA cluster, packet just needs to be=20 >processed one time. Here I do not intend to deny the out of order=20 >claim. note that 4301 removed the requirement to support SA bundles, so the compar= ison seems out of place. Victor> I note that too. If we do not compare SA bundle and cluster, we ca= n just compare SA and SA cluster. The later is an option to enhance the se= curity. >This is another option comparing with SA or SA cluster. The product=20 >developers can choose what method they need, or it can be configurable. =20 >I submitted the draft to see if it exhibits some benefit. It does not=20 >intend to be necessarily absolute better or replace the existing=20 >method. as I noted in prior messages, this seems awfully complex and has the potent= ial to degrade performance, so a very string secruity argument needs to be = made to justify considering this proposal. I have not seen that argument. Victor> I do not want to deny that it has the potential to degrade the perf= ormance. But I want to say it also has the potential to improve the perfor= mance, for example, when congestion happens. This is why multi-path TCP co= mes into picture. SA cluster should not be awfully complex. If there are two SA, it just gro= up them together. I implemented one IPsec stack before. If I update the co= de, it does not need much change at both sending side and receiving side. = If you see it is awfully complex, how do you come to that conclusion? I use SA bundle as an example, just want to say that it is simpler than SA = bundle. And the performance should be better in most cases. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From xiangyang.zhang@huawei.com Mon Apr 9 15:15: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 D662E21F87F7 for ; Mon, 9 Apr 2012 15:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.253 X-Spam-Level: X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=0.346, 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 oy+m+ShuMsAD for ; Mon, 9 Apr 2012 15:15:59 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BC01A21F87F4 for ; Mon, 9 Apr 2012 15:15:58 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFB90054; Mon, 09 Apr 2012 18:15:57 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 15:14:02 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.128]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 15:14:03 -0700 From: Xiangyang zhang To: "Paul_Koning@Dell.com" , "kent@bbn.com" Thread-Topic: [IPsec] draft-zhang-ipsecme-multi-path-ipsec Thread-Index: AQHNETbnWY8qptfHo0+ep8QVvtAqKJaNF6gAgAAfBWCAASJaAP//qN3ggAN4b4CAAZiMAIAABhqw Date: Mon, 9 Apr 2012 22:14:02 +0000 Message-ID: <00E6CDB229A4CF4487D6E0326EDE5A0320A0FADF@dfweml511-mbx.china.huawei.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F648@dfweml511-mbx.china.huawei.com> <09787EF419216C41A903FD14EE5506DD0313D9EB11@AUSX7MCPC103.AMER.DELL.COM> In-Reply-To: <09787EF419216C41A903FD14EE5506DD0313D9EB11@AUSX7MCPC103.AMER.DELL.COM> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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 Apr 2012 22:16:00 -0000 Paul, The packets or fragments can go different route, but there is aggregate poi= nt where assembly could be done. For example, usually firewall/IPsec are i= ntegrated in the same network device. And reassembly must be done when flo= w-based processing comes into picture. Thanks, Victor -----Original Message----- From: Paul_Koning@Dell.com [mailto:Paul_Koning@Dell.com]=20 Sent: Monday, April 09, 2012 7:50 AM To: kent@bbn.com; Xiangyang zhang Cc: ipsec@ietf.org Subject: RE: [IPsec] draft-zhang-ipsecme-multi-path-ipsec >At 4:50 PM +0000 4/6/12, Xiangyang zhang wrote: >>>Stephen, >> >>You understand this method very well. The disadvantage is the=20 >>possible severity of out of order delivery. Even with single SA, it=20 >>can also cause the out of order problem. As for re-order, just like=20 >>TCP reorder or IP reassembly, it can be done at intermediate node or end = host. > >The TCP and IP specs do not envision an intermediary trying to put packets= back in order or performing reassembly. When middle bioxes do this perform= ance often suffers. In fact, reassembly at intermediate nodes is not possible at all, because I= P can route packets on several routes. The full stream of packets is only = available at the end points, so that is the only place where reassembly can= be done. paul From xiangyang.zhang@huawei.com Mon Apr 9 15:20: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 3063621F87F8 for ; Mon, 9 Apr 2012 15:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.303, 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 ugKFl8CkdsAn for ; Mon, 9 Apr 2012 15:20:44 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAB221F87F7 for ; Mon, 9 Apr 2012 15:20:44 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AET90326; Mon, 09 Apr 2012 18:20:44 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Apr 2012 15:18:13 -0700 Received: from dfweml511-mbx.china.huawei.com ([169.254.16.128]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Mon, 9 Apr 2012 15:17:49 -0700 From: Xiangyang zhang To: Stephen Kent , "Paul_Koning@Dell.com" Thread-Topic: [IPsec] draft-zhang-ipsecme-multi-path-ipsec Thread-Index: AQHNETbnWY8qptfHo0+ep8QVvtAqKJaNF6gAgAAfBWCAASJaAP//qN3ggAN4b4CAAZiMAIAAdZkA//+RfIA= Date: Mon, 9 Apr 2012 22:18:14 +0000 Message-ID: <00E6CDB229A4CF4487D6E0326EDE5A0320A0FAEC@dfweml511-mbx.china.huawei.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F648@dfweml511-mbx.china.huawei.com> <09787EF419216C41A903FD14EE5506DD0313D9EB11@AUSX7MCPC103.AMER.DELL.COM> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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 Apr 2012 22:20:45 -0000 That is also the common case. When you want to offload something for desti= nation, you have to do IP reassembly. -----Original Message----- From: Stephen Kent [mailto:kent@bbn.com]=20 Sent: Monday, April 09, 2012 2:50 PM To: Paul_Koning@Dell.com Cc: Xiangyang zhang; ipsec@ietf.org Subject: RE: [IPsec] draft-zhang-ipsecme-multi-path-ipsec At 9:49 AM -0500 4/9/12, wrote: > >At 4:50 PM +0000 4/6/12, Xiangyang zhang wrote: >>>>Stephen, >>> >>>You understand this method very well. The disadvantage is the=20 >>>possible severity of out of order delivery. Even with single SA, it=20 >>>can also cause the out of order problem. As for re-order, just like=20 >>>TCP reorder or IP reassembly, it can be done at intermediate node or end= host. >> >>The TCP and IP specs do not envision an intermediary trying to put=20 >>packets back in order or performing reassembly. When middle bioxes do=20 >>this performance often suffers. > >In fact, reassembly at intermediate nodes is not possible at all,=20 >because IP can route packets on several routes. The full stream of=20 >packets is only available at the end points, so that is the only place=20 >where reassembly can be done. > > paul Paul, I agree in general, but I was considering the case where the intermediate n= ode is very enough to the destination. Steve From kent@bbn.com Wed Apr 11 00:55:24 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 8391711E809F for ; Wed, 11 Apr 2012 00:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 mQQKDKOfkuNp for ; Wed, 11 Apr 2012 00:55:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C66B711E808C for ; Wed, 11 Apr 2012 00:55:23 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:52325 helo=[172.31.27.154]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SHsOI-000CTf-45; Wed, 11 Apr 2012 03:54:59 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <00E6CDB229A4CF4487D6E0326EDE5A0320A0FAD1@dfweml511-mbx.china.huawei.com> References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F648@dfweml511-mbx.china.huawei.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0FAD1@dfweml511-mbx.china.huawei.com> Date: Wed, 11 Apr 2012 03:55:02 -0400 To: Xiangyang zhang From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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 Apr 2012 07:55:24 -0000 At 10:11 PM +0000 4/9/12, Xiangyang zhang wrote: >Steve > >Even though TCP or IP does not envision it, the ordered processing >is very common now. In an intermediary node, IP reassembly and TCP >reorder must be done some time. In flow-based technology (for >example, stateful firewall), without IP reassembly, it could not >work. You know flow is based on 5 tuples, non-first fragments has >no TCP or UDP port information in it. Without IP reassembly, the >only way is to drop the packet. No customer will accept this kind >of network product. and yet there are adverse affects ... >In NAT device, no matter it is large scale (LSN) or others, it could >break some application like FTP, VOIP etc. TCP payload must be >extracted. If TCP segments do not arrive in order, it must wait for >it. In our GGSN product, there are also some cases where TCP >reorder must be done. you're giving examples of intermediate nodes doing things that can cause problems. >Just like TCP/IP, the ordered arrival is not a requirement. This is >similar to IPsec. IPsec does not intrinsically reorder packets. At worst is may discard packets that arrived very much out of order, a situation where TCP probably would have requested retransmission anyway. >Please check my comments inline starting with "victor>". >... > >The TCP and IP specs do not envision an intermediary trying to put >packets back in order or performing reassembly. When middle bioxes >do this performance often suffers. > >Victor> Current network is much more complicated than old one. It >could not be avoided in some situation even though you do not want >to do that. You're creating new opportunities to make the problem worse. > >... > >note that 4301 removed the requirement to support SA bundles, so the >comparison seems out of place. > >Victor> I note that too. If we do not compare SA bundle and >cluster, we can just compare SA and SA cluster. The later is an >option to enhance the security. You say that, but you have failed to provide any analysis to support this claim. >... > >as I noted in prior messages, this seems awfully complex and has the >potential to degrade performance, so a very string secruity argument >needs to be made to justify considering this proposal. I have not >seen that argument. > >Victor> I do not want to deny that it has the potential to degrade >the performance. But I want to say it also has the potential to >improve the performance, for example, when congestion happens. This >is why multi-path TCP comes into picture. pick an argument and stick with it :-). when this began you didn't seem to know about multi-path TCP, so your proposal can't be assuming its use. >SA cluster should not be awfully complex. If there are two SA, it >just group them together. I implemented one IPsec stack before. If >I update the code, it does not need much change at both sending side >and receiving side. If you see it is awfully complex, how do you >come to that conclusion? I have watched a number of vendors produce non-compliant IPsec implementations since I wrote 2301. That perspective provides me with a basis for arguing that this proposal adds complexity for questionable benefit. >I use SA bundle as an example, just want to say that it is simpler >than SA bundle. And the performance should be better in most cases. SA bundles were removed because most vendors felt they were too complex and did not offer enough benefits. So, saying that this proposal is simpler than SA bundles does not make it simple :-). Steve From rja.lists@gmail.com Wed Apr 11 16:16: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 47B2611E8106 for ; Wed, 11 Apr 2012 16:16:45 -0700 (PDT) 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 tth2TyHuLUrE for ; Wed, 11 Apr 2012 16:16:44 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B43A411E8102 for ; Wed, 11 Apr 2012 16:16:44 -0700 (PDT) Received: by qaea16 with SMTP id a16so1126134qae.10 for ; Wed, 11 Apr 2012 16:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=Z5CfTeoyLDT3G1s1fUZk53l45xx2MBlYpd77myJEPB4=; b=vWb7OiZTHffv4iUn6WcGR88fvj39s5MqrwEcKpzCDEH+P1YZSahTwaTdGw3fpcoT3i NPDzw3F90aHjje82r5IYvcvFZ2/4O53NDwg+wqCqO1PfFDGgJQmhNvBs95yfgekAr9nD wfR7vmZOuD+Kxrcf2PRNeqvJLfcSLzgJ6lMYI4hzh/rTESQSdf54615a0Z/ToLGg8M0G kmwl2W7Zj50S7BKUmgEJTHlYUUsyK/SU8buC5a0wx9e3QPSqWF0bxhAitltsIMiasasn i75CCV5stCRoZ7BvvFTyZIFZkxOIhcLOJiDlKCCxoN2T9m0gEEln2DtEPPcPwxsNfUS2 k6Rw== Received: by 10.224.181.197 with SMTP id bz5mr1014066qab.64.1334186204284; Wed, 11 Apr 2012 16:16:44 -0700 (PDT) Received: from [10.30.20.8] (pool-96-225-134-175.nrflva.fios.verizon.net. [96.225.134.175]) by mx.google.com with ESMTPS id i12sm8323881qad.9.2012.04.11.16.16.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 Apr 2012 16:16:43 -0700 (PDT) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 11 Apr 2012 19:16:42 -0400 Message-Id: To: IPsec ME WG List Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec 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 Apr 2012 23:16:45 -0000 I agree with Steve Kent's recent postings about this draft. Ran From kivinen@iki.fi Thu Apr 12 05:08: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 2519B21F8661 for ; Thu, 12 Apr 2012 05:08:04 -0700 (PDT) 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 zVW6--N5ez1b for ; Thu, 12 Apr 2012 05:08:03 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C4321F865E for ; Thu, 12 Apr 2012 05:08:02 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.3) with ESMTP id q3CC7wnW007713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Apr 2012 15:07:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q3CC7vf8007744; Thu, 12 Apr 2012 15:07:57 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20358.50589.522227.111165@fireball.kivinen.iki.fi> Date: Thu, 12 Apr 2012 15:07:57 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 8 min Cc: ipsec@ietf.org Subject: [IPsec] IKEv2-only implementation question 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, 12 Apr 2012 12:08:04 -0000 Scott C Moonen writes: > I'm curious how IKEv2-only implementations have approached the problem of > dealing with IKEv1 proposals. IKEv2 defines an INVALID_MAJOR_VERSION > notify, but it only carries a maximum version and not a minimum version. (I > wonder if that is an oversight.) IKEv1 (in RFC 2408) defines an > INVALID-MAJOR-VERSION notify which MAY be sent. The RFC does not discuss > whether the notify carries any data. If you have IKEv2-only implementation then you do not support IKEv1, thus you cannot really even parse incoming IKEv1 messages or generate response IKEv1 messages, so most likely you should silently discard the packet. > If I wanted to send an "IKEv1 not supported" indication from an IKEv2-only > daemon, I think I would use the IKEv1 INVALID-MAJOR-VERSION notify and not > send any SPI or notification data in the payload. I.e. you implement minimal IKEv1 implementation in your IKEv2-only implementation which knows how to get IKEv1 packet in, and response to it that INVALID-MAJOR-VERSION in IKEv1. > How have existing IKEv2-only implementations approached this? Do you ignore > IKEv1 messages, or do you send an error notification in response? In our case we do response with the same protocol (i.e if incoming messages are in IKEv1, we reply with IKEv1). As our implementation also do support IKEv1, even when it is disabled by policy, we do not answer with INVALID-MAJOR-VERSION. In our case we just reply with similar error which we use when the policy does not match (NO-PROPOSAL-CHOSEN), i.e. we interpret the IKE version as part of the policy, just as encryption algorithm etc would be. For your case if you really have IKEv2-only implementation, I do not think there is any good interoperable way to solve the issue. Most likely sending the minimal IKEv1 reply with INVALID-MAJOR-VERSION would be best, as at least that can be parsed by the initiator sending IKEv1 messages, and will most likely be shown in the logs, so adminstrators can then reconfigure the system to try with IKEv2, provided the implementation supports IKEv2. On the other hand if the implementation supports IKEv2, it should first try with that as there is clearly defined fall-back mechanims from IKEv2 to IKEv1. -- kivinen@iki.fi From ynir@checkpoint.com Thu Apr 12 11:18: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 EBC2921F8565 for ; Thu, 12 Apr 2012 11:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.573 X-Spam-Level: X-Spam-Status: No, score=-10.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 jQbUqQyCSKlJ for ; Thu, 12 Apr 2012 11:18:01 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 092AF21F8549 for ; Thu, 12 Apr 2012 11:18:00 -0700 (PDT) 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 q3CIHqZJ022096; Thu, 12 Apr 2012 21:17:53 +0300 X-CheckPoint: {4F872980-0-1B221DC2-5FFFF} 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; Thu, 12 Apr 2012 21:17:53 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 12 Apr 2012 21:17:51 +0300 From: Yoav Nir To: IPsecme WG Date: Thu, 12 Apr 2012 21:17:55 +0300 Thread-Topic: New Version Notification for draft-nir-ipsecme-erx-03.txt Thread-Index: Ac0Y2JIQ+WA/GRm5RjO3ZfR3jtCvgg== Message-ID: References: <20120412103348.32017.74969.idtracker@ietfa.amsl.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 x-cpdlp: 11144766674384544fc4a779f15666ac35567120a0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: Qin Wu Subject: [IPsec] Fwd: New Version Notification for draft-nir-ipsecme-erx-03.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, 12 Apr 2012 18:18:02 -0000 Hi all. This is the 3rd iteration of the draft I presented about in Paris. We would like this working group to accept this, and have it added to chart= er. Of course, if it gets accepted, we volunteer to be authors. If it is no= t accepted, we will try to progress it as an individual submission, but we = believe that this changes IKE enough that it should come from the working g= roup. Yoav & Qin Begin forwarded message: > From: "internet-drafts@ietf.org" > Subject: New Version Notification for draft-nir-ipsecme-erx-03.txt > Date: April 12, 2012 1:33:48 PM GMT+03:00 > To: Yoav Nir > Cc: "sunseawq@huawei.com" >=20 > A new version of I-D, draft-nir-ipsecme-erx-03.txt has been successfully = submitted by Yoav Nir and posted to the IETF repository. >=20 > Filename: draft-nir-ipsecme-erx > Revision: 03 > Title: An IKEv2 Extension for Supporting ERP > Creation date: 2012-04-12 > WG ID: Individual Submission > Number of pages: 7 >=20 > Abstract: > This document describes an extension to the IKEv2 protocol that > allows an IKE Security Association (SA) to be created and > authenticated using the EAP Re-authentication Protocol extension as > described in RFC 5296bis. >=20 > NOTE TO RFC EDITOR: Replace 5296bis in the previous paragraph with > the RFC number assigned to that document. From paul.hoffman@vpnc.org Thu Apr 12 12:31: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 EE0B421F863E for ; Thu, 12 Apr 2012 12:31:30 -0700 (PDT) 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 cNOzuwQWJTqt for ; Thu, 12 Apr 2012 12:31:30 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 71FFF21F85D7 for ; Thu, 12 Apr 2012 12:31:30 -0700 (PDT) Received: from [10.20.30.105] (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 q3CJVREx086533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Apr 2012 12:31:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 12 Apr 2012 12:31:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8F2229FE-1995-41F5-AF49-FB5C221C9C85@vpnc.org> References: <20120412103348.32017.74969.idtracker@ietfa.amsl.com> To: IPsecme WG X-Mailer: Apple Mail (2.1257) Subject: Re: [IPsec] New Version Notification for draft-nir-ipsecme-erx-03.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, 12 Apr 2012 19:31:31 -0000 On Apr 12, 2012, at 11:17 AM, Yoav Nir wrote: > We would like this working group to accept this, and have it added to = charter. Of course, if it gets accepted, we volunteer to be authors. If = it is not accepted, we will try to progress it as an individual = submission, but we believe that this changes IKE enough that it should = come from the working group. Statements of interest and disinterest on this document are welcome. If = you prefer to make such a statement off-list please send it to me or = Yaron. A statement of interest that include a promise to review in WG LC count = for more than a bare statement of interest. --Paul Hoffman From paul@nohats.ca Sat Apr 14 18:07: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 6F91D21F84C9 for ; Sat, 14 Apr 2012 18:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=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 FgLwdaAOJwDy for ; Sat, 14 Apr 2012 18:07:25 -0700 (PDT) Received: from letoams.cypherpunks.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) by ietfa.amsl.com (Postfix) with ESMTP id 52E4021F84C5 for ; Sat, 14 Apr 2012 18:07:24 -0700 (PDT) Received: by letoams.cypherpunks.ca (Postfix, from userid 500) id 66AC280348; Sat, 14 Apr 2012 21:07:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id 5845E80331 for ; Sat, 14 Apr 2012 21:07:23 -0400 (EDT) Date: Sat, 14 Apr 2012 21:07:23 -0400 (EDT) From: Paul Wouters To: IPsecme WG Message-ID: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [IPsec] looking for someone who can read/interpret Cisco vpn logs 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, 15 Apr 2012 01:07:26 -0000 Hi, I'm trying to figure out an interop issue with a Cisco device, but can't make head or tails from the cisco logs. If there is anyone on this list could help me interpret such losgs, please contact me off list. Thanks, Paul From nick@inex.ie Mon Apr 16 03:52: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 2F23F21F8704 for ; Mon, 16 Apr 2012 03:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.171 X-Spam-Level: X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.429, 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 OkQWopg-4yrf for ; Mon, 16 Apr 2012 03:52:44 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id A125521F8725 for ; Mon, 16 Apr 2012 03:52:43 -0700 (PDT) X-Envelope-To: Received: from vpn-251.int.inex.ie (vpn-251.int.inex.ie [193.242.111.251]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q3GAqULZ098465 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 16 Apr 2012 11:52:32 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4F8BFA0E.4080006@inex.ie> Date: Mon, 16 Apr 2012 11:53:02 +0100 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: ipsec@ietf.org X-Enigmail-Version: 1.4 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [IPsec] draft-bhatia-moving-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, 16 Apr 2012 10:52:47 -0000 I'd like to add a voice of support to this draft. AH adds little except complication to ipsec implementations and confusion to end users. Regarding ipv4 NATs, they are ubiquitous and will become more so once ipv4 scarcity is realised worldwide (particularly in asia, which is currently the fastest growing global region, and has already reached RIR exhaustion). There was a previous comment about this draft about the NAT/AH issue being a NAT problem rather than an AH problem. Well, yeah, in the purest sense this is true, but we live in the real world and need to work within its limitations. You can apply fixups and ALGs to lots of protocols which are NAT sensitive, but AH is cryptographically incompatible with NAT and this cannot be fixed. I see little value in the IETF formally supporting a protocol which simply cannot work for most end-users on the basis of the access addressing provided. Formal deprecation / designation to historic status is appropriate in this case. Also +1 to the following arguments: - ESP + NULL == substantially equivalent - less mailing list chatter Nick From ynir@checkpoint.com Mon Apr 16 04:27: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 C4DE021F8627 for ; Mon, 16 Apr 2012 04:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.577 X-Spam-Level: X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 jLnuwM2rcUis for ; Mon, 16 Apr 2012 04:27:16 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 92F3121F862B for ; Mon, 16 Apr 2012 04:27:15 -0700 (PDT) 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 q3GBR6OQ011109; Mon, 16 Apr 2012 14:27:07 +0300 X-CheckPoint: {4F8C0F04-1-1B221DC2-5FFFF} 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; Mon, 16 Apr 2012 14:26:02 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Mon, 16 Apr 2012 14:25:48 +0300 From: Yoav Nir To: Nick Hilliard Date: Mon, 16 Apr 2012 14:25:51 +0300 Thread-Topic: [IPsec] draft-bhatia-moving-ah-to-historic Thread-Index: Ac0bw6u3d6u5ZJURT6WNxQjCVYnAVg== Message-ID: <5C94A95E-D36E-4474-8D17-0E17E2493E0F@checkpoint.com> References: <4F8BFA0E.4080006@inex.ie> In-Reply-To: <4F8BFA0E.4080006@inex.ie> 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 x-cpdlp: 11551fa8adde2c5c39ff1d036ff2fda62509a514b1 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] draft-bhatia-moving-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, 16 Apr 2012 11:27:16 -0000 On Apr 16, 2012, at 1:53 PM, Nick Hilliard wrote: > I'd like to add a voice of support to this draft. AH adds little except > complication to ipsec implementations and confusion to end users. It only adds confusion and complication in the sense that telnet adds them = (ESP is SSH in this analogy). If you don't implement it you and your users = don't get confused. Besides, the end users of IPsec who actually have to kn= ow what ESP is vs what AH is are very sophisticated. They're not the people= who simply press "Connect" on their L2TP or VPN clients. > Regarding ipv4 NATs, they are ubiquitous and will become more so once ipv= 4 > scarcity is realised worldwide (particularly in asia, which is currently > the fastest growing global region, and has already reached RIR exhaustion= ). Maybe, maybe not. As ISPs move large blocks of users to a combination of IP= v6 and CGN, blocks of IPv4 address space may be freed up. But regardless, N= AT *is* going to be with us for a while, even in IPv6. > There was a previous comment about this draft about the NAT/AH issue bein= g > a NAT problem rather than an AH problem. Well, yeah, in the purest sense > this is true, but we live in the real world and need to work within its > limitations. You can apply fixups and ALGs to lots of protocols which ar= e > NAT sensitive, but AH is cryptographically incompatible with NAT and this > cannot be fixed. Nothing's stopping you from proposing 4302bis, which will be compatible wit= h NATs. There just isn't much demand for changing AH like that. > I see little value in the IETF formally supporting a protocol which simpl= y > cannot work for most end-users on the basis of the access addressing > provided. Formal deprecation / designation to historic status is > appropriate in this case. Formal deprecation is pretty much meaningless. Consider this example: Suppose the TICTOC working group decide that they need packet authenticatio= n for time signals, but not encryption. (makes sense, as they only deliver = the time of day). They can go with either AH or ESP-Null. They also don't c= are about NAT, because NATs introduce so much jitter, that they'll ruin the= accuracy of PTP, so PTP does not go through NAT anyway. They also first co= nstruct the IPsec packet, then paste the timestamp where it's needed, and q= uickly calculate the hash. If they can do this with less jitter with AH tha= n with ESP, do you think they'll actually care whether they're using a "cur= rent" or "historic" standard? They'll just use whatever gets the job done = better. Even "historic" does not mean everyone has to stop using it, even in new st= andards. It just means that you have to have a really good justification wh= y you need that rather than ESP. That's the situation already. Declaring it= so doesn't help. > Also +1 to the following arguments: >=20 > - ESP + NULL =3D=3D substantially equivalent > - less mailing list chatter Well, this draft generated a 77-post thread. Then the mailing list got quie= t about it, and we had three months without any mention of AH. I think movi= ng it to historic creates a lot more mailing list chatter than ignoring it. Yoav From nick@inex.ie Mon Apr 16 09:23:03 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 2C7CC11E8099 for ; Mon, 16 Apr 2012 09:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7asrsQBCEBdr for ; Mon, 16 Apr 2012 09:23:02 -0700 (PDT) Received: from mail.acquirer.com (mail.acquirer.com [IPv6:2a03:8900:0:100::5]) by ietfa.amsl.com (Postfix) with ESMTP id BB1ED11E8091 for ; Mon, 16 Apr 2012 09:22:48 -0700 (PDT) X-Envelope-To: ipsec@ietf.org Received: from dhcp-26-238.ripemtg.ripe.net ([IPv6:2001:67c:64:42:ad48:acbf:e018:9e1d]) (authenticated bits=0) by mail.acquirer.com (8.14.4/8.14.4) with ESMTP id q3GGMNJa004796 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 16 Apr 2012 17:22:29 +0100 (IST) (envelope-from nick@inex.ie) Message-ID: <4F8C4747.5030902@inex.ie> Date: Mon, 16 Apr 2012 18:22:31 +0200 From: Nick Hilliard User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Yoav Nir References: <4F8BFA0E.4080006@inex.ie> <5C94A95E-D36E-4474-8D17-0E17E2493E0F@checkpoint.com> In-Reply-To: <5C94A95E-D36E-4474-8D17-0E17E2493E0F@checkpoint.com> X-Enigmail-Version: 1.4 X-Company-Info-1: Internet Neutral Exchange Association Limited. Registered in Ireland No. 253804 X-Company-Info-2: Registered Offices: 1-2, Marino Mart, Fairview, Dublin 3 X-Company-Info-3: Internet Neutral Exchange Association Limited is limited by guarantee X-Company-Info-4: Offices: 4027 Kingswood Road, Citywest, Dublin 24. Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-bhatia-moving-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, 16 Apr 2012 16:23:03 -0000 On 16/04/2012 12:25, Yoav Nir wrote: > It only adds confusion and complication in the sense that telnet adds > them (ESP is SSH in this analogy). To be fair, it adds a lot more confusion than telnet vs ssh. With my !inex.ie hats on, I see smart but untrained ops people attempting to configure up their firewall / vpn systems and not realise that AH is actually a separate protocol, but actually requires end-to-end support for protocol 51. Then they stumble on the fact that it doesn't work with NAT and further anxiety ensues. Debugging firewall problems is at least a level 2 support issue, and often requires escalation to level 3. This sort of support burden is expensive. > If you don't implement it you and your users don't get confused. It's not me using it - it's my clients' customers. The end-users are one level further removed from that. > Besides, the end users of IPsec who actually have to know what ESP is vs > what AH is are very sophisticated. They're not the people who simply > press "Connect" on their L2TP or VPN clients. Indeed, and I'm talking about operators who configure these services, not end users who click connect. > Maybe, maybe not. As ISPs move large blocks of users to a combination of > IPv6 and CGN, blocks of IPv4 address space may be freed up. But > regardless, NAT *is* going to be with us for a while, even in IPv6. I question whether we will ever transition to ipv6. I hope we will, but rate it somewhat unlikely at this stage of the Internet's evolution. This is a separate discussion though. IPv4 NAT will be around for the forseeable future - e.g. many decades at the very least. > Nothing's stopping you from proposing 4302bis, which will be compatible > with NATs. There just isn't much demand for changing AH like that. That particular wheel has already been invented many times at many layers (esp, ssl/tls, etc). > Suppose the TICTOC working group decide that they need packet > authentication for time signals, but not encryption. (makes sense, as > they only deliver the time of day). They can go with either AH or > ESP-Null. They also don't care about NAT, because NATs introduce so much > jitter, that they'll ruin the accuracy of PTP, so PTP does not go > through NAT anyway. They also first construct the IPsec packet, then > paste the timestamp where it's needed, and quickly calculate the hash. > If they can do this with less jitter with AH than with ESP, do you think > they'll actually care whether they're using a "current" or "historic" > standard? They'll just use whatever gets the job done better. This is an edge case. It's possible to create edge cases for anything. > Even "historic" does not mean everyone has to stop using it, even in new > standards. It just means that you have to have a really good > justification why you need that rather than ESP. That's the situation > already. Declaring it so doesn't help. The IETF is very self-deprecating about historic status. There's nothing wrong with a document saying: -- operators: this protocol has serious problems in practice. therefore we suggest you use $otherprotocol which has none of these problems and is better in almost every other respect. developers: don't bother. no point. -- Call it good housekeeping. Call it operational guidance that access providers can show to their customers about why AH is not a good idea. Whatever it's called, historic status is a good place for moribund protocols to be placed, lovingly or otherwise. > Well, this draft generated a 77-post thread. Then the mailing list got > quiet about it, and we had three months without any mention of AH. Sounds pretty typical for most mailing lists...? > I think moving it to historic creates a lot more mailing list chatter > than ignoring it. Right now yes. But this argument will go round in circles for the next 50 years until people finally accept that AH is generally not useful. During that time, there will be much mailing list chatter about it, on this and other lists. Best consign it to history and close that particular door. It was good while it was relevant, but those times are gone. Nick