From paul.hoffman@vpnc.org Sat Sep 8 09:31: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 B5A4721F856C for ; Sat, 8 Sep 2012 09:31:26 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFwMrbmP3LJe for ; Sat, 8 Sep 2012 09:31:26 -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 1454F21F853B for ; Sat, 8 Sep 2012 09:31:25 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q88GVN6U023602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 8 Sep 2012 09:31:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Paul Hoffman In-Reply-To: Date: Sat, 8 Sep 2012 09:31:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> References: To: IPsecme WG X-Mailer: Apple Mail (2.1486) Subject: [IPsec] STRONG NUDGE: Revised AD VPN Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 16:31:26 -0000 This appeared on the list over two weeks ago and it has received no = comments since. This is supposed to be the WG's main work item, folks. --Paul Hoffman On Aug 23, 2012, at 9:02 AM, Stephen Hanna wrote: > Vishwas and I have updated the AD VPN Problem Statement > and Requirements draft to address the comments received > on the previous version and remaining comments from > earlier email discussions. The new version is available at >=20 > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem >=20 > A summary of the changes in this version is included at > the end of this message. >=20 > Please review this document and provide any comments on > the existing requirements or suggestions for new ones. >=20 > For requirement 3, Vishwas will be starting an email > thread soon so that the WG can discuss what this text > means, whether we want to keep it, and how it can be > made clearer. >=20 > Thanks, >=20 > Steve >=20 > ------------ >=20 > Summary of Changes in draft-ietf-ipsecme-ad-vpn-00.txt >=20 > * Changed draft name from p2p-vpn to ad-vpn. >=20 > * Added a paragraph for each requirement, explaining how > that requirement is driven by the use cases. >=20 > * In requirement 1, defined what we mean by minimizing > configuration changes. >=20 > * In requirement 2, explained that this requirement implies > that SPD entries and other configuration based on peer > IP address will need to be automatically updated when > the peer's IP address changes. >=20 > * Split requirement 4 into two requirements (now 4 and 5). >=20 > * In requirement 6 (formerly 5), explained what we mean > by "easy handoff of sessions": avoid TCP session breakage > and packet loss, when possible. >=20 > * In requirement 8 (formerly 7), acknowledged the difficulty > of handling cases where gateways are behind NATs or where > two endpoints are both behind separate NATs. In those cases, > we may need to use workarounds such as port forwarding by > the NATs or falling back to a hub and spoke architecture. >=20 > * Added new requirement 9 around manageability. >=20 > * Added new requirement 10 around cross-organization use. >=20 > * Added new requirement 11 saying that administrators should > be able to limit topologies for security and other reasons. >=20 > * Fixed typos and other minor wording issues. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 From ynir@checkpoint.com Sat Sep 8 12:23: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 DBDF521F8512 for ; Sat, 8 Sep 2012 12:23:22 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-auiA5QY2sD for ; Sat, 8 Sep 2012 12:23:22 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F000A21F84F8 for ; Sat, 8 Sep 2012 12:23:21 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q88JNJjx007901 for ; Sat, 8 Sep 2012 22:23:19 +0300 X-CheckPoint: {504B96A1-0-1B221DC2-4FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 8 Sep 2012 22:23:19 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 8 Sep 2012 22:23:19 +0300 From: Yoav Nir To: IPsecme WG Date: Sat, 8 Sep 2012 22:23:18 +0300 Thread-Topic: [IPsec] STRONG NUDGE: Revised AD VPN Requirements Thread-Index: Ac2N92a5e+ujW1wZQZqcoz88EB0QMQ== Message-ID: <4BAFA2F5-E8EE-4EEA-9761-C6A4CE003A38@checkpoint.com> References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> In-Reply-To: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: Re: [IPsec] STRONG NUDGE: Revised AD VPN Requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Sep 2012 19:23:23 -0000 On Sep 8, 2012, at 7:31 PM, Paul Hoffman wrote: > This appeared on the list over two weeks ago and it has received no comme= nts since. This is supposed to be the WG's main work item, folks. >=20 > --Paul Hoffman OK. Section 4.1: Point #1: While less configuration required is better, I would like there t= o be some absolute requirements. Like, changing or adding a spoke requires = no changes to other spokes. Or changing any node does not require changing = any other nodes where the static configuration does not include that node. Speaking of which, I think a good criterion for evaluating proposals is the= amount of required static (or "manual") configuration. Point #3: What is "tunnel binding"? Point #4 is unclear. If spokes talk to other spokes, in what way are they s= pokes? Sounds like a mesh to me. If you mean that the administrator(s) begi= n by statically configuring a star topology, and it automagically morphs in= to a mesh, this should be said explicitly. Point #6: I'm not sure what a handoff is. If it's a single host moving from= behind one peer to behind another peer, I don't see how this can be requir= ed. VPN gateways are often combined with stateful firewalls, which typicall= y refuse to allow a TCP connection to proceed.=20 Point #9: I think there's an expired draft for an IPsec MIB. But that's not= what I meant in Vancouver. We are adding dynamic changes to the configurat= ion. These changes should be logged and reported to facilitate trouble-shoo= ting. With static configuration, if you haven't touched the configuration a= nd things stopped working, you can look at gateways failing, at network err= ors, expired certificates, or any number of other issues that administrator= s know about and can look for. A dynamically changing configuration is a ne= w possible source for errors, one that is currently not reported. So if gat= eway A believes that packets to host H should be forwarded through gateway = B, but gateway B applies a DROP rule to all such packets, we need reporting= of the configuration changes on both gateways to see how this thing happen= ed. Yoav= From kivinen@iki.fi Mon Sep 10 05:25:15 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 953AE21F868A for ; Mon, 10 Sep 2012 05:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMwHc2CXQaDL for ; Mon, 10 Sep 2012 05:25:14 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B25A21F8686 for ; Mon, 10 Sep 2012 05:25:13 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q8ACPBQk001995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Sep 2012 15:25:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q8ACPAor013818; Mon, 10 Sep 2012 15:25:10 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Message-ID: <20557.56357.878183.593537@fireball.kivinen.iki.fi> Date: Mon, 10 Sep 2012 15:25:09 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Tero Kivinen To: Paul Hoffman In-Reply-To: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 103 min X-Total-Time: 54 min Cc: IPsecme WG Subject: [IPsec] STRONG NUDGE: Revised AD VPN Requirements 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, 10 Sep 2012 12:25:15 -0000 Paul Hoffman writes: > This appeared on the list over two weeks ago and it has received no > comments since. This is supposed to be the WG's main work item, > folks. My comments: > 2.2. Gateway-to-Gateway AD VPN Use Case ... > The spoke gateways can themselves come up and down, getting different > IP addresses in the process, making th static configuration ^^ Typo. > 3.2. Star Topology ... > This solution however does not work when the spokes get dynamic IP > address which the "hub gateways" cannot be configured with. I think star topology works fine with dynamic IP addresses. You just need to make sure that the spokes are the entities which brings up the link, i.e. immediately when they boot up they put up the IPsec link and keep it up all the time. There is other identities in the IPsec world than IP-addresses... I would remove the whole sentence. > bandwidth. A single packet in the hub-and-spoke scenario can be > encrypted and decrypted three times. It would be much preferable if In the pure hub-and-spoke model I cannot really see more than two times, one from the spoke to hub, and second time from the hub to another spoke. If there is hub to hub links also then it is not pure hub-and-spoke scenario anymore. I would replace the "three" with "multiple". I myself really had to read the first paragraph of this section again to notice that you talk there that this section says there can be multiple gateways selected as hub gateways. > 4.1. Gateway and Endpoint Requirements ... > 2. Gateways and endpoints MUST allow IPsec Tunnels to be setup > without any configuration changes, even when peer addresses get > updated every time the device comes up. This is unclear for me. Does that mean that anybody can connect to the gateway and the gateway MUST allow IPsec Tunnels to be setup without any configuration changes (like adding authentication credentials?). I do not think so. I think this needs to be clarified. Also endpoints do require configuration changes before they can first time connect to the AD VPN, for example you need to insert the credentials and most likely also point at least one gateway for them to fetch rest of configuration from them. If this is just trying to say that already configured devices in the AD VPN MUST be able to connect to any other configured device in the AD VPN at any time, even when the IP addresses are not known beforehand, then I think it should be said differently. Anyways I am not sure what this is trying to say. > This implies that SPD > entries or other configuration based on peer IP address will need to > be automatically updated, avoided, or handled in some manner to avoid > a need to manually update policy whenever an address changes. This is much more clear, and I think this most likely means that the first paragraph was trying to say that already existing AD VPN members should be able to connect other AD VPN members even when their IP-addresses are not static. Next question is how does the one member know to which address connect to if also the destination member has changing IP address? And how to punch holes to NATs that might be between them. > 3. Gateways MUST allow tunnel binding, such that applications like > Routing using the tunnels can work seamlessly without any updates to > the higher level application configuration i.e. OSPF configuration. I have no idea what this requirement means. What is "tunnel binding"? Where does this requirement come? Which use case drives this? > 4. In a hub-and-spoke topology, spoke gateways and endpoints MUST > allow for direct communication with other spoke gateways and > endpoints. Hmm... why are you listing here spokes and endpoints as separate entries. In the terminology I understood spoke also includes endpoints? > 5. One spoke MUST NOT be able to impersonate another spoke. If spoke does not imply endpoints, then we should say that this also applies to the endpoints, i.e. One endpoint or spoke MUST NOT be able to impersonate another spokes or endpoints. What about hubs? Are they allowed to impersonate other hubs? I assume yes, but then next question comes are hubs allowed to impersonate as a spoke or endpoint? Is there any requirement that when endpoint makes direct connection to other endpoint it knows that there cannot be any other parties listening on the link? If there is such requirement then also the hubs are not allowed to impersonate endpoints, but on the other hand if we use CA infrastructure, then the CA can always issue certificate allowing this kind of impersonation. > 6. Gateways SHOULD allow for easy handoff of sessions in case > endpoints are roaming, even if they cross policy boundaries. This > means that TCP session breakage and packet loss should be avoided, > when possible. > > This requirement is driven by use case 2.1. Today's endpoints are > mobile and transition often between different networks (from 4G to > WiFi and among various WiFi networks). This cannot come from case 2.1, as that is endpoint to endpoint, so there is no gateway at all there. I would expect this would come from 2.3 i.e. the endpoint to gateway use case. Or does this mean gateways should allow handoff from the endpoint-gateway-endpoint to direct endpoint-endpoint link without breaking TCP sessions? > 8. Gateways and endpoints MUST be able to work when they are behind > NAT boxes. However, it is especially difficult to handle cases where > gateways are behind NATs and where two endpoints are both behind > separate NATs. In those cases, workarounds MAY be used such as port > forwarding by the NAT or detecting when two spokes are behind > uncooperative NATs and using a hub in that case. > > This requirement is driven by use cases 2.1 and 2.2. Endpoints are > often behind NATs and gateways sometimes are. IPsec should continue > to work seamlessly regardless, using AD VPN techniques whenever > possible and providing graceful fallback to hub and spoke techniques > as needed. Does this also include discovery of the addresses? How about if we have two endpoints talking to each other and one of the nat boxes is restarted and one peers IP-address changes, and as the NATs are restricted nats, which means they cannot connect to each other at all after that without the help of the 3rd party. Also the 3rd party cannot connect to either one of them, thus the recover must then start from the endpoints so both of them connect to this 3rd party (hub) to recover from the situation. > 9. Changes such as establishing a new IPsec SA SHOULD be reportable > and manageable. However, creating a MIB or other management > technique is not within scope for this effort. > > This requirement is driven by manageability concerns for all the use > cases, especially use case 2.2. As IPsec networks become more > dynamic, management tools become more essential. I would rule configuration MIB out of the scope, but I would actually think it would be good idea to make reporting and statistics MIB. We really need one in the IPsec, and this is effort I think we should take here in ipsecme also for normal IPsec devices. I am sure we are still missing some requirements, but thats my comments for the existing requirements. I need to think bit more what other requirements we might have. -- kivinen@iki.fi From vishwas.ietf@gmail.com Tue Sep 11 20:04: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 5ED6C21F85EA for ; Tue, 11 Sep 2012 20:04:12 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5Dkpw3c2D3S for ; Tue, 11 Sep 2012 20:04:11 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7101B21F85D5 for ; Tue, 11 Sep 2012 20:04:10 -0700 (PDT) Received: by lahm15 with SMTP id m15so838205lah.31 for ; Tue, 11 Sep 2012 20:04:09 -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=W7lFq7pg2n38J4ZQ/9m1GP99JvhhXvOWtKW9AT1YpPQ=; b=AW3CfPjbzvBW00iSI+ywQIFL9tcYSZ6czQ8PGlgzvZo9IT7njQSdJwnnZW12kwf+1Q xImjF5UKr4GiofIU5gzdRNB/c/CyW/hFLUWfoRWyKQkPxFJymb3gsCDAAvyifQJHL2YW SMr9fVF6JuwObz2tD6eKOu4tMrjuZpR2L8YOZNlZ5QsaiuwmO8yp+sKiz9wsf64Yc7Rn 1gbN6+NNsCsldafd6J2TigFbDdxTixBMlJxlHnq9dI700NfKplKkRVOelTlRnULWZasT UGbQNM2pz2lUs2MIak9YqLzIW70PhcE1IGQiAw220FWMbm2+moAlRecEsPFZ5bSxsEMh TUbw== MIME-Version: 1.0 Received: by 10.112.9.3 with SMTP id v3mr6946925lba.32.1347419049243; Tue, 11 Sep 2012 20:04:09 -0700 (PDT) Received: by 10.114.0.14 with HTTP; Tue, 11 Sep 2012 20:04:09 -0700 (PDT) In-Reply-To: <20557.56357.878183.593537@fireball.kivinen.iki.fi> References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20557.56357.878183.593537@fireball.kivinen.iki.fi> Date: Tue, 11 Sep 2012 20:04:09 -0700 Message-ID: From: Vishwas Manral To: Tero Kivinen Content-Type: multipart/alternative; boundary=e0cb4efe2b18cb353404c978719d Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] STRONG NUDGE: Revised AD VPN Requirements 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, 12 Sep 2012 03:04:12 -0000 --e0cb4efe2b18cb353404c978719d Content-Type: text/plain; charset=ISO-8859-1 Hi Tero/ Yoav, Thanks for your great comments. We are discussing this internally and will get back to you in a few days. Thanks, Vishwas On Mon, Sep 10, 2012 at 5:25 AM, Tero Kivinen wrote: > Paul Hoffman writes: > > This appeared on the list over two weeks ago and it has received no > > comments since. This is supposed to be the WG's main work item, > > folks. > > My comments: > > > 2.2. Gateway-to-Gateway AD VPN Use Case > ... > > The spoke gateways can themselves come up and down, getting different > > IP addresses in the process, making th static configuration > ^^ > Typo. > > > 3.2. Star Topology > ... > > This solution however does not work when the spokes get dynamic IP > > address which the "hub gateways" cannot be configured with. > > I think star topology works fine with dynamic IP addresses. You just > need to make sure that the spokes are the entities which brings up the > link, i.e. immediately when they boot up they put up the IPsec link > and keep it up all the time. There is other identities in the IPsec > world than IP-addresses... > > I would remove the whole sentence. > > > bandwidth. A single packet in the hub-and-spoke scenario can be > > encrypted and decrypted three times. It would be much preferable if > > In the pure hub-and-spoke model I cannot really see more than two > times, one from the spoke to hub, and second time from the hub to > another spoke. If there is hub to hub links also then it is not pure > hub-and-spoke scenario anymore. I would replace the "three" with > "multiple". I myself really had to read the first paragraph of this > section again to notice that you talk there that this section says > there can be multiple gateways selected as hub gateways. > > > 4.1. Gateway and Endpoint Requirements > ... > > 2. Gateways and endpoints MUST allow IPsec Tunnels to be setup > > without any configuration changes, even when peer addresses get > > updated every time the device comes up. > > This is unclear for me. Does that mean that anybody can connect to the > gateway and the gateway MUST allow IPsec Tunnels to be setup without > any configuration changes (like adding authentication credentials?). I > do not think so. > > I think this needs to be clarified. Also endpoints do require > configuration changes before they can first time connect to the AD > VPN, for example you need to insert the credentials and most likely > also point at least one gateway for them to fetch rest of > configuration from them. > > If this is just trying to say that already configured devices in the > AD VPN MUST be able to connect to any other configured device in the > AD VPN at any time, even when the IP addresses are not known > beforehand, then I think it should be said differently. > > Anyways I am not sure what this is trying to say. > > > This implies that SPD > > entries or other configuration based on peer IP address will need to > > be automatically updated, avoided, or handled in some manner to avoid > > a need to manually update policy whenever an address changes. > > This is much more clear, and I think this most likely means that the > first paragraph was trying to say that already existing AD VPN members > should be able to connect other AD VPN members even when their > IP-addresses are not static. > > Next question is how does the one member know to which address connect > to if also the destination member has changing IP address? And how to > punch holes to NATs that might be between them. > > > 3. Gateways MUST allow tunnel binding, such that applications like > > Routing using the tunnels can work seamlessly without any updates to > > the higher level application configuration i.e. OSPF configuration. > > I have no idea what this requirement means. What is "tunnel binding"? > Where does this requirement come? Which use case drives this? > > > 4. In a hub-and-spoke topology, spoke gateways and endpoints MUST > > allow for direct communication with other spoke gateways and > > endpoints. > > Hmm... why are you listing here spokes and endpoints as separate > entries. In the terminology I understood spoke also includes > endpoints? > > > 5. One spoke MUST NOT be able to impersonate another spoke. > > If spoke does not imply endpoints, then we should say that this also > applies to the endpoints, i.e. One endpoint or spoke MUST NOT be able > to impersonate another spokes or endpoints. > > What about hubs? Are they allowed to impersonate other hubs? I assume > yes, but then next question comes are hubs allowed to impersonate as a > spoke or endpoint? Is there any requirement that when endpoint makes > direct connection to other endpoint it knows that there cannot be any > other parties listening on the link? If there is such requirement then > also the hubs are not allowed to impersonate endpoints, but on the > other hand if we use CA infrastructure, then the CA can always issue > certificate allowing this kind of impersonation. > > > 6. Gateways SHOULD allow for easy handoff of sessions in case > > endpoints are roaming, even if they cross policy boundaries. This > > means that TCP session breakage and packet loss should be avoided, > > when possible. > > > > This requirement is driven by use case 2.1. Today's endpoints are > > mobile and transition often between different networks (from 4G to > > WiFi and among various WiFi networks). > > This cannot come from case 2.1, as that is endpoint to endpoint, so > there is no gateway at all there. I would expect this would come from > 2.3 i.e. the endpoint to gateway use case. > > Or does this mean gateways should allow handoff from the > endpoint-gateway-endpoint to direct endpoint-endpoint link without > breaking TCP sessions? > > > 8. Gateways and endpoints MUST be able to work when they are behind > > NAT boxes. However, it is especially difficult to handle cases where > > gateways are behind NATs and where two endpoints are both behind > > separate NATs. In those cases, workarounds MAY be used such as port > > forwarding by the NAT or detecting when two spokes are behind > > uncooperative NATs and using a hub in that case. > > > > This requirement is driven by use cases 2.1 and 2.2. Endpoints are > > often behind NATs and gateways sometimes are. IPsec should continue > > to work seamlessly regardless, using AD VPN techniques whenever > > possible and providing graceful fallback to hub and spoke techniques > > as needed. > > Does this also include discovery of the addresses? How about if we > have two endpoints talking to each other and one of the nat boxes is > restarted and one peers IP-address changes, and as the NATs are > restricted nats, which means they cannot connect to each other at all > after that without the help of the 3rd party. Also the 3rd party > cannot connect to either one of them, thus the recover must then start > from the endpoints so both of them connect to this 3rd party (hub) to > recover from the situation. > > > 9. Changes such as establishing a new IPsec SA SHOULD be reportable > > and manageable. However, creating a MIB or other management > > technique is not within scope for this effort. > > > > This requirement is driven by manageability concerns for all the use > > cases, especially use case 2.2. As IPsec networks become more > > dynamic, management tools become more essential. > > I would rule configuration MIB out of the scope, but I would actually > think it would be good idea to make reporting and statistics MIB. We > really need one in the IPsec, and this is effort I think we should > take here in ipsecme also for normal IPsec devices. > > I am sure we are still missing some requirements, but thats my > comments for the existing requirements. I need to think bit more what > other requirements we might have. > -- > kivinen@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --e0cb4efe2b18cb353404c978719d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tero/ Yoav,

Thanks for your great comments. We are discussing thi= s internally and will get back to you in a few days.

Thanks,
Vish= was

On Mon, Sep 10, 2012 at 5:25 AM, Tero= Kivinen <kivinen@iki.fi> wrote:
Paul Hoffman writes:
> This appeared on the list over two weeks ago and it has received no > comments since. This is supposed to be the WG's main work item, > folks.

My comments:

> 2.2. =A0Gateway-to-Gateway AD VPN Use Case
...
> =A0 =A0The spoke gateways can themselves come up and down, getting dif= ferent
> =A0 =A0IP addresses in the process, making th static configuration
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0^^
Typo.

> 3.2. =A0Star Topology
...
> =A0 =A0This solution however does not work when the spokes get dynamic= IP
> =A0 =A0address which the "hub gateways" cannot be configured= with.

I think star topology works fine with dynamic IP addresses. You just
need to make sure that the spokes are the entities which brings up the
link, i.e. immediately when they boot up they put up the IPsec link
and keep it up all the time. There is other identities in the IPsec
world than IP-addresses...

I would remove the whole sentence.

> =A0 =A0bandwidth. =A0A single packet in the hub-and-spoke scenario can= be
> =A0 =A0encrypted and decrypted three times. =A0It would be much prefer= able if

In the pure hub-and-spoke model I cannot really see more than two
times, one from the spoke to hub, and second time from the hub to
another spoke. If there is hub to hub links also then it is not pure
hub-and-spoke scenario anymore. I would replace the "three" with<= br> "multiple". I myself really had to read the first paragraph of th= is
section again to notice that you talk there that this section says
there can be multiple gateways selected as hub gateways.

> 4.1. =A0Gateway and Endpoint Requirements
...
> =A0 =A02. =A0Gateways and endpoints MUST allow IPsec Tunnels to be set= up
> =A0 =A0without any configuration changes, even when peer addresses get=
> =A0 =A0updated every time the device comes up.

This is unclear for me. Does that mean that anybody can connect to the
gateway and the gateway MUST allow IPsec Tunnels to be setup without
any configuration changes (like adding authentication credentials?). I
do not think so.

I think this needs to be clarified. Also endpoints do require
configuration changes before they can first time connect to the AD
VPN, for example you need to insert the credentials and most likely
also point at least one gateway for them to fetch rest of
configuration from them.

If this is just trying to say that already configured devices in the
AD VPN MUST be able to connect to any other configured device in the
AD VPN at any time, even when the IP addresses are not known
beforehand, then I think it should be said differently.

Anyways I am not sure what this is trying to say.

> =A0 =A0This implies that SPD
> =A0 =A0entries or other configuration based on peer IP address will ne= ed to
> =A0 =A0be automatically updated, avoided, or handled in some manner to= avoid
> =A0 =A0a need to manually update policy whenever an address changes.
This is much more clear, and I think this most likely means that the
first paragraph was trying to say that already existing AD VPN members
should be able to connect other AD VPN members even when their
IP-addresses are not static.

Next question is how does the one member know to which address connect
to if also the destination member has changing IP address? And how to
punch holes to NATs that might be between them.

> =A0 =A03. =A0Gateways MUST allow tunnel binding, such that application= s like
> =A0 =A0Routing using the tunnels can work seamlessly without any updat= es to
> =A0 =A0the higher level application configuration i.e. =A0OSPF configu= ration.

I have no idea what this requirement means. What is "tunnel binding&qu= ot;?
Where does this requirement come? Which use case drives this?

> =A0 =A04. =A0In a hub-and-spoke topology, spoke gateways and endpoints= MUST
> =A0 =A0allow for direct communication with other spoke gateways and > =A0 =A0endpoints.

Hmm... why are you listing here spokes and endpoints as separate
entries. In the terminology I understood spoke also includes
endpoints?

> =A0 =A05. =A0One spoke MUST NOT be able to impersonate another spoke.<= br>
If spoke does not imply endpoints, then we should say that this also
applies to the endpoints, i.e. One endpoint or spoke MUST NOT be able
to impersonate another spokes or endpoints.

What about hubs? Are they allowed to impersonate other hubs? I assume
yes, but then next question comes are hubs allowed to impersonate as a
spoke or endpoint? Is there any requirement that when endpoint makes
direct connection to other endpoint it knows that there cannot be any
other parties listening on the link? If there is such requirement then
also the hubs are not allowed to impersonate endpoints, but on the
other hand if we use CA infrastructure, then the CA can always issue
certificate allowing this kind of impersonation.

> =A0 =A06. =A0Gateways SHOULD allow for easy handoff of sessions in cas= e
> =A0 =A0endpoints are roaming, even if they cross policy boundaries. = =A0This
> =A0 =A0means that TCP session breakage and packet loss should be avoid= ed,
> =A0 =A0when possible.
>
> =A0 =A0This requirement is driven by use case 2.1. =A0Today's endp= oints are
> =A0 =A0mobile and transition often between different networks (from 4G= to
> =A0 =A0WiFi and among various WiFi networks).

This cannot come from case 2.1, as that is endpoint to endpoint, so
there is no gateway at all there. I would expect this would come from
2.3 i.e. the endpoint to gateway use case.

Or does this mean gateways should allow handoff from the
endpoint-gateway-endpoint to direct endpoint-endpoint link without
breaking TCP sessions?

> =A0 =A08. =A0Gateways and endpoints MUST be able to work when they are= behind
> =A0 =A0NAT boxes. =A0However, it is especially difficult to handle cas= es where
> =A0 =A0gateways are behind NATs and where two endpoints are both behin= d
> =A0 =A0separate NATs. =A0In those cases, workarounds MAY be used such = as port
> =A0 =A0forwarding by the NAT or detecting when two spokes are behind > =A0 =A0uncooperative NATs and using a hub in that case.
>
> =A0 =A0This requirement is driven by use cases 2.1 and 2.2. =A0Endpoin= ts are
> =A0 =A0often behind NATs and gateways sometimes are. =A0IPsec should c= ontinue
> =A0 =A0to work seamlessly regardless, using AD VPN techniques whenever=
> =A0 =A0possible and providing graceful fallback to hub and spoke techn= iques
> =A0 =A0as needed.

Does this also include discovery of the addresses? How about if we
have two endpoints talking to each other and one of the nat boxes is
restarted and one peers IP-address changes, and as the NATs are
restricted nats, which means they cannot connect to each other at all
after that without the help of the 3rd party. Also the 3rd party
cannot connect to either one of them, thus the recover must then start
from the endpoints so both of them connect to this 3rd party (hub) to
recover from the situation.

> =A0 =A09. =A0Changes such as establishing a new IPsec SA SHOULD be rep= ortable
> =A0 =A0and manageable. =A0However, creating a MIB or other management<= br> > =A0 =A0technique is not within scope for this effort.
>
> =A0 =A0This requirement is driven by manageability concerns for all th= e use
> =A0 =A0cases, especially use case 2.2. =A0As IPsec networks become mor= e
> =A0 =A0dynamic, management tools become more essential.

I would rule configuration MIB out of the scope, but I would actually
think it would be good idea to make reporting and statistics MIB. We
really need one in the IPsec, and this is effort I think we should
take here in ipsecme also for normal IPsec devices.

I am sure we are still missing some requirements, but thats my
comments for the existing requirements. I need to think bit more what
other requirements we might have.
--
kivinen@iki.fi
_____________________= __________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--e0cb4efe2b18cb353404c978719d-- From vishwas.ietf@gmail.com Fri Sep 14 15:16:39 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F1021F84D1 for ; Fri, 14 Sep 2012 15:16:39 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99Y-8lB3coCK for ; Fri, 14 Sep 2012 15:16:38 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id F32C321F84B9 for ; Fri, 14 Sep 2012 15:16:37 -0700 (PDT) Received: by lbky2 with SMTP id y2so3296686lbk.31 for ; Fri, 14 Sep 2012 15:16:37 -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=KZ6/kCWMdmeULDtgJwQw5ElvAqZ/MEUJcPXs23oATeQ=; b=tbj8GJ55kc/D00f4ws0JUFYf321yaZQP2WFgOMF150qOHYaLyNwdgT2C/3DNCiTp0l yhHJ5a0qfYvgiBNBF03VUdF3kxQbf2oVwyUp9pYLu24wCpg6FlfycAWdNuSoRAQfMNEF fSn2vJcz8ysqd8b9ToR/ayBhlffaz2mWOdtwWKA0FMGEIUw5R3HkgfT0EpTQNYUgAyQM IBnb59vHBHpoDVSdxAEH6818x0Ys8BCVakajruWOww+SYCcDbAXh0JFNl4F75Eb2UUmA ldWefsQrs9qKPaCYyOhVW79BEAeQ/l1vVGj4eTQoTccll392ONj3ZeAF6D0ZAG0fn/7g tPcA== MIME-Version: 1.0 Received: by 10.152.124.76 with SMTP id mg12mr3790617lab.10.1347660996924; Fri, 14 Sep 2012 15:16:36 -0700 (PDT) Received: by 10.114.0.14 with HTTP; Fri, 14 Sep 2012 15:16:36 -0700 (PDT) In-Reply-To: <4BAFA2F5-E8EE-4EEA-9761-C6A4CE003A38@checkpoint.com> References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <4BAFA2F5-E8EE-4EEA-9761-C6A4CE003A38@checkpoint.com> Date: Fri, 14 Sep 2012 15:16:36 -0700 Message-ID: From: Vishwas Manral To: Yoav Nir Content-Type: multipart/alternative; boundary=f46d043bd88affd5ff04c9b0c6ed Cc: IPsecme WG Subject: Re: [IPsec] STRONG NUDGE: Revised AD VPN Requirements 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, 14 Sep 2012 22:16:39 -0000 --f46d043bd88affd5ff04c9b0c6ed Content-Type: text/plain; charset=ISO-8859-1 Hi Yoav, My replies below. Thanks a lot for your thoughtful comments and I am sorry for the delays. Section 4.1: > > Point #1: While less configuration required is better, I would like there > to be some absolute requirements. Like, changing or adding a spoke requires > no changes to other spokes. Or changing any node does not require changing > any other nodes where the static configuration does not include that node. > > Speaking of which, I think a good criterion for evaluating proposals is > the amount of required static (or "manual") configuration. > VM> I agree we need absolute requirements. The point we were trying to stress was that though we know not having any changes in some cases may not be possible it should be a requirement to minimize the changes in configuration. I will look at the various cases as you suggest and then put in more exact requirements. > Point #3: What is "tunnel binding"? > I have heard similar concerns from Steve Hanna on the requirements too. The idea here is that we should allow applications like OSPF, to work over the tunnels irrespective of the end point addresses.Let me know if I am clearer. > > Point #4 is unclear. If spokes talk to other spokes, in what way are they > spokes? Sounds like a mesh to me. If you mean that the administrator(s) > begin by statically configuring a star topology, and it automagically > morphs into a mesh, this should be said explicitly. > This requirement comes from the way Enterprise WAN architecture is. The branches connect to the data centers in a Hub-and-Spoke topology using IPsec tunnels. However spokes are optionally and temporarily allowed to connect to each other for traffic such as voice etc which does not gain from taking an extra hop to the data center. I will clarify the point. > Point #6: I'm not sure what a handoff is. If it's a single host moving > from behind one peer to behind another peer, I don't see how this can be > required. VPN gateways are often combined with stateful firewalls, which > typically refuse to allow a TCP connection to proceed. > It is for that purpose the draft says the protocol should avoid packet loss when possible. If there are external factors like firewalls, they need to be dealt with separately. > > Point #9: I think there's an expired draft for an IPsec MIB. But that's > not what I meant in Vancouver. We are adding dynamic changes to the > configuration. These changes should be logged and reported to facilitate > trouble-shooting. With static configuration, if you haven't touched the > configuration and things stopped working, you can look at gateways failing, > at network errors, expired certificates, or any number of other issues that > administrators know about and can look for. A dynamically changing > configuration is a new possible source for errors, one that is currently > not reported. So if gateway A believes that packets to host H should be > forwarded through gateway B, but gateway B applies a DROP rule to all such > packets, we need reporting of the configuration changes on both gateways to > see how this thing happened. > I agree this is a good requirement and I will update the draft with the same. Thanks, Vishwas > > Yoav > --f46d043bd88affd5ff04c9b0c6ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yoav,

My replies below. Thanks a lot for your thoughtful comments= and I am sorry for the delays.

Section 4.1:

Point #1: While less configuration required is better, I would like there t= o be some absolute requirements. Like, changing or adding a spoke requires = no changes to other spokes. Or changing any node does not require changing = any other nodes where the static configuration does not include that node.<= br>
Speaking of which, I think a good criterion for evaluating proposals is the= amount of required static (or "manual") configuration.
VM> I agree we need absolute requirements. The point we were= trying to stress was that though we know not having any changes in some ca= ses may not be possible it should be a requirement to minimize the changes = in configuration.

I will look at the various cases as you suggest and then put in more ex= act requirements.


Point #3: What is "tunnel binding"?
I have h= eard similar concerns from Steve Hanna on the requirements too. The idea he= re is that we should allow applications like OSPF, to work over the tunnels= irrespective of the end point addresses.Let me know if I am clearer.
=A0

Point #4 is unclear. If spokes talk to other spokes, in what way are they s= pokes? Sounds like a mesh to me. If you mean that the administrator(s) begi= n by statically configuring a star topology, and it automagically morphs in= to a mesh, this should be said explicitly.
This requirement comes from the way Enterprise WAN archit= ecture is. The branches connect to the data centers in a Hub-and-Spoke topo= logy using IPsec tunnels. However spokes are optionally and temporarily all= owed to connect to each other for traffic such as voice etc which does not = gain from taking an extra hop to the data center.

I will clarify the point.


Point #6: I'm not sure what a handoff is. If it's a single host mov= ing from behind one peer to behind another peer, I don't see how this c= an be required. VPN gateways are often combined with stateful firewalls, wh= ich typically refuse to allow a TCP connection to proceed.
It is for that purpose the draft says the protocol should= avoid packet loss when possible. If there are external factors like firewa= lls, they need to be dealt with separately.
=A0

Point #9: I think there's an expired draft for an IPsec MIB. But that&#= 39;s not what I meant in Vancouver. We are adding dynamic changes to the co= nfiguration. These changes should be logged and reported to facilitate trou= ble-shooting. With static configuration, if you haven't touched the con= figuration and things stopped working, you can look at gateways failing, at= network errors, expired certificates, or any number of other issues that a= dministrators know about and can look for. A dynamically changing configura= tion is a new possible source for errors, one that is currently not reporte= d. So if gateway A believes that packets to host H should be forwarded thro= ugh gateway B, but gateway B applies a DROP rule to all such packets, we ne= ed reporting of the configuration changes on both gateways to see how this = thing happened.
I agree this is a good requirement and I will update the = draft with the same.

Thanks,
Vishwas

Yoav

--f46d043bd88affd5ff04c9b0c6ed-- From vishwas.ietf@gmail.com Fri Sep 14 15:39:46 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B4921F849D for ; Fri, 14 Sep 2012 15:39:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iw1t067MQBvR for ; Fri, 14 Sep 2012 15:39:44 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id DD17521F845B for ; Fri, 14 Sep 2012 15:39:43 -0700 (PDT) Received: by lbky2 with SMTP id y2so3305397lbk.31 for ; Fri, 14 Sep 2012 15:39: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=wCGWuloXOoR2GVxXFd09HgILZnHSJAncyVL5WWg+8C8=; b=KN8XnrUOvW5PmPX2ovYvTb3/5Ga6BRGOttKXqnUB/4ARWWf/O/n/JUeK/OAobp8+9N AoU/ND/ybJ9nTEki5e7RRAYttEhKrCoPjH+PGC6RTzRHkcCaKe6+XzUZN7SxV1s7BnBM 7z1Nz2Hv5rzRoKXxqE0Uh0z4aa1B0eVN9bxso2MWX4WJ7D/DtB7dWwOJWKK2IVKjc3t8 rtcVdGPOmcOTsimzKQNZvNvzHw7WtxgJc8VpyrEdt6dwE6UfXJowDottxDMVaQTLoWe/ FOYbmr0Uywk5+sJAg/+7oXCdFWTtC8Nwdl3StltXDCxdfpZ8vxfXYrDloZkOlFHMtchd J/Lw== MIME-Version: 1.0 Received: by 10.152.111.227 with SMTP id il3mr2937284lab.23.1347662382796; Fri, 14 Sep 2012 15:39:42 -0700 (PDT) Received: by 10.114.0.14 with HTTP; Fri, 14 Sep 2012 15:39:42 -0700 (PDT) In-Reply-To: <20557.56357.878183.593537@fireball.kivinen.iki.fi> References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20557.56357.878183.593537@fireball.kivinen.iki.fi> Date: Fri, 14 Sep 2012 15:39:42 -0700 Message-ID: From: Vishwas Manral To: Tero Kivinen Content-Type: multipart/alternative; boundary=f46d040839eb9a8e7204c9b11957 Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] STRONG NUDGE: Revised AD VPN Requirements 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, 14 Sep 2012 22:39:46 -0000 --f46d040839eb9a8e7204c9b11957 Content-Type: text/plain; charset=ISO-8859-1 Hi Tero, Thanks a lot for your comments. My comments inline with a "VM>" prefix. On Mon, Sep 10, 2012 at 5:25 AM, Tero Kivinen wrote: > Paul Hoffman writes: > > This appeared on the list over two weeks ago and it has received no > > comments since. This is supposed to be the WG's main work item, > > folks. > > My comments: > > > 2.2. Gateway-to-Gateway AD VPN Use Case > ... > > The spoke gateways can themselves come up and down, getting different > > IP addresses in the process, making th static configuration > ^^ > Typo. > VM> Perfect. > > > 3.2. Star Topology > ... > > This solution however does not work when the spokes get dynamic IP > > address which the "hub gateways" cannot be configured with. > > I think star topology works fine with dynamic IP addresses. You just > need to make sure that the spokes are the entities which brings up the > link, i.e. immediately when they boot up they put up the IPsec link > and keep it up all the time. There is other identities in the IPsec > world than IP-addresses... > > I would remove the whole sentence. > > VM> I think what we need to talk here is that in case IP address is used as an identifier, we need to make sure that it works even as the IP address changes or we can put it that IP address should not be ever used as identifiers in such cases. > > bandwidth. A single packet in the hub-and-spoke scenario can be > > encrypted and decrypted three times. It would be much preferable if > > In the pure hub-and-spoke model I cannot really see more than two > times, one from the spoke to hub, and second time from the hub to > another spoke. If there is hub to hub links also then it is not pure > hub-and-spoke scenario anymore. I would replace the "three" with > "multiple". I myself really had to read the first paragraph of this > section again to notice that you talk there that this section says > there can be multiple gateways selected as hub gateways. > OK. We can replace with multiple I agree it could even be more than 3 in some cases. > > 4.1. Gateway and Endpoint Requirements > ... > > 2. Gateways and endpoints MUST allow IPsec Tunnels to be setup > > without any configuration changes, even when peer addresses get > > updated every time the device comes up. > > This is unclear for me. Does that mean that anybody can connect to the > gateway and the gateway MUST allow IPsec Tunnels to be setup without > any configuration changes (like adding authentication credentials?). I > do not think so. > > I think this needs to be clarified. Also endpoints do require > configuration changes before they can first time connect to the AD > VPN, for example you need to insert the credentials and most likely > also point at least one gateway for them to fetch rest of > configuration from them. > > If this is just trying to say that already configured devices in the > AD VPN MUST be able to connect to any other configured device in the > AD VPN at any time, even when the IP addresses are not known > beforehand, then I think it should be said differently. > > Anyways I am not sure what this is trying to say. VM> In my view if the first time a hub is connected to a spoke we will need to do some configuration for sure, however as we add other similar spokes (could be based on template), we would require no configuration at the Hub end for each spoke added. Let me know if I am clear here, I can update the document with this. > > This implies that SPD > > entries or other configuration based on peer IP address will need to > > be automatically updated, avoided, or handled in some manner to avoid > > a need to manually update policy whenever an address changes. > > This is much more clear, and I think this most likely means that the > first paragraph was trying to say that already existing AD VPN members > should be able to connect other AD VPN members even when their > IP-addresses are not static. > > Next question is how does the one member know to which address connect > to if also the destination member has changing IP address? And how to > punch holes to NATs that might be between them. > VM> These are the exact questions we need to answer with the protocol solution in my view. > > > 3. Gateways MUST allow tunnel binding, such that applications like > > Routing using the tunnels can work seamlessly without any updates to > > the higher level application configuration i.e. OSPF configuration. > > I have no idea what this requirement means. What is "tunnel binding"? > Where does this requirement come? Which use case drives this? > VM> Do let me know if the mail to Yoav makes it any clearer? > > > 4. In a hub-and-spoke topology, spoke gateways and endpoints MUST > > allow for direct communication with other spoke gateways and > > endpoints. > > Hmm... why are you listing here spokes and endpoints as separate > entries. In the terminology I understood spoke also includes > endpoints? > VM> I agree good point. Will update. > > 5. One spoke MUST NOT be able to impersonate another spoke. > > If spoke does not imply endpoints, then we should say that this also > applies to the endpoints, i.e. One endpoint or spoke MUST NOT be able > to impersonate another spokes or endpoints. > > What about hubs? Are they allowed to impersonate other hubs? I assume > yes, but then next question comes are hubs allowed to impersonate as a > spoke or endpoint? Is there any requirement that when endpoint makes > direct connection to other endpoint it knows that there cannot be any > other parties listening on the link? If there is such requirement then > also the hubs are not allowed to impersonate endpoints, but on the > other hand if we use CA infrastructure, then the CA can always issue > certificate allowing this kind of impersonation. > VM> In my view for the ADVPN case Hubs and spokes have permanent connections. Spokes may have temporary connections with other spokes and in such cases the temporary credentials should not allow any impersonation at all. That was the intent. Let me discuss this with Steve on how to resolve the same. > > 6. Gateways SHOULD allow for easy handoff of sessions in case > > endpoints are roaming, even if they cross policy boundaries. This > > means that TCP session breakage and packet loss should be avoided, > > when possible. > > > > This requirement is driven by use case 2.1. Today's endpoints are > > mobile and transition often between different networks (from 4G to > > WiFi and among various WiFi networks). > > This cannot come from case 2.1, as that is endpoint to endpoint, so > there is no gateway at all there. I would expect this would come from > 2.3 i.e. the endpoint to gateway use case. > > Or does this mean gateways should allow handoff from the > endpoint-gateway-endpoint to direct endpoint-endpoint link without > breaking TCP sessions? > VM> The intent was the first paragraph you mention, but I do not see any reason we should now allow for a direct connectivity either as you mention in the second paragraph. > > 8. Gateways and endpoints MUST be able to work when they are behind > > NAT boxes. However, it is especially difficult to handle cases where > > gateways are behind NATs and where two endpoints are both behind > > separate NATs. In those cases, workarounds MAY be used such as port > > forwarding by the NAT or detecting when two spokes are behind > > uncooperative NATs and using a hub in that case. > > > > This requirement is driven by use cases 2.1 and 2.2. Endpoints are > > often behind NATs and gateways sometimes are. IPsec should continue > > to work seamlessly regardless, using AD VPN techniques whenever > > possible and providing graceful fallback to hub and spoke techniques > > as needed. > > Does this also include discovery of the addresses? How about if we > have two endpoints talking to each other and one of the nat boxes is > restarted and one peers IP-address changes, and as the NATs are > restricted nats, which means they cannot connect to each other at all > after that without the help of the 3rd party. Also the 3rd party > cannot connect to either one of them, thus the recover must then start > from the endpoints so both of them connect to this 3rd party (hub) to > recover from the situation. > VM> I think the idea here is that spokes being behind NAT's, and the solution should allow for a tunnel setup between them. There can be external factors however like firewall/ NAT etc which may have cause issues and need to be dealt with seperately. > > > 9. Changes such as establishing a new IPsec SA SHOULD be reportable > > and manageable. However, creating a MIB or other management > > technique is not within scope for this effort. > > > > This requirement is driven by manageability concerns for all the use > > cases, especially use case 2.2. As IPsec networks become more > > dynamic, management tools become more essential. > > I would rule configuration MIB out of the scope, but I would actually > think it would be good idea to make reporting and statistics MIB. We > really need one in the IPsec, and this is effort I think we should > take here in ipsecme also for normal IPsec devices. > > VM> I agree with what Yoav said on this. I agree we should allow for logging/ tracking dynamic changes. Let me discuss with Steve on whether we should add having a MIB as a requirement for the same. > I am sure we are still missing some requirements, but thats my > comments for the existing requirements. I need to think bit more what > other requirements we might have. > VM> I would love to hear such requirements. Thanks, Vishwas > -- > kivinen@iki.fi > --f46d040839eb9a8e7204c9b11957 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tero,

Thanks a lot for your comments. My comments inline with a &= quot;VM>" prefix.

On Mon, Sep 10,= 2012 at 5:25 AM, Tero Kivinen <kivinen@iki.fi> wrote:
Paul Hoffman writes:
> This appeared on the list over two weeks ago and it has received no > comments since. This is supposed to be the WG's main work item, > folks.

My comments:

> 2.2. =A0Gateway-to-Gateway AD VPN Use Case
...
> =A0 =A0The spoke gateways can themselves come up and down, getting dif= ferent
> =A0 =A0IP addresses in the process, making th static configuration
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0^^
Typo.
VM> Perfect.
=A0

> 3.2. =A0Star Topology
...
> =A0 =A0This solution however does not work when the spokes get dynamic= IP
> =A0 =A0address which the "hub gateways" cannot be configured= with.

I think star topology works fine with dynamic IP addresses. You just
need to make sure that the spokes are the entities which brings up the
link, i.e. immediately when they boot up they put up the IPsec link
and keep it up all the time. There is other identities in the IPsec
world than IP-addresses...

I would remove the whole sentence.

VM> I think what we need to talk here is that in c= ase IP address is used as an identifier, we need to make sure that it works= even as the IP address changes or we can put it that IP address should not= be ever used as identifiers in such cases.
=A0
> =A0 =A0bandwidth. =A0A single packet in the hub-and-spoke scenario can= be
> =A0 =A0encrypted and decrypted three times. =A0It would be much prefer= able if

In the pure hub-and-spoke model I cannot really see more than two
times, one from the spoke to hub, and second time from the hub to
another spoke. If there is hub to hub links also then it is not pure
hub-and-spoke scenario anymore. I would replace the "three" with<= br> "multiple". I myself really had to read the first paragraph of th= is
section again to notice that you talk there that this section says
there can be multiple gateways selected as hub gateways.
OK. We can replace with multiple I agree it could even be more than 3 in= some cases.
=A0
> 4.1. =A0Gateway and Endpoint Requirements
...
> =A0 =A02. =A0Gateways and endpoints MUST allow IPsec Tunnels to be set= up
> =A0 =A0without any configuration changes, even when peer addresses get=
> =A0 =A0updated every time the device comes up.

This is unclear for me. Does that mean that anybody can connect to the
gateway and the gateway MUST allow IPsec Tunnels to be setup without
any configuration changes (like adding authentication credentials?). I
do not think so.

I think this needs to be clarified. Also endpoints do require
configuration changes before they can first time connect to the AD
VPN, for example you need to insert the credentials and most likely
also point at least one gateway for them to fetch rest of
configuration from them.

If this is just trying to say that already configured devices in the
AD VPN MUST be able to connect to any other configured device in the
AD VPN at any time, even when the IP addresses are not known
beforehand, then I think it should be said differently.

Anyways I am not sure what this is trying to say.=A0
VM>= ; In my view if the first time a hub is connected to a spoke we will need t= o do some configuration for sure, however as we add other similar spokes (c= ould be based on template), we would require no configuration at the Hub en= d for each spoke added. Let me know if I am clear here, I can update the do= cument with this.


> =A0 =A0This implies that SPD
> =A0 =A0entries or other configuration based on peer IP address will ne= ed to
> =A0 =A0be automatically updated, avoided, or handled in some manner to= avoid
> =A0 =A0a need to manually update policy whenever an address changes.
This is much more clear, and I think this most likely means that the
first paragraph was trying to say that already existing AD VPN members
should be able to connect other AD VPN members even when their
IP-addresses are not static.

Next question is how does the one member know to which address connect
to if also the destination member has changing IP address? And how to
punch holes to NATs that might be between them.
VM>= These are the exact questions we need to answer with the protocol solution= in my view.
=A0

> =A0 =A03. =A0Gateways MUST allow tunnel binding, such that application= s like
> =A0 =A0Routing using the tunnels can work seamlessly without any updat= es to
> =A0 =A0the higher level application configuration i.e. =A0OSPF configu= ration.

I have no idea what this requirement means. What is "tunnel binding&qu= ot;?
Where does this requirement come? Which use case drives this?
VM> Do let me know if the mail to Yoav makes it any clearer?
= =A0

> =A0 =A04. =A0In a hub-and-spoke topology, spoke gateways and endpoints= MUST
> =A0 =A0allow for direct communication with other spoke gateways and > =A0 =A0endpoints.

Hmm... why are you listing here spokes and endpoints as separate
entries. In the terminology I understood spoke also includes
endpoints?
VM> I agree good point. Will update.
=

> =A0 =A05. =A0One spoke MUST NOT be able to impersonate another spoke.<= br>
If spoke does not imply endpoints, then we should say that this also
applies to the endpoints, i.e. One endpoint or spoke MUST NOT be able
to impersonate another spokes or endpoints.

What about hubs? Are they allowed to impersonate other hubs? I assume
yes, but then next question comes are hubs allowed to impersonate as a
spoke or endpoint? Is there any requirement that when endpoint makes
direct connection to other endpoint it knows that there cannot be any
other parties listening on the link? If there is such requirement then
also the hubs are not allowed to impersonate endpoints, but on the
other hand if we use CA infrastructure, then the CA can always issue
certificate allowing this kind of impersonation.
=A0
VM> In my view for the ADVPN case Hubs and spokes h= ave permanent connections. Spokes may have temporary connections with other= spokes and in such cases the temporary credentials should not allow any im= personation at all. That was the intent. Let me discuss this with Steve on = how to resolve the same.
=A0
> =A0 =A06. =A0Gateways SHOULD allow for easy handoff of sessions in cas= e
> =A0 =A0endpoints are roaming, even if they cross policy boundaries. = =A0This
> =A0 =A0means that TCP session breakage and packet loss should be avoid= ed,
> =A0 =A0when possible.
>
> =A0 =A0This requirement is driven by use case 2.1. =A0Today's endp= oints are
> =A0 =A0mobile and transition often between different networks (from 4G= to
> =A0 =A0WiFi and among various WiFi networks).

This cannot come from case 2.1, as that is endpoint to endpoint, so
there is no gateway at all there. I would expect this would come from
2.3 i.e. the endpoint to gateway use case.

Or does this mean gateways should allow handoff from the
endpoint-gateway-endpoint to direct endpoint-endpoint link without
breaking TCP sessions?
VM> The intent was the first= paragraph you mention, but I do not see any reason we should now allow for= a direct connectivity either as you mention in the second paragraph.


> =A0 =A08. =A0Gateways and endpoints MUST be able to work when they are= behind
> =A0 =A0NAT boxes. =A0However, it is especially difficult to handle cas= es where
> =A0 =A0gateways are behind NATs and where two endpoints are both behin= d
> =A0 =A0separate NATs. =A0In those cases, workarounds MAY be used such = as port
> =A0 =A0forwarding by the NAT or detecting when two spokes are behind > =A0 =A0uncooperative NATs and using a hub in that case.
>
> =A0 =A0This requirement is driven by use cases 2.1 and 2.2. =A0Endpoin= ts are
> =A0 =A0often behind NATs and gateways sometimes are. =A0IPsec should c= ontinue
> =A0 =A0to work seamlessly regardless, using AD VPN techniques whenever=
> =A0 =A0possible and providing graceful fallback to hub and spoke techn= iques
> =A0 =A0as needed.

Does this also include discovery of the addresses? How about if we
have two endpoints talking to each other and one of the nat boxes is
restarted and one peers IP-address changes, and as the NATs are
restricted nats, which means they cannot connect to each other at all
after that without the help of the 3rd party. Also the 3rd party
cannot connect to either one of them, thus the recover must then start
from the endpoints so both of them connect to this 3rd party (hub) to
recover from the situation.
VM> I think the idea he= re is that spokes being behind NAT's, and the solution should allow for= a tunnel setup between them. There can be external factors however like fi= rewall/ NAT etc which may have cause issues and need to be dealt with seper= ately.

> =A0 =A09. =A0Changes such as establishing a new IPsec SA SHOULD be rep= ortable
> =A0 =A0and manageable. =A0However, creating a MIB or other management<= br> > =A0 =A0technique is not within scope for this effort.
>
> =A0 =A0This requirement is driven by manageability concerns for all th= e use
> =A0 =A0cases, especially use case 2.2. =A0As IPsec networks become mor= e
> =A0 =A0dynamic, management tools become more essential.

I would rule configuration MIB out of the scope, but I would actually
think it would be good idea to make reporting and statistics MIB. We
really need one in the IPsec, and this is effort I think we should
take here in ipsecme also for normal IPsec devices.

VM> I agree with what Yoav said on this. I agree w= e should allow for logging/ tracking dynamic changes. Let me discuss with S= teve on whether we should add having a MIB as a requirement for the same. =A0
I am sure we are still missing some requirements, but thats my
comments for the existing requirements. I need to think bit more what
other requirements we might have.
VM> I would love = to hear such requirements.

Thanks,
Vishwas
=A0
--
kivinen@iki.fi

--f46d040839eb9a8e7204c9b11957-- From kivinen@iki.fi Mon Sep 17 04:50:34 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1284721F8628 for ; Mon, 17 Sep 2012 04:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8rRdQP-RAKb for ; Mon, 17 Sep 2012 04:50:32 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0F18421F854A for ; Mon, 17 Sep 2012 04:50:31 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q8HBoOvV016083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Sep 2012 14:50:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q8HBoM95022121; Mon, 17 Sep 2012 14:50:22 +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: <20567.3710.740450.2640@fireball.kivinen.iki.fi> Date: Mon, 17 Sep 2012 14:50:22 +0300 From: Tero Kivinen To: Vishwas Manral In-Reply-To: References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20557.56357.878183.593537@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 132 min X-Total-Time: 50 min Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] STRONG NUDGE: Revised AD VPN Requirements 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, 17 Sep 2012 11:50:34 -0000 Vishwas Manral writes: > > > 3.2. Star Topology > > ... > > > This solution however does not work when the spokes get dynamic IP > > > address which the "hub gateways" cannot be configured with. > > > > I think star topology works fine with dynamic IP addresses. You just > > need to make sure that the spokes are the entities which brings up the > > link, i.e. immediately when they boot up they put up the IPsec link > > and keep it up all the time. There is other identities in the IPsec > > world than IP-addresses... > > > > I would remove the whole sentence. > > > I think what we need to talk here is that in case IP address is used > as an identifier, we need to make sure that it works even as the IP address > changes or we can put it that IP address should not be ever used as > identifiers in such cases. There is quite big difference "cannot be configured with" and "cannot use IP-addresses as identifiers". And I agree IP addresses should not be used as identifiers in these cases, but that actually DOES NOT prevent it working. The ID is just identifier that can be used for policy lookup, and the RFC5996 says: When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 does not require this address to match the address in the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. The contents of IDi/IDr are used purely to fetch the policy and authentication data related to the other party. So even when the spokes have dynamic IP addresses they can use whatever ID_IPV4_ADDR/ID_IPV6_ADDR they like to identify themselves to the other end. For example they could always use their internal IP-address, i.e. something like 10.22.8.1 when this device is responsible for the traffic to 10.22.8.0-10.22.12.255, or it could use IP address of 0.0.0.1 as this is first gateway and second gateway could use 0.0.0.2 etc... Both of those are completely legal in RFC5996 sense, but neither of them might not be good idea in practice. > > > 4.1. Gateway and Endpoint Requirements > > ... > > > 2. Gateways and endpoints MUST allow IPsec Tunnels to be setup > > > without any configuration changes, even when peer addresses get > > > updated every time the device comes up. > > > > This is unclear for me. Does that mean that anybody can connect to the > > gateway and the gateway MUST allow IPsec Tunnels to be setup without > > any configuration changes (like adding authentication credentials?). I > > do not think so. > > > > I think this needs to be clarified. Also endpoints do require > > configuration changes before they can first time connect to the AD > > VPN, for example you need to insert the credentials and most likely > > also point at least one gateway for them to fetch rest of > > configuration from them. > > > > If this is just trying to say that already configured devices in the > > AD VPN MUST be able to connect to any other configured device in the > > AD VPN at any time, even when the IP addresses are not known > > beforehand, then I think it should be said differently. > > > > Anyways I am not sure what this is trying to say. > > VM> In my view if the first time a hub is connected to a spoke we will need > to do some configuration for sure, however as we add other similar spokes > (could be based on template), we would require no configuration at the Hub > end for each spoke added. Let me know if I am clear here, I can update the > document with this. I would expect that adding new spoke to hub only requires initial configuration in the newly added spoke, and MAY require configuration changes in the hub where the spoke is connected to, but SHOULD NOT require configuration changes to the other hubs than the one where the spoke was connected to, and MUST NOT require configuration changes in other spokes. Or something like that for the adding new spoke to the AD VPN. To add new hub it might require more changes, i.e. adding new hub to the AD VPN do require initial configuration in the newly added hub, and MAY also require configuration changes to the other hubs, and MAY also require configuration changes to the spokes connecting to this new hub, but SHOULD NOT require any configuration changes to the spokes connected to the other hubs. Actually the current definition in the section 1.1 says: Hub - The central point in a star topology, generally implemented in a gateway. meaning, there can be only one hub. And I just wonder how can hub not be a gateway? I think it must always be a gateway, i.e. it always protect traffic flowing through the device, otherwise it is not hub it is server (and outside the scope of the AD VPN). Perhaps we should expand this and define several different types of devices: Hubs - The central point in a star topology, or one of the central points in the mesh style VPN, i.e. gateway where multiple other hubs or spokes connect to. The hubs usually forward traffic coming from encrypted links to other encrypted links, i.e. there is no devices connected to it in clear. Spoke - The edge devices in the a star topology, or gateway which forwards traffic from multiple cleartext devices to other hubs or spokes, and some of those other devices are connected to it in clear (i.e. it encrypt data coming from cleartext device and forwards it to the AD VPN). Endpoint device - A device that implements IPsec for its own traffic, but does not act as a gateway. Cleartext device - A device that does rely on the spokes to protect its traffic. Cleartext device might implement IPsec, but does not use it in currect setup. I.e. we should define that there are cleartext devices which talk in clear to the spokes, which encrypt the traffic and forward it either to hubs, other spokes, or endpoints, these are devices like those in the branch office network, which use spokes as their encryption providers. Then there is endpoint devices which take care of their own encryption, and connect directly to the spokes, hubs and other endpoints, but do not connect directly to the devices behind spokes. Note that endpoint can move to be cleartext device if it moves to network that is already protected by spoke. In the same way cleartext device can move to be endpoint device if it moves out from the network protected by the spoke. Those two are the end user devices, i.e. those devices where the user itself is. The spokes and hubs are just network devices forwarding traffic. Those definations might make things a bit more clear, especially when we are talking about the required configuration changes. I.e. we do not want to have any changes to any other Endpoint or cleartext devices than what we are modifying now (adding, removing), we may have changes to the neigbour spokes and hubs, but we should not have any changes to spokes, or hubs further away. > > > This implies that SPD > > > entries or other configuration based on peer IP address will need to > > > be automatically updated, avoided, or handled in some manner to avoid > > > a need to manually update policy whenever an address changes. > > > > This is much more clear, and I think this most likely means that the > > first paragraph was trying to say that already existing AD VPN members > > should be able to connect other AD VPN members even when their > > IP-addresses are not static. > > > > Next question is how does the one member know to which address connect > > to if also the destination member has changing IP address? And how to > > punch holes to NATs that might be between them. > > > These are the exact questions we need to answer with the protocol > solution in my view. I meant to say is that requirement that it should work in such setup too, or do we just say that there is no such requirement, and on end of the connection must have static ip-address. Also talking about NATs which classes can be behind NAT? I assume we do require that endpoint devices MUST be able to be behind NAT. Cleartext devices does not matter, as they do not do IPsec themselves. Do we require that spokes also can be behind NATs? What about hubs? I would expect that spokes can be behind NAT, so we should probably require that, but I am not sure if the hubs themselves will ever be behind NAT, and it would make things much easier if we say that there is no requirement to support setups where hubs are behind NATs. This would solve the problem that when new spoke is added and it is trying to fetch to configuration, it knows what IP address to use as the IP-address of the hub can be configured to it... If all the hubs have dynamic IP-addresses things get really complex... > > > 3. Gateways MUST allow tunnel binding, such that applications like > > > Routing using the tunnels can work seamlessly without any updates to > > > the higher level application configuration i.e. OSPF configuration. > > > > I have no idea what this requirement means. What is "tunnel binding"? > > Where does this requirement come? Which use case drives this? > > > Do let me know if the mail to Yoav makes it any clearer? Not really. I still do not understand what you mean by tunnel binding. > > > 4. In a hub-and-spoke topology, spoke gateways and endpoints MUST > > > allow for direct communication with other spoke gateways and > > > endpoints. > > > > Hmm... why are you listing here spokes and endpoints as separate > > entries. In the terminology I understood spoke also includes > > endpoints? > > > I agree good point. Will update. Actually I think it would be easier if we make bigger changes to the terminology, like we I proposed earlier. I.e. define roles of hub and spokes better, and not tie them to the star-topology, like we currently do. And in my version the spokes does not include endpoints, as endpoints do not have any cleartext devices behind them. > > > 5. One spoke MUST NOT be able to impersonate another spoke. > > > > If spoke does not imply endpoints, then we should say that this also > > applies to the endpoints, i.e. One endpoint or spoke MUST NOT be able > > to impersonate another spokes or endpoints. > > > > What about hubs? Are they allowed to impersonate other hubs? I assume > > yes, but then next question comes are hubs allowed to impersonate as a > > spoke or endpoint? Is there any requirement that when endpoint makes > > direct connection to other endpoint it knows that there cannot be any > > other parties listening on the link? If there is such requirement then > > also the hubs are not allowed to impersonate endpoints, but on the > > other hand if we use CA infrastructure, then the CA can always issue > > certificate allowing this kind of impersonation. > > > > In my view for the ADVPN case Hubs and spokes have permanent > connections. This is not specified anywhere. If such requirement exists, we need to list it as requirement. I for example do not agree on that. I think hub-to-hub connections should be permanent, but hub-to-spoke connections might not be permanent, as one spoke might decide it is forwarding stuff so much to some other hub, that it might be better to connect directly to that hub, and only use local hub for more local traffic. > Spokes may have temporary connections with other spokes > and in such cases the temporary credentials should not allow any > impersonation at all. That was the intent. Let me discuss this with > Steve on how to resolve the same. Ok. > > > 6. Gateways SHOULD allow for easy handoff of sessions in case > > > endpoints are roaming, even if they cross policy boundaries. This > > > means that TCP session breakage and packet loss should be avoided, > > > when possible. > > > > > > This requirement is driven by use case 2.1. Today's endpoints are > > > mobile and transition often between different networks (from 4G to > > > WiFi and among various WiFi networks). > > > > This cannot come from case 2.1, as that is endpoint to endpoint, so > > there is no gateway at all there. I would expect this would come from > > 2.3 i.e. the endpoint to gateway use case. > > > > Or does this mean gateways should allow handoff from the > > endpoint-gateway-endpoint to direct endpoint-endpoint link without > > breaking TCP sessions? > > > The intent was the first paragraph you mention, but I do not see any > reason we should now allow for a direct connectivity either as you mention > in the second paragraph. I am lost now. I think this requirement needs to be specified more clearly, so I can understand what is mean by it. > > > 8. Gateways and endpoints MUST be able to work when they are behind > > > NAT boxes. However, it is especially difficult to handle cases where > > > gateways are behind NATs and where two endpoints are both behind > > > separate NATs. In those cases, workarounds MAY be used such as port > > > forwarding by the NAT or detecting when two spokes are behind > > > uncooperative NATs and using a hub in that case. > > > > > > This requirement is driven by use cases 2.1 and 2.2. Endpoints are > > > often behind NATs and gateways sometimes are. IPsec should continue > > > to work seamlessly regardless, using AD VPN techniques whenever > > > possible and providing graceful fallback to hub and spoke techniques > > > as needed. > > > > Does this also include discovery of the addresses? How about if we > > have two endpoints talking to each other and one of the nat boxes is > > restarted and one peers IP-address changes, and as the NATs are > > restricted nats, which means they cannot connect to each other at all > > after that without the help of the 3rd party. Also the 3rd party > > cannot connect to either one of them, thus the recover must then start > > from the endpoints so both of them connect to this 3rd party (hub) to > > recover from the situation. > > > I think the idea here is that spokes being behind NAT's, and the > solution should allow for a tunnel setup between them. There can be > external factors however like firewall/ NAT etc which may have cause issues > and need to be dealt with seperately. The original requirement talked about gateways and endpoints, and gateways also includes hubs. I think we really need to define those roles more clearly. -- kivinen@iki.fi From Chris.Ulliott@cesg.gsi.gov.uk Mon Sep 17 17:11:36 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D51E21F8628 for ; Mon, 17 Sep 2012 17:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvm2vXNMl9WX for ; Mon, 17 Sep 2012 17:11:29 -0700 (PDT) Received: from mail205.messagelabs.com (mail205.messagelabs.com [85.158.140.179]) by ietfa.amsl.com (Postfix) with ESMTP id E420221F8618 for ; Mon, 17 Sep 2012 17:11:28 -0700 (PDT) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-2.tower-205.messagelabs.com!1347927087!9463801!1 X-Originating-IP: [62.25.106.208] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 19804 invoked from network); 18 Sep 2012 00:11:27 -0000 Received: from gateway-102.energis.gsi.gov.uk (HELO mx.hosting-w.gsi.gov.uk) (62.25.106.208) by server-2.tower-205.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Sep 2012 00:11:27 -0000 From: "Ulliott, Chris" To: "'paul.hoffman@vpnc.org'" Date: Tue, 18 Sep 2012 01:11:21 +0100 Thread-Topic: [IPsec] STRONG NUDGE: Revised AD VPN Requirements UNCLASSIFIED Thread-Index: Ac2N33XdbFzxrkPhSLSCns+6QkFpnwHUqx/w Message-ID: <20549DD10769DA47A86F0F0FAF8012DD0391560F56@PIACHEVEX00.GCHQ.GOV.UK> In-Reply-To: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'ipsec@ietf.org'" Subject: Re: [IPsec] STRONG NUDGE: Revised AD VPN Requirements UNCLASSIFIED 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, 18 Sep 2012 00:11:36 -0000 Classification:UNCLASSIFIED Paul, I'm keen to run the use cases past the telecomms community in the UK as th= ey are the people who have to face these challenges on a regular basis (an= d we seem to have an absence of users contributing to this debate for some= reason). I don't have a date for this yet, but it's likely to be late Oct= ober before I can get all the right people together... When would you idea= lly like comments by and would it be possible to push that date back to ac= commodate such an effort. Chris [This message has been sent by a mobile device] ----- Original Message ----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Saturday, September 08, 2012 05:31 PM To: IPsecme WG Subject: [IPsec] STRONG NUDGE: Revised AD VPN Requirements This appeared on the list over two weeks ago and it has received no commen= ts since. This is supposed to be the WG's main work item, folks. --Paul Hoffman On Aug 23, 2012, at 9:02 AM, Stephen Hanna wrote: > Vishwas and I have updated the AD VPN Problem Statement > and Requirements draft to address the comments received > on the previous version and remaining comments from > earlier email discussions. The new version is available at >=20 > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem >=20 > A summary of the changes in this version is included at > the end of this message. >=20 > Please review this document and provide any comments on > the existing requirements or suggestions for new ones. >=20 > For requirement 3, Vishwas will be starting an email > thread soon so that the WG can discuss what this text > means, whether we want to keep it, and how it can be > made clearer. >=20 > Thanks, >=20 > Steve >=20 > ------------ >=20 > Summary of Changes in draft-ietf-ipsecme-ad-vpn-00.txt >=20 > * Changed draft name from p2p-vpn to ad-vpn. >=20 > * Added a paragraph for each requirement, explaining how > that requirement is driven by the use cases. >=20 > * In requirement 1, defined what we mean by minimizing > configuration changes. >=20 > * In requirement 2, explained that this requirement implies > that SPD entries and other configuration based on peer > IP address will need to be automatically updated when > the peer's IP address changes. >=20 > * Split requirement 4 into two requirements (now 4 and 5). >=20 > * In requirement 6 (formerly 5), explained what we mean > by "easy handoff of sessions": avoid TCP session breakage > and packet loss, when possible. >=20 > * In requirement 8 (formerly 7), acknowledged the difficulty > of handling cases where gateways are behind NATs or where > two endpoints are both behind separate NATs. In those cases, > we may need to use workarounds such as port forwarding by > the NATs or falling back to a hub and spoke architecture. >=20 > * Added new requirement 9 around manageability. >=20 > * Added new requirement 10 around cross-organization use. >=20 > * Added new requirement 11 saying that administrators should > be able to limit topologies for security and other reasons. >=20 > * Fixed typos and other minor wording issues. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec **************************************************************************= ** Communications with GCHQ may be monitored and/or recorded=20 for system efficiency and other lawful purposes. Any views or=20 opinions expressed in this e-mail do not necessarily reflect GCHQ=20 policy. This email, and any attachments, is intended for the=20 attention of the addressee(s) only. Its unauthorised use,=20 disclosure, storage or copying is not permitted. If you are not the intended recipient, please notify postmaster@gchq.gsi.gov.uk. =20 This information is exempt from disclosure under the Freedom of=20 Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to=20 GCHQ on 01242 221491 ext 30306 (non-secure) or email infoleg@gchq.gsi.gov.uk **************************************************************************= ** The original of this email was scanned for viruses by the Government Secur= e Intranet virus scanning service supplied by Cable&Wireless Worldwide in = partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On l= eaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored and/or r= ecorded for legal purposes. From paul.hoffman@vpnc.org Mon Sep 17 17:27: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 DF50F21E808C for ; Mon, 17 Sep 2012 17:27:17 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTvLxYpqiLuW for ; Mon, 17 Sep 2012 17:27:17 -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 6CE0221E804A for ; Mon, 17 Sep 2012 17:27:17 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q8I0RCpO064855 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Sep 2012 17:27:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: Paul Hoffman In-Reply-To: <20549DD10769DA47A86F0F0FAF8012DD0391560F56@PIACHEVEX00.GCHQ.GOV.UK> Date: Mon, 17 Sep 2012 17:27:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <744446A6-295A-4958-94A0-F002B95C957E@vpnc.org> References: <20549DD10769DA47A86F0F0FAF8012DD0391560F56@PIACHEVEX00.GCHQ.GOV.UK> To: "Ulliott, Chris" X-Mailer: Apple Mail (2.1486) Cc: "'ipsec@ietf.org'" Subject: Re: [IPsec] STRONG NUDGE: Revised AD VPN Requirements UNCLASSIFIED 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, 18 Sep 2012 00:27:18 -0000 On Sep 17, 2012, at 5:11 PM, "Ulliott, Chris" = wrote: > I'm keen to run the use cases past the telecomms community in the UK = as they are the people who have to face these challenges on a regular = basis (and we seem to have an absence of users contributing to this = debate for some reason). I don't have a date for this yet, but it's = likely to be late October before I can get all the right people = together... When would you ideally like comments by and would it be = possible to push that date back to accommodate such an effort. Weeks ago, seriously. I am very hesitant to wait for additional = requirements comments from people who don't even know about the work = without some reasonable expectation that those comments will be useful. = I don't want to be harsh, but is there a particular reason that those = folks have not participated in the preceding six months? --Paul Hoffman= From paul@nohats.ca Thu Sep 20 09:22:31 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 A881021F87F4 for ; Thu, 20 Sep 2012 09:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8MLhFBywHkc for ; Thu, 20 Sep 2012 09:22:30 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id A2FD321F877A for ; Thu, 20 Sep 2012 09:22:29 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 19D8D83321; Thu, 20 Sep 2012 12:22:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0CCF982FB5 for ; Thu, 20 Sep 2012 12:22:28 -0400 (EDT) Date: Thu, 20 Sep 2012 12:22:28 -0400 (EDT) From: Paul Wouters To: IPsecme WG In-Reply-To: <20567.3710.740450.2640@fireball.kivinen.iki.fi> Message-ID: References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20557.56357.878183.593537@fireball.kivinen.iki.fi> <20567.3710.740450.2640@fireball.kivinen.iki.fi> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [IPsec] IPsec compression - vulnerable to CRIME-style attack or not? 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, 20 Sep 2012 16:22:31 -0000 Hi, With the TLS compression attack of CRIME hitting the news recently, I was wondering about this attack against IPsec compression. While I think the attack is much harder, due to the HMAC, if I understand it correctly it could still be tried once per user http request. So if the attacker can trigger the user into connecting multiple times to some http/https side through the ipsec tunnel, it could attempt the same one octet replacement. The Linux *swan implementations do not request compression per default, but will always do it when the other end requests this, as it was considered harmless to comply. I want to ensure this train of thought is still valid, or whether this behaviour should be modified in "no means no". Paul From yaronf.ietf@gmail.com Thu Sep 20 09:33:19 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1696821F8762 for ; Thu, 20 Sep 2012 09:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.956 X-Spam-Level: X-Spam-Status: No, score=-101.956 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_NJABL_PROXY=1.643, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4NntQSM4xphJ for ; Thu, 20 Sep 2012 09:33:18 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58D3E21F86DE for ; Thu, 20 Sep 2012 09:33:18 -0700 (PDT) Received: by eekb45 with SMTP id b45so1079142eek.31 for ; Thu, 20 Sep 2012 09:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=/DQwO00mqWbgVLFvlUI5XSWwkSa+CbRxhUbQN+mUei0=; b=uEspRZkDApl+Gqp+cmStG9udP6VZLx86YxAgh/2AnvYI1fH4JlcSKWdnXRWN5iaSJ2 0ePv701Q+p9jjdrLiLeK1jBae8uXBGGQyDUEHB8N/rXT7XtW3kwm4QD8LGxA3/O6ucVQ ucpCFko2mnI8PNLa1YVPnnr3jRxdBoe2JofPec9r1sxm/iV5/AeWV6oIdhVpMQZ6mNtJ DYJ8AKGdzDFm8uF4v0lSMUTe2I8YCkUYxRwcjL3wZxppv21o5BKwZzBzciqzUcMQi5LW KMd/Gq52az6i+UBE0Mw3EoEPznK8veKq7Iay1Hu623pFzEasJSvpv9TbSuJ5S2MSdm48 CS/g== Received: by 10.14.203.73 with SMTP id e49mr2944786eeo.27.1348158797510; Thu, 20 Sep 2012 09:33:17 -0700 (PDT) Received: from [192.168.1.188] (80.179.201.42.cable.012.net.il. [80.179.201.42]) by mx.google.com with ESMTPS id l42sm16989103eep.1.2012.09.20.09.33.15 (version=SSLv3 cipher=OTHER); Thu, 20 Sep 2012 09:33:16 -0700 (PDT) Message-ID: <505B454A.3020807@gmail.com> Date: Thu, 20 Sep 2012 19:33:14 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Paul Wouters References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20557.56357.878183.593537@fireball.kivinen.iki.fi> <20567.3710.740450.2640@fireball.kivinen.iki.fi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] IPsec compression - vulnerable to CRIME-style attack or not? 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, 20 Sep 2012 16:33:19 -0000 Hi Paul, Can you please clarify why the HMAC mitigates this attack? As far as I understand the attack, everything takes place inside the protected tunnel, so the HMAC is always correct. What could mitigate it of course is Traffic Flow Confidentiality (TFC). In cases where compression is highly effective, maybe it makes sense to sacrifice a few bytes for extra padding. Thanks, Yaron On 09/20/2012 07:22 PM, Paul Wouters wrote: > > Hi, > > With the TLS compression attack of CRIME hitting the news recently, I > was wondering about this attack against IPsec compression. > > While I think the attack is much harder, due to the HMAC, if I > understand it correctly it could still be tried once per user http > request. So if the attacker can trigger the user into connecting > multiple times to some http/https side through the ipsec tunnel, it > could attempt the same one octet replacement. > > The Linux *swan implementations do not request compression per default, > but will always do it when the other end requests this, as it was > considered harmless to comply. I want to ensure this train of thought > is still valid, or whether this behaviour should be modified in "no > means no". > > Paul > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From paul@nohats.ca Thu Sep 20 09:42:07 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC1121F87F4 for ; Thu, 20 Sep 2012 09:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ci9hhsFgoL6 for ; Thu, 20 Sep 2012 09:42:02 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 002BC21F8759 for ; Thu, 20 Sep 2012 09:42:01 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 3E17183321; Thu, 20 Sep 2012 12:42:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 31E7582FB5; Thu, 20 Sep 2012 12:42:01 -0400 (EDT) Date: Thu, 20 Sep 2012 12:41:58 -0400 (EDT) From: Paul Wouters To: Yaron Sheffer In-Reply-To: <505B454A.3020807@gmail.com> Message-ID: References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20557.56357.878183.593537@fireball.kivinen.iki.fi> <20567.3710.740450.2640@fireball.kivinen.iki.fi> <505B454A.3020807@gmail.com> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPsecme WG Subject: Re: [IPsec] IPsec compression - vulnerable to CRIME-style attack or not? 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, 20 Sep 2012 16:42:07 -0000 On Thu, 20 Sep 2012, Yaron Sheffer wrote: > Can you please clarify why the HMAC mitigates this attack? As far as I > understand the attack, everything takes place inside the protected tunnel, so > the HMAC is always correct. I thought, but please correct me if I'm wrong here, that with TLS you can send multiple one-byte-off packets to see the response of the TLS server. The error or lucky guess will be shown by a different response on the server. With IPsec, I thought once you sent the one packet, the HMAC with counter would prevent you from sending more packets for testing until the client starts another request packet for the attacker to modify. Though thinking about it again, I guess if the crypto fails on the packet, it is not received so you can send more packets here as well. Paul From nico@cryptonector.com Thu Sep 20 09:43: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 7816E21F84D5 for ; Thu, 20 Sep 2012 09:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXbqvXiXFJ+w for ; Thu, 20 Sep 2012 09:43:15 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id EDDE621F847C for ; Thu, 20 Sep 2012 09:43:15 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 9E8151B4057 for ; Thu, 20 Sep 2012 09:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=/TZ4I73OL8mu4wZC4hWg 9gHiNac=; b=boIaWsTI4kXTw+iLvPFhg2WQhUhZVxvzm+U7lnalhmFt3RfAXyu7 YXgXiuw4xetQBzmzEhhclDeGMlOpWBm1IAlHEA0t9/exqZ9SHG/MKvxlLVDv349m f8fzAenhRVAzctZMc5SWWP7DSy4blpAHwCvOf0iZMtjoqKOu5rEKUGI= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 7BEBE1B4009 for ; Thu, 20 Sep 2012 09:43:15 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3181196pbb.31 for ; Thu, 20 Sep 2012 09:43:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.220.104 with SMTP id pv8mr8201091pbc.119.1348159395162; Thu, 20 Sep 2012 09:43:15 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 09:43:15 -0700 (PDT) In-Reply-To: References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20557.56357.878183.593537@fireball.kivinen.iki.fi> <20567.3710.740450.2640@fireball.kivinen.iki.fi> Date: Thu, 20 Sep 2012 11:43:15 -0500 Message-ID: From: Nico Williams To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Cc: IPsecme WG Subject: Re: [IPsec] IPsec compression - vulnerable to CRIME-style attack or not? 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, 20 Sep 2012 16:43:16 -0000 On Thu, Sep 20, 2012 at 11:22 AM, Paul Wouters wrote: > With the TLS compression attack of CRIME hitting the news recently, I > was wondering about this attack against IPsec compression. Well, in so far as IPsec doesn't have cookies or anything like a bearer token, it's safe. However, if you were using IPsec to protect HTTP web traffic, and if the attacker can find some way to either be an IPsec peer of your client or get your client to use unsecured HTTP connections by which the attacker can inject adaptive chosen plaintext for use in HTTP secured with IPsec, then that would be vulnerable, yes. The key is: what's running on top of IPsec? My thinking is that compression of data needs to be pushed to as high a layer as possible (i.e., the application layer), where decisions about what to be compressed (e.g., bulk non-voice/non-real time, therefore bufferable data) can be left to the part of the system that can best make them (i.e., the application). Nico -- From paul@nohats.ca Thu Sep 20 09:48: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 919B321F86B5 for ; Thu, 20 Sep 2012 09:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xa+WgwjPMDcr for ; Thu, 20 Sep 2012 09:48:26 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2038921F86AA for ; Thu, 20 Sep 2012 09:48:26 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 7C37A83321; Thu, 20 Sep 2012 12:48:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6D5B782FB5; Thu, 20 Sep 2012 12:48:25 -0400 (EDT) Date: Thu, 20 Sep 2012 12:48:25 -0400 (EDT) From: Paul Wouters To: Nico Williams In-Reply-To: Message-ID: References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20557.56357.878183.593537@fireball.kivinen.iki.fi> <20567.3710.740450.2640@fireball.kivinen.iki.fi> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IPsecme WG Subject: Re: [IPsec] IPsec compression - vulnerable to CRIME-style attack or not? 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, 20 Sep 2012 16:48:26 -0000 On Thu, 20 Sep 2012, Nico Williams wrote: > On Thu, Sep 20, 2012 at 11:22 AM, Paul Wouters wrote: >> With the TLS compression attack of CRIME hitting the news recently, I >> was wondering about this attack against IPsec compression. > > Well, in so far as IPsec doesn't have cookies or anything like a > bearer token, it's safe. This is not about breaking the IPsec layer, but guessing the session cookie of an http/https session protected by an IPsec layer. > However, if you were using IPsec to protect > HTTP web traffic, and if the attacker can find some way to either be > an IPsec peer of your client or get your client to use unsecured HTTP > connections by which the attacker can inject adaptive chosen plaintext > for use in HTTP secured with IPsec, then that would be vulnerable, > yes. But would they be _more_ vulnerable with compression? If not, then there is nothing we can do. If compresion does make these attacks easier, I want to change the default of always allowing it. > My thinking is that compression of data needs to be pushed to as high > a layer as possible (i.e., the application layer), where decisions > about what to be compressed (e.g., bulk non-voice/non-real time, > therefore bufferable data) can be left to the part of the system that > can best make them (i.e., the application). Yes, compression needs to happen at the plaintext layer, otherwise it wouldn't compress that much to begin with. Paul From nico@cryptonector.com Thu Sep 20 10:13: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 6FAD421F872E for ; Thu, 20 Sep 2012 10:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.051 X-Spam-Level: X-Spam-Status: No, score=-2.051 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4naACIUZwq6 for ; Thu, 20 Sep 2012 10:13:37 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id EB15B21F872A for ; Thu, 20 Sep 2012 10:13:36 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 0B3BDB805C for ; Thu, 20 Sep 2012 10:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=8QveZC4Tg6KfB+pHvfYH ZgExsdY=; b=My3e7ZGbiA0Dk0QlZzsO8/m5jTtsFQKSDLYxjOIGo5ZgAY1/W9v/ Pn6Bzdk1bD4eDvI1GvQrFpW1IsQxwKJiIenMCIgc4jjRlRkYP0EAmuXKkLH4z5rR bPGyk5rN689U09nLYFx0mleMSJ91nOUkYkjaeRyzAe08KyzRNCTtTiQ= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id EF5D6B8057 for ; Thu, 20 Sep 2012 10:13:34 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3237708pbb.31 for ; Thu, 20 Sep 2012 10:13:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.224.73 with SMTP id ra9mr8503364pbc.85.1348161214634; Thu, 20 Sep 2012 10:13:34 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 10:13:34 -0700 (PDT) In-Reply-To: References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20557.56357.878183.593537@fireball.kivinen.iki.fi> <20567.3710.740450.2640@fireball.kivinen.iki.fi> Date: Thu, 20 Sep 2012 12:13:34 -0500 Message-ID: From: Nico Williams To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Cc: IPsecme WG Subject: Re: [IPsec] IPsec compression - vulnerable to CRIME-style attack or not? 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, 20 Sep 2012 17:13:38 -0000 On Thu, Sep 20, 2012 at 11:48 AM, Paul Wouters wrote: > On Thu, 20 Sep 2012, Nico Williams wrote: >> However, if you were using IPsec to protect >> HTTP web traffic, and if the attacker can find some way to either be >> an IPsec peer of your client or get your client to use unsecured HTTP >> connections by which the attacker can inject adaptive chosen plaintext >> for use in HTTP secured with IPsec, then that would be vulnerable, >> yes. > > But would they be _more_ vulnerable with compression? If not, then there > is nothing we can do. If compresion does make these attacks easier, I > want to change the default of always allowing it. For HTTP (with cookies) the use of compression at *any* lower layer [that provides session cryptographic protection] creates this vulnerability. >> My thinking is that compression of data needs to be pushed to as high >> a layer as possible (i.e., the application layer), where decisions >> about what to be compressed (e.g., bulk non-voice/non-real time, >> therefore bufferable data) can be left to the part of the system that >> can best make them (i.e., the application). > > Yes, compression needs to happen at the plaintext layer, otherwise it > wouldn't compress that much to begin with. I didn't say otherwise. I said that compression should happen at a layer (the application layer) that is higher than the transport protection layer (TLS, ESP, SSH, whatever). I did not imply that the alternative is to try to compress at a layer below that where encryption takes place. From sfluhrer@cisco.com Thu Sep 20 10:38:25 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8C321F86A3 for ; Thu, 20 Sep 2012 10:38:25 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vj5ZsHBrXCdk for ; Thu, 20 Sep 2012 10:38:25 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2912621F8747 for ; Thu, 20 Sep 2012 10:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2818; q=dns/txt; s=iport; t=1348162705; x=1349372305; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CjwSlP379Ztnl3Zt2x32ORaCRvDDyu2QUo9beMnIDRc=; b=Awl6FSbKQNPrwRtPJaAXCpmEui0QS/VM8t0nylyCZpRkZZJrKCb8gSpK lKc0Rci6slW+FgKjqwwSQxI0TW05vM54VW1uAwQZZxsDcrLqIyspaAQXT 3ROaanqQwZQN5dG+JkPrgsGRNMdvDUYz00Po0rABEtsot63nSa+WmAWzG 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHBTW1CtJXHA/2dsb2JhbABFvSOBCIIgAQEBBAEBAQ8BJzQLDAQCAQgRBAEBAQoUCQcnCxQJCAIEAQ0FCBIIh2ELmgmgEQSLHIViYAOkHIFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,455,1344211200"; d="scan'208";a="120663261" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 20 Sep 2012 17:38:24 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8KHc6nt016595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Sep 2012 17:38:21 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Thu, 20 Sep 2012 12:38:20 -0500 From: "Scott Fluhrer (sfluhrer)" To: Nico Williams , Paul Wouters Thread-Topic: [IPsec] IPsec compression - vulnerable to CRIME-style attack or not? Thread-Index: AQHNl08NBcciqGHLJUChgzEwifDv3peTe/lQ Date: Thu, 20 Sep 2012 17:38:19 +0000 Message-ID: References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20557.56357.878183.593537@fireball.kivinen.iki.fi> <20567.3710.740450.2640@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {C8281E9A-4E98-4664-933F-158647426F39} x-cr-hashedpuzzle: DeFs EaI2 GYdU HuHS IDRE NPkm Qs5a RgaL SEmW VP4C VkXj Yst+ aJN4 atlu bS2/ bspI; 3; aQBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAbgBpAGMAbwBAAGMAcgB5AHAAdABvAG4AZQBjAHQAbwByAC4AYwBvAG0AOwBwAGEAdQBsAEAAbgBvAGgAYQB0AHMALgBjAGEA; Sosha1_v1; 7; {C8281E9A-4E98-4664-933F-158647426F39}; cwBmAGwAdQBoAHIAZQByAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Thu, 20 Sep 2012 17:38:14 GMT; UgBFADoAIABbAEkAUABzAGUAYwBdACAASQBQAHMAZQBjACAAYwBvAG0AcAByAGUAcwBzAGkAbwBuACAALQAgAHYAdQBsAG4AZQByAGEAYgBsAGUAIAB0AG8AIABDAFIASQBNAEUALQBzAHQAeQBsAGUAIABhAHQAdABhAGMAawAgAG8AcgAJAG4AbwB0AD8A x-originating-ip: [10.32.244.82] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19194.004 x-tm-as-result: No--43.381300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] IPsec compression - vulnerable to CRIME-style attack or not? 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, 20 Sep 2012 17:38:25 -0000 With IPSec, compression happens on a per-packet basis; the contents of prev= ious packets do not affect how this packet is compressed in any way. Hence= , there would be a vulnerability only if the attacker can somehow create a = single packet that contains both the unknown cookies, as well as his chosen= text. If he can, then likely he could (with sufficient cleverness) figure= out a way to exploit it. However, if his chosen packets contain only what= he picked and not the cookies (or whatever else he is interested in), ther= e's no vulnerability. For TLS, compression is stateful; how this segment is compressed does depen= d on previous segments; for example, if the text of the segment appears exa= ctly as is in a previous segment, this entire datagram may be replaced with= a token that says [Insert X bytes from Y positions from the current stream= ]; if this entire datagram doesn't appear exactly as is, it'll be replaced = with more tokens, and so it won't compress as well. That makes compression= work much better (because it doesn't forget everything at the start of eac= h segment); however, it does introduce the vulnerability that CRIME is base= d on. I'm not arguing for/against the idea the compression ought to be done by th= e application; I'm merely talking about the likelihood of CRIME being an im= pact of IPSec right now. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of N= ico Williams Sent: Thursday, September 20, 2012 12:43 PM To: Paul Wouters Cc: IPsecme WG Subject: Re: [IPsec] IPsec compression - vulnerable to CRIME-style attack o= r not? On Thu, Sep 20, 2012 at 11:22 AM, Paul Wouters wrote: > With the TLS compression attack of CRIME hitting the news recently, I > was wondering about this attack against IPsec compression. Well, in so far as IPsec doesn't have cookies or anything like a bearer token, it's safe. However, if you were using IPsec to protect HTTP web traffic, and if the attacker can find some way to either be an IPsec peer of your client or get your client to use unsecured HTTP connections by which the attacker can inject adaptive chosen plaintext for use in HTTP secured with IPsec, then that would be vulnerable, yes. The key is: what's running on top of IPsec? My thinking is that compression of data needs to be pushed to as high a layer as possible (i.e., the application layer), where decisions about what to be compressed (e.g., bulk non-voice/non-real time, therefore bufferable data) can be left to the part of the system that can best make them (i.e., the application). Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nico@cryptonector.com Thu Sep 20 11:20: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 5C7F721F880C for ; Thu, 20 Sep 2012 11:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlpuHNAtkfI3 for ; Thu, 20 Sep 2012 11:20:43 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id AC19621F8806 for ; Thu, 20 Sep 2012 11:20:43 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 07F9C1F0087 for ; Thu, 20 Sep 2012 11:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=J9fMUEI5gF3l3wJqIly5YWx8ej8=; b=Hf9G0B/YL7R +gNFdQfRQnUGAwrh+h9nwkx1I4NVhId54TpMj97b2Ud8JbETHIohkmwMKhPfP4/2 z8ItO2aQ80VJMFBpWsBgxSDhCUPR7zjSzfx70RBBcN84SabhPcBDJlv5UtuNFKdc 2CEo2Ii3bbk8uigiPZG7o/XTKFz8eRII= Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id DC8651F001E for ; Thu, 20 Sep 2012 11:20:42 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so3355505pbb.31 for ; Thu, 20 Sep 2012 11:20:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.213.228 with SMTP id nv4mr9100618pbc.67.1348165242481; Thu, 20 Sep 2012 11:20:42 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Thu, 20 Sep 2012 11:20:42 -0700 (PDT) In-Reply-To: References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20557.56357.878183.593537@fireball.kivinen.iki.fi> <20567.3710.740450.2640@fireball.kivinen.iki.fi> Date: Thu, 20 Sep 2012 13:20:42 -0500 Message-ID: From: Nico Williams To: "Scott Fluhrer (sfluhrer)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: IPsecme WG , Paul Wouters Subject: Re: [IPsec] IPsec compression - vulnerable to CRIME-style attack or not? 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, 20 Sep 2012 18:20:44 -0000 On Thu, Sep 20, 2012 at 12:38 PM, Scott Fluhrer (sfluhrer) wrote: > With IPSec, compression happens on a per-packet basis; the contents of pr= evious packets do not affect how this packet is compressed in any way. Hen= ce, there would be a vulnerability only if the attacker can somehow create = a single packet that contains both the unknown cookies, as well as his chos= en text. If he can, then likely he could (with sufficient cleverness) figu= re out a way to exploit it. However, if his chosen packets contain only wh= at he picked and not the cookies (or whatever else he is interested in), th= ere's no vulnerability. Indeed, and for the BEAST attack being able to manage buffering (via a "flush" operation, in that case) was critical to the exploit. And such buffering functionality existed, indeed. If the question is "is IPsec (ESP) immune to this attack" and the answer is (as I think it is) "it depends on the application" then the fail-safe thing to do is to disable compression in IPsec (I'm not necessarily recommending that though). Nico -- From turners@ieca.com Fri Sep 21 07:19:53 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95D521F86FD for ; Fri, 21 Sep 2012 07:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.833 X-Spam-Level: X-Spam-Status: No, score=-100.833 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd755-VYymkz for ; Fri, 21 Sep 2012 07:19:53 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.56.195.19]) by ietfa.amsl.com (Postfix) with ESMTP id E293A21F884D for ; Fri, 21 Sep 2012 07:19:52 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id D2DFC51FA16AD; Fri, 21 Sep 2012 09:19:49 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway15.websitewelcome.com (Postfix) with ESMTP id C7DCF51FA168C for ; Fri, 21 Sep 2012 09:19:49 -0500 (CDT) Received: from [108.18.174.220] (port=56634 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1TF457-0007Vo-Gd; Fri, 21 Sep 2012 09:19:49 -0500 Message-ID: <505C7784.3080803@ieca.com> Date: Fri, 21 Sep 2012 10:19:48 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.220]:56634 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [IPsec] brainpool summary, suggested way ahead, and comments on draft 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, 21 Sep 2012 14:19:54 -0000 I'd like to discuss the IEEE's request for brainpool code points additions in the Group Description registry (https://www.iana.org/assignments/ipsec-registry) on this mailing list. I realize it's not in scope of the WG, but all the right people are here so I'd like to ask for the wg chair's and member's indulgence on this matter. Here's the summary of events as I remember them: Stephen and I got an informal liaison from IEEE 802.11 requesting code point assignments in the Group Description section of https://www.iana.org/assignments/ipsec-registry. Since then we've received the official liaison. And we figured inviting Dorthy along to secir would cut down on some email. My initial thought was that adding anything to this registry was an update to IKEv1 and that was pretty much a no-go because IKEv1 is obsolete. But, the registry is RFC required so that's not strictly true. That is, other code points have been assigned after IKEv1 was obsoleted. The other thing that came to light was that the code points were in fact not going to be used by IKEv1 they were being used by another protocol, the IEEE 802.11 SAE (Simultaneous Authentication of Equals) protocol. I think it's fair to say that at the meeting most people weren't thrilled that IEEE plans to reuse the registry. We discussed setting up a new registry or pointing from the existing registry to a new registry, but the IEEE folks didn't like that because their spec is apparently not up for change until 2015 (Tero has submitted comments on this topic in IEEE). What I thought we came to was that Dan would publish a draft that requested the points and that the "notes" column would contain "not for IKEv1" - and then we'd talk about it. Dan submitted the draft requesting 14 code points with "not for IKEv1" in the notes column for each code point. I forwarded it to secdir and here we are. ^ | summary | way ahead discussion v From the discussion following publication, it's still clear the dual use of the registry is still unloved. I share that view. I think it comes down to this: - On the one hand, putting "not for IKEv1" in the notes column assumes that whoever consults the registry will make note of the note and not implement (or ask for them to be implemented) the code points in IKEv1. Concerns have been expressed that the note won't be enough to stop people asking for IKEv1 products to support these new code points - not thrilled about this prospect. - On the other hand, getting the IEEE spec to point to a new registry is (or might be) a no-go because of their publishing cycle. Assuming the IEEE spec can't be changed and we don't assign the code points, I'm sure some kind of inter-SDO struggle/spat will occur - not thrilled about this this prospect either. In this unfortunate situation, I'd like everyone to consider the (third surgically attached) hand that shares the burden: reserve the code points for 802.11 SAE in the Group Description registry, be very explicit about it in the draft/regstry, and then point from the Group Description registry to another registry (thanks to whoever suggested this at the secdir lunch we probably should have explored this more). The burden is then shared by the IETF assigning code points for something some despise/dislike and the IEEE implementers following an additional link from the registry they've already got to consult (they have to follow the link because the registry values aren't copied to their spec). The registry entries would appear as follows (well Value, Group, Reference, and Notes would normally appear on one line but it wraps in email and I thought this would be easier to follow): Value ----- 27-y Group ----------------------- Reserved for 802.11 SAE Description ------------------ This specification Notes ----------------------------------------- Not for use with IKEv1 - see xyz registry and then link 27-y to the curve names in the xyz registry (more on the number of code points at the end): Value Group Reference ----- ------------------------------ ------------------ 27 X-bit Brainpool: brainpoolPXr1 This specification ... ... .... Thoughts about this? | comments on draft v I'd like to make to the draft clearer about what's going on: #1) Retitle: OLD: Brainpool Elliptic Curves for the IKE Group Description Registry NEW: Brainpool Elliptic Curves for 802.11 SAE in the IKE Group Description Registry #2) tweak abstract: OLD: This memo allocates code points for fourteen new elliptic curve domain parameter sets over finite prime fields into a registry established by The Internet Key Exchange (IKE). NEW (where X is TBD at this point): This memo allocates code points for X new elliptic curve domain parameter sets over finite prime fields into a registry established by The Internet Key Exchange (IKE). These values are used by the IEEE 802.11 SAE (Simultaneous Authentication of Equals) protocol. The values found in this document are not for use in IKEv1. #3) tweak intro: OLD: IANA maintains a registry for [RFC2409] to map complete domain parameter sets to numbers. Other protocols, for example [IEEE802.11], refer to this registry for its convenience. Therefore, this memo instructs IANA to allocate new code points for the Brainpool curves defined in [RFC5639] to the registry established by [RFC2409]. NEW: [RFC2409] defined the Group Description registry that other protocols, for example [IEEE802.11], refer to for convenience. Non-IKE protocols referring to the registry is not ideal but also not a problem until the non-IKE protocol(s) want values added to the registry and these values are not for use by IKE. This is the case with the values in this document; they are not for use with IKEv1. The values in this document are for the Brainpool curves defined in [RFC5639] use with 802.11 SAE and the documents only purpose is to instruct IANA to allocate new code points. #4) Pick fewer curves. Not sure which ones but if we end up doing brainpool in TLS I'd like to see us pick the same ones. Not sure which ones those will be. I'm thinking like 3 - probably lining up with the 3 ECP groups. #5) Once we've settled on the format for the registry put it exactly as agreed in the IANA section. spt From paul.hoffman@vpnc.org Fri Sep 21 11:19:05 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9854B21E80B9 for ; Fri, 21 Sep 2012 11:19:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAdnPJnImeDy for ; Fri, 21 Sep 2012 11:19:05 -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 188E421E80B7 for ; Fri, 21 Sep 2012 11:19:05 -0700 (PDT) Received: from [10.20.30.108] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q8LIJ0hS067541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Sep 2012 11:19:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Paul Hoffman In-Reply-To: <505C7784.3080803@ieca.com> Date: Fri, 21 Sep 2012 11:19:00 -0700 Content-Transfer-Encoding: 7bit Message-Id: <2CB1A45B-7F15-4B2A-A3FA-BB2FD1AB1AD4@vpnc.org> References: <505C7784.3080803@ieca.com> To: Sean Turner X-Mailer: Apple Mail (2.1498) Cc: ipsec@ietf.org Subject: Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft 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, 21 Sep 2012 18:19:05 -0000 This all works for me, adding #6) Remove the snark. --Paul Hoffman From vishwas.ietf@gmail.com Fri Sep 21 12:15:15 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 9A87821E8039 for ; Fri, 21 Sep 2012 12:15:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzPblBtLfnXo for ; Fri, 21 Sep 2012 12:15:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A0F0311E808D for ; Fri, 21 Sep 2012 12:15:12 -0700 (PDT) Received: by lboj14 with SMTP id j14so4197461lbo.31 for ; Fri, 21 Sep 2012 12:15:11 -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=PeFpIMOaBWMCnO1UgH7J0ZVHnoZl1XJ9QCAwO95q3R0=; b=CTpj+kUgH3bvH8hARQPbvwmkKKo9dfQCzdfm9gW7rR0j7YmQgwX6WOgyZSjSHDqiTJ E75IXILlPmW3BqmBtgdAcqfdo9D5t4W0N0FpNKVAeGhBsHO/hb8X0B+2xniCucGMAFww rndL85alKnIlk89tWSohnfSN6zOw/lyLD6pRFqFF8Jd3i5vPg4Iz3WGjKhGj3G7PFLM3 hXencCpMJWhCECvHYLFW/UjvbrfrM66qt5gMfLU7YrSD/MIqeNVVfkHtdFizN6zv9v1h WjC5QpF0SlqHeop0JSpRVx9SVtyuVOQkK2wdNozPRpdLiORHd3MLUcubXynUm5tXFqht JSOg== MIME-Version: 1.0 Received: by 10.112.38.134 with SMTP id g6mr2057954lbk.39.1348254911397; Fri, 21 Sep 2012 12:15:11 -0700 (PDT) Received: by 10.114.0.14 with HTTP; Fri, 21 Sep 2012 12:15:11 -0700 (PDT) In-Reply-To: <20567.3710.740450.2640@fireball.kivinen.iki.fi> References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20557.56357.878183.593537@fireball.kivinen.iki.fi> <20567.3710.740450.2640@fireball.kivinen.iki.fi> Date: Fri, 21 Sep 2012 12:15:11 -0700 Message-ID: From: Vishwas Manral To: Tero Kivinen Content-Type: multipart/alternative; boundary=e0cb4efe2f080f7e4c04ca3b0f1c Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] STRONG NUDGE: Revised AD VPN Requirements 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, 21 Sep 2012 19:15:15 -0000 --e0cb4efe2f080f7e4c04ca3b0f1c Content-Type: text/plain; charset=ISO-8859-1 Hi Tero, Thanks for the great comments. Your main comments seem to be around clarifying the terminology and you have very thoughtfully expanded the definitions. I agree with most of it, just one question in the comments regarding the same. We seem to be on the same page here. Please see inline: On Mon, Sep 17, 2012 at 4:50 AM, Tero Kivinen wrote: > Vishwas Manral writes: > > > > 3.2. Star Topology > > > ... > > > > This solution however does not work when the spokes get dynamic IP > > > > address which the "hub gateways" cannot be configured with. > > > > > > I think star topology works fine with dynamic IP addresses. You just > > > need to make sure that the spokes are the entities which brings up the > > > link, i.e. immediately when they boot up they put up the IPsec link > > > and keep it up all the time. There is other identities in the IPsec > > > world than IP-addresses... > > > > > > I would remove the whole sentence. > > > > > I think what we need to talk here is that in case IP address is used > > as an identifier, we need to make sure that it works even as the IP > address > > changes or we can put it that IP address should not be ever used as > > identifiers in such cases. > > There is quite big difference "cannot be configured with" and "cannot > use IP-addresses as identifiers". And I agree IP addresses should not > be used as identifiers in these cases, but that actually DOES NOT > prevent it working. The ID is just identifier that can be used for > policy lookup, and the RFC5996 says: > > When using the > ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 > does not require this address to match the address in the IP header > of IKEv2 packets, or anything in the TSi/TSr payloads. The contents > of IDi/IDr are used purely to fetch the policy and authentication > data related to the other party. > > So even when the spokes have dynamic IP addresses they can use > whatever ID_IPV4_ADDR/ID_IPV6_ADDR they like to identify themselves to > the other end. For example they could always use their internal > IP-address, i.e. something like 10.22.8.1 when this device is > responsible for the traffic to 10.22.8.0-10.22.12.255, or it could use > IP address of 0.0.0.1 as this is first gateway and second gateway > could use 0.0.0.2 etc... Both of those are completely legal in RFC5996 > sense, but neither of them might not be good idea in practice. > Perfect. Though we are not solving the problems yet, I guess those are great inputs for the solution. > > > > > 4.1. Gateway and Endpoint Requirements > > > ... > > > > 2. Gateways and endpoints MUST allow IPsec Tunnels to be setup > > > > without any configuration changes, even when peer addresses get > > > > updated every time the device comes up. > > > > > > This is unclear for me. Does that mean that anybody can connect to the > > > gateway and the gateway MUST allow IPsec Tunnels to be setup without > > > any configuration changes (like adding authentication credentials?). I > > > do not think so. > > > > > > I think this needs to be clarified. Also endpoints do require > > > configuration changes before they can first time connect to the AD > > > VPN, for example you need to insert the credentials and most likely > > > also point at least one gateway for them to fetch rest of > > > configuration from them. > > > > > > If this is just trying to say that already configured devices in the > > > AD VPN MUST be able to connect to any other configured device in the > > > AD VPN at any time, even when the IP addresses are not known > > > beforehand, then I think it should be said differently. > > > > > > Anyways I am not sure what this is trying to say. > > > > VM> In my view if the first time a hub is connected to a spoke we will > need > > to do some configuration for sure, however as we add other similar spokes > > (could be based on template), we would require no configuration at the > Hub > > end for each spoke added. Let me know if I am clear here, I can update > the > > document with this. > > I would expect that adding new spoke to hub only requires initial > configuration in the newly added spoke, and MAY require configuration > changes in the hub where the spoke is connected to, but SHOULD NOT > require configuration changes to the other hubs than the one where the > spoke was connected to, and MUST NOT require configuration changes in > other spokes. > > Or something like that for the adding new spoke to the AD VPN. To add > new hub it might require more changes, i.e. adding new hub to the AD > VPN do require initial configuration in the newly added hub, and MAY > also require configuration changes to the other hubs, and MAY also > require configuration changes to the spokes connecting to this new > hub, but SHOULD NOT require any configuration changes to the spokes > connected to the other hubs. > > Actually the current definition in the section 1.1 says: > > > Hub - The central point in a star topology, generally implemented in > a gateway. > > meaning, there can be only one hub. And I just wonder how can hub not > be a gateway? I think it must always be a gateway, i.e. it always > protect traffic flowing through the device, otherwise it is not hub > it is server (and outside the scope of the AD VPN). > > Perhaps we should expand this and define several different types of > devices: > > Hubs - The central point in a star topology, or one of the central > points in the mesh style VPN, i.e. gateway where multiple > other hubs or spokes connect to. The hubs usually forward > traffic coming from encrypted links to other encrypted > links, i.e. there is no devices connected to it in clear. > > Spoke - The edge devices in the a star topology, or gateway which > forwards traffic from multiple cleartext devices to other > hubs or spokes, and some of those other devices are > connected to it in clear (i.e. it encrypt data coming from > cleartext device and forwards it to the AD VPN). > > Endpoint device - A device that implements IPsec for its own > traffic, but does not act as a gateway. > > Cleartext device - A device that does rely on the spokes to protect > its traffic. Cleartext device might implement > IPsec, but does not use it in currect setup. > > I.e. we should define that there are cleartext devices which talk in > clear to the spokes, which encrypt the traffic and forward it either > to hubs, other spokes, or endpoints, these are devices like those in > the branch office network, which use spokes as their encryption > providers. > > Then there is endpoint devices which take care of their own > encryption, and connect directly to the spokes, hubs and other > endpoints, but do not connect directly to the devices behind spokes. > Note that endpoint can move to be cleartext device if it moves to > network that is already protected by spoke. In the same way cleartext > device can move to be endpoint device if it moves out from the network > protected by the spoke. > > Those two are the end user devices, i.e. those devices where the user > itself is. The spokes and hubs are just network devices forwarding > traffic. > > Those definations might make things a bit more clear, especially when > we are talking about the required configuration changes. I.e. we do > not want to have any changes to any other Endpoint or cleartext > devices than what we are modifying now (adding, removing), we may have > changes to the neigbour spokes and hubs, but we should not have any > changes to spokes, or hubs further away. > Great inputs will update the definitions in the document based on the inputs here. >From our perspective the difference in terminology (between what you have said and what the draft says) seems to be the spoke. In our definition a Spoke is an edge device in the star topology which can be an end-point or a gateway. Other definitions look good to me. > > > > > This implies that SPD > > > > entries or other configuration based on peer IP address will need > to > > > > be automatically updated, avoided, or handled in some manner to > avoid > > > > a need to manually update policy whenever an address changes. > > > > > > This is much more clear, and I think this most likely means that the > > > first paragraph was trying to say that already existing AD VPN members > > > should be able to connect other AD VPN members even when their > > > IP-addresses are not static. > > > > > > Next question is how does the one member know to which address connect > > > to if also the destination member has changing IP address? And how to > > > punch holes to NATs that might be between them. > > > > > These are the exact questions we need to answer with the protocol > > solution in my view. > > I meant to say is that requirement that it should work in such setup > too, or do we just say that there is no such requirement, and on end > of the connection must have static ip-address. > > Also talking about NATs which classes can be behind NAT? > > I assume we do require that endpoint devices MUST be able to be behind > NAT. Cleartext devices does not matter, as they do not do IPsec > themselves. Do we require that spokes also can be behind NATs? What > about hubs? > Yes the aim is ADVPN end points can be behind NAT's. I agree a hub may not require to be behind NAT, but if two spokes communicate both of them can be behind NAT's. > > I would expect that spokes can be behind NAT, so we should probably > require that, but I am not sure if the hubs themselves will ever be > behind NAT, and it would make things much easier if we say that there > is no requirement to support setups where hubs are behind NATs. This > would solve the problem that when new spoke is added and it is trying > to fetch to configuration, it knows what IP address to use as the > IP-address of the hub can be configured to it... If all the hubs have > dynamic IP-addresses things get really complex... > > > > > 3. Gateways MUST allow tunnel binding, such that applications > like > > > > Routing using the tunnels can work seamlessly without any updates > to > > > > the higher level application configuration i.e. OSPF > configuration. > > > > > > I have no idea what this requirement means. What is "tunnel binding"? > > > Where does this requirement come? Which use case drives this? > > > > > Do let me know if the mail to Yoav makes it any clearer? > > Not really. I still do not understand what you mean by tunnel binding. > The requirement is that in an Enterprise, we may want the branch addresses to be propagated to the Hub, and run routing protocol over the IPsec tunnels, even as they change their end point IP addresses. If this is not clear, would it be possible to expand the question? > > > > > 4. In a hub-and-spoke topology, spoke gateways and endpoints MUST > > > > allow for direct communication with other spoke gateways and > > > > endpoints. > > > > > > Hmm... why are you listing here spokes and endpoints as separate > > > entries. In the terminology I understood spoke also includes > > > endpoints? > > > > > I agree good point. Will update. > > Actually I think it would be easier if we make bigger changes to the > terminology, like we I proposed earlier. I.e. define roles of hub and > spokes better, and not tie them to the star-topology, like we > currently do. And in my version the spokes does not include endpoints, > as endpoints do not have any cleartext devices behind them. > Ok, let me look at the complete document for clarity. > > > > > 5. One spoke MUST NOT be able to impersonate another spoke. > > > > > > If spoke does not imply endpoints, then we should say that this also > > > applies to the endpoints, i.e. One endpoint or spoke MUST NOT be able > > > to impersonate another spokes or endpoints. > > > > > > What about hubs? Are they allowed to impersonate other hubs? I assume > > > yes, but then next question comes are hubs allowed to impersonate as a > > > spoke or endpoint? Is there any requirement that when endpoint makes > > > direct connection to other endpoint it knows that there cannot be any > > > other parties listening on the link? If there is such requirement then > > > also the hubs are not allowed to impersonate endpoints, but on the > > > other hand if we use CA infrastructure, then the CA can always issue > > > certificate allowing this kind of impersonation. > > > > > > > In my view for the ADVPN case Hubs and spokes have permanent > > connections. > > This is not specified anywhere. If such requirement exists, we need to > list it as requirement. I for example do not agree on that. I think > hub-to-hub connections should be permanent, but hub-to-spoke > connections might not be permanent, as one spoke might decide it is > forwarding stuff so much to some other hub, that it might be better to > connect directly to that hub, and only use local hub for more local > traffic. > I am trying to impose the typical enterprise connectivity scenario here - where the hubs and spokes have permanent connections, while the spoke to spoke connections come up and go down. I can add your use case too to the document, but I do not see in cases I know of. > > > > > > > 6. Gateways SHOULD allow for easy handoff of sessions in case > > > > endpoints are roaming, even if they cross policy boundaries. This > > > > means that TCP session breakage and packet loss should be avoided, > > > > when possible. > > > > > > > > This requirement is driven by use case 2.1. Today's endpoints are > > > > mobile and transition often between different networks (from 4G to > > > > WiFi and among various WiFi networks). > > > > > > This cannot come from case 2.1, as that is endpoint to endpoint, so > > > there is no gateway at all there. I would expect this would come from > > > 2.3 i.e. the endpoint to gateway use case. > > > > > > Or does this mean gateways should allow handoff from the > > > endpoint-gateway-endpoint to direct endpoint-endpoint link without > > > breaking TCP sessions? > > > > > The intent was the first paragraph you mention, but I do not see any > > reason we should now allow for a direct connectivity either as you > mention > > in the second paragraph. > > I am lost now. I think this requirement needs to be specified more > clearly, so I can understand what is mean by it. > > The intent of the document was to allow for handoff between gateways for endpoint-gateway-endpoint connectivity. What I was saying was, we can look at the use case you mention of handing off a connection from endpoint-gateway-endpoint to endpoint-to-endpoint. > > > > 8. Gateways and endpoints MUST be able to work when they are > behind > > > > NAT boxes. However, it is especially difficult to handle cases > where > > > > gateways are behind NATs and where two endpoints are both behind > > > > separate NATs. In those cases, workarounds MAY be used such as > port > > > > forwarding by the NAT or detecting when two spokes are behind > > > > uncooperative NATs and using a hub in that case. > > > > > > > > This requirement is driven by use cases 2.1 and 2.2. Endpoints > are > > > > often behind NATs and gateways sometimes are. IPsec should > continue > > > > to work seamlessly regardless, using AD VPN techniques whenever > > > > possible and providing graceful fallback to hub and spoke > techniques > > > > as needed. > > > > > > Does this also include discovery of the addresses? How about if we > > > have two endpoints talking to each other and one of the nat boxes is > > > restarted and one peers IP-address changes, and as the NATs are > > > restricted nats, which means they cannot connect to each other at all > > > after that without the help of the 3rd party. Also the 3rd party > > > cannot connect to either one of them, thus the recover must then start > > > from the endpoints so both of them connect to this 3rd party (hub) to > > > recover from the situation. > > > > > I think the idea here is that spokes being behind NAT's, and the > > solution should allow for a tunnel setup between them. There can be > > external factors however like firewall/ NAT etc which may have cause > issues > > and need to be dealt with seperately. > > The original requirement talked about gateways and endpoints, and > gateways also includes hubs. I think we really need to define those > roles more clearly. > Got the point of clarifying the definitions further and will do so. Thanks, Vishwas > -- > kivinen@iki.fi > --e0cb4efe2f080f7e4c04ca3b0f1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tero,

Thanks for the great comments. Your main comments seem to b= e around clarifying the terminology and you have very thoughtfully expanded= the definitions. I agree with most of it, just one question in the comment= s regarding the same.

We seem to be on the same page here. Please see inline:

On Mon, Sep 17, 2012 at 4:50 AM, Tero Kivinen <kivinen@ik= i.fi> wrote:
Vishwas Manral writes:
> > > 3.2. =A0Star Topology
> > ...
> > > =A0 =A0This solution however does not work when the spokes g= et dynamic IP
> > > =A0 =A0address which the "hub gateways" cannot be = configured with.
> >
> > I think star topology works fine with dynamic IP addresses. You j= ust
> > need to make sure that the spokes are the entities which brings u= p the
> > link, i.e. immediately when they boot up they put up the IPsec li= nk
> > and keep it up all the time. There is other identities in the IPs= ec
> > world than IP-addresses...
> >
> > I would remove the whole sentence.
> >
> I think what we need to talk here is that in c= ase IP address is used
> as an identifier, we need to make sure that it works even as the IP ad= dress
> changes or we can put it that IP address should not be ever used as > identifiers in such cases.

There is quite big difference "cannot be configured with" a= nd "cannot
use IP-addresses as identifiers". And I agree IP addresses should not<= br> be used as identifiers in these cases, but that actually DOES NOT
prevent it working. The ID is just identifier that can be used for
policy lookup, and the RFC5996 says:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 When using the
=A0 =A0ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2<= br> =A0 =A0does not require this address to match the address in the IP header<= br> =A0 =A0of IKEv2 packets, or anything in the TSi/TSr payloads. =A0The conten= ts
=A0 =A0of IDi/IDr are used purely to fetch the policy and authentication =A0 =A0data related to the other party.

So even when the spokes have dynamic IP addresses they can use
whatever ID_IPV4_ADDR/ID_IPV6_ADDR they like to identify themselves to
the other end. For example they could always use their internal
IP-address, i.e. something like 10.22.8.1 when this device is
responsible for the traffic to 10.22.8.0-10.22.12.255, or it could use
IP address of 0.0.0.1 as this is first gateway and second gateway
could use 0.0.0.2 etc... Both of those are completely legal in RFC5996
sense, but neither of them might not be good idea in practice.
Perfect. Though we are not solving the problems yet, I guess those= are great inputs for the solution.
=A0

> > > 4.1. =A0Gateway and Endpoint Requirements
> > ...
> > > =A0 =A02. =A0Gateways and endpoints MUST allow IPsec Tunnels= to be setup
> > > =A0 =A0without any configuration changes, even when peer add= resses get
> > > =A0 =A0updated every time the device comes up.
> >
> > This is unclear for me. Does that mean that anybody can connect t= o the
> > gateway and the gateway MUST allow IPsec Tunnels to be setup with= out
> > any configuration changes (like adding authentication credentials= ?). I
> > do not think so.
> >
> > I think this needs to be clarified. Also endpoints do require
> > configuration changes before they can first time connect to the A= D
> > VPN, for example you need to insert the credentials and most like= ly
> > also point at least one gateway for them to fetch rest of
> > configuration from them.
> >
> > If this is just trying to say that already configured devices in = the
> > AD VPN MUST be able to connect to any other configured device in = the
> > AD VPN at any time, even when the IP addresses are not known
> > beforehand, then I think it should be said differently.
> >
> > Anyways I am not sure what this is trying to say.
>
> VM> In my view if the first time a hub is connected to a spoke we w= ill need
> to do some configuration for sure, however as we add other similar spo= kes
> (could be based on template), we would require no configuration at the= Hub
> end for each spoke added. Let me know if I am clear here, I can update= the
> document with this.

I would expect that adding new spoke to hub only requires initial
configuration in the newly added spoke, and MAY require configuration
changes in the hub where the spoke is connected to, but SHOULD NOT
require configuration changes to the other hubs than the one where the
spoke was connected to, and MUST NOT require configuration changes in
other spokes.

Or something like that for the adding new spoke to the AD VPN. To add
new hub it might require more changes, i.e. adding new hub to the AD
VPN do require initial configuration in the newly added hub, and MAY
also require configuration changes to the other hubs, and MAY also
require configuration changes to the spokes connecting to this new
hub, but SHOULD NOT require any configuration changes to the spokes
connected to the other hubs.

Actually the current definition in the section 1.1 says:


=A0 =A0Hub - The central point in a star topology, generally implemented in=
=A0 =A0a gateway.

meaning, there can be only one hub. And I just wonder how can hub not
be a gateway? I think it must always be a gateway, i.e. it always
protect traffic flowing through the device, otherwise it is not hub
it is server (and outside the scope of the AD VPN).

Perhaps we should expand this and define several different types of
devices:

=A0 =A0Hubs - The central point in a star topology, or one of the central =A0 =A0 =A0 =A0 =A0 points in the mesh style VPN, i.e. gateway where multip= le
=A0 =A0 =A0 =A0 =A0 other hubs or spokes connect to. The hubs usually forwa= rd
=A0 =A0 =A0 =A0 =A0 traffic coming from encrypted links to other encrypted<= br> =A0 =A0 =A0 =A0 =A0 links, i.e. there is no devices connected to it in clea= r.

=A0 =A0Spoke - The edge devices in the a star topology, or gateway which =A0 =A0 =A0 =A0 =A0 =A0forwards traffic from multiple cleartext devices to = other
=A0 =A0 =A0 =A0 =A0 =A0hubs or spokes, and some of those other devices are<= br> =A0 =A0 =A0 =A0 =A0 =A0connected to it in clear (i.e. it encrypt data comin= g from
=A0 =A0 =A0 =A0 =A0 =A0cleartext device and forwards it to the AD VPN).

=A0 =A0Endpoint device - A device that implements IPsec for its own
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0traffic, but does not act as a g= ateway.

=A0 =A0Cleartext device - A device that does rely on the spokes to protect<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 its traffic. Cleartext device m= ight implement
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IPsec, but does not use it in c= urrect setup.

I.e. we should define that there are cleartext devices which talk in
clear to the spokes, which encrypt the traffic and forward it either
to hubs, other spokes, or endpoints, these are devices like those in
the branch office network, which use spokes as their encryption
providers.

Then there is endpoint devices which take care of their own
encryption, and connect directly to the spokes, hubs and other
endpoints, but do not connect directly to the devices behind spokes.
Note that endpoint can move to be cleartext device if it moves to
network that is already protected by spoke. In the same way cleartext
device can move to be endpoint device if it moves out from the network
protected by the spoke.

Those two are the end user devices, i.e. those devices where the user
itself is. The spokes and hubs are just network devices forwarding
traffic.

Those definations might make things a bit more clear, especially when
we are talking about the required configuration changes. I.e. we do
not want to have any changes to any other Endpoint or cleartext
devices than what we are modifying now (adding, removing), we may have
changes to the neigbour spokes and hubs, but we should not have any
changes to spokes, or hubs further away.
Great inputs = will update the definitions in the document based on the inputs here.
From our perspective the difference in terminology=A0 (between what you have=20 said and what the draft says) seems to be the spoke. In our definition a Spoke is an edge device in the star topology which can be an end-point=20 or a gateway. Other definitions look good to me.

> > > =A0 =A0This implies that SPD
> > > =A0 =A0entries or other configuration based on peer IP addre= ss will need to
> > > =A0 =A0be automatically updated, avoided, or handled in some= manner to avoid
> > > =A0 =A0a need to manually update policy whenever an address = changes.
> >
> > This is much more clear, and I think this most likely means that = the
> > first paragraph was trying to say that already existing AD VPN me= mbers
> > should be able to connect other AD VPN members even when their > > IP-addresses are not static.
> >
> > Next question is how does the one member know to which address co= nnect
> > to if also the destination member has changing IP address? And ho= w to
> > punch holes to NATs that might be between them.
> >
> These are the exact questions we need to answe= r with the protocol
> solution in my view.

I meant to say is that requirement that it should work in such setup<= br> too, or do we just say that there is no such requirement, and on end
of the connection must have static ip-address.

Also talking about NATs which classes can be behind NAT?

I assume we do require that endpoint devices MUST be able to be behind
NAT. Cleartext devices does not matter, as they do not do IPsec
themselves. Do we require that spokes also can be behind NATs? What
about hubs?
Yes the aim is ADVPN end points can be beh= ind NAT's. I agree a hub may not require to be behind NAT, but if two s= pokes communicate both of them can be behind NAT's.
=A0

I would expect that spokes can be behind NAT, so we should probably
require that, but I am not sure if the hubs themselves will ever be
behind NAT, and it would make things much easier if we say that there
is no requirement to support setups where hubs are behind NATs. This
would solve the problem that when new spoke is added and it is trying
to fetch to configuration, it knows what IP address to use as the
IP-address of the hub can be configured to it... If all the hubs have
dynamic IP-addresses things get really complex...

> > > =A0 =A03. =A0Gateways MUST allow tunnel binding, such that a= pplications like
> > > =A0 =A0Routing using the tunnels can work seamlessly without= any updates to
> > > =A0 =A0the higher level application configuration i.e. =A0OS= PF configuration.
> >
> > I have no idea what this requirement means. What is "tunnel = binding"?
> > Where does this requirement come? Which use case drives this?
> >
> Do let me know if the mail to Yoav makes it an= y clearer?

Not really. I still do not understand what you mean by tunnel binding= .
The requirement is that in an Enterprise, we may wan= t the branch addresses to be propagated to the Hub, and run routing protoco= l over the IPsec tunnels, even as they change their end point IP addresses.= If this is not clear, would it be possible to expand the question?
=A0

> > > =A0 =A04. =A0In a hub-and-spoke topology, spoke gateways and= endpoints MUST
> > > =A0 =A0allow for direct communication with other spoke gatew= ays and
> > > =A0 =A0endpoints.
> >
> > Hmm... why are you listing here spokes and endpoints as separate<= br> > > entries. In the terminology I understood spoke also includes
> > endpoints?
> >
> I agree good point. Will update.

Actually I think it would be easier if we make bigger changes to the<= br> terminology, like we I proposed earlier. I.e. define roles of hub and
spokes better, and not tie them to the star-topology, like we
currently do. And in my version the spokes does not include endpoints,
as endpoints do not have any cleartext devices behind them.
Ok, let me look at the complete document for clarity.
=A0

> > > =A0 =A05. =A0One spoke MUST NOT be able to impersonate anoth= er spoke.
> >
> > If spoke does not imply endpoints, then we should say that this a= lso
> > applies to the endpoints, i.e. One endpoint or spoke MUST NOT be = able
> > to impersonate another spokes or endpoints.
> >
> > What about hubs? Are they allowed to impersonate other hubs? I as= sume
> > yes, but then next question comes are hubs allowed to impersonate= as a
> > spoke or endpoint? Is there any requirement that when endpoint ma= kes
> > direct connection to other endpoint it knows that there cannot be= any
> > other parties listening on the link? If there is such requirement= then
> > also the hubs are not allowed to impersonate endpoints, but on th= e
> > other hand if we use CA infrastructure, then the CA can always is= sue
> > certificate allowing this kind of impersonation.
> >
>
> In my view for the ADVPN case Hubs and spokes = have permanent
> connections.

This is not specified anywhere. If such requirement exists, we need t= o
list it as requirement. I for example do not agree on that. I think
hub-to-hub connections should be permanent, but hub-to-spoke
connections might not be permanent, as one spoke might decide it is
forwarding stuff so much to some other hub, that it might be better to
connect directly to that hub, and only use local hub for more local
traffic.
I am trying to impose the typical enterprise = connectivity scenario here - where the hubs and spokes have permanent conne= ctions, while the spoke to spoke connections come up and go down. I can add= your use case too to the document, but I do not see in cases I know of. =A0



> > > =A0 =A06. =A0Gateways SHOULD allow for easy handoff of sessi= ons in case
> > > =A0 =A0endpoints are roaming, even if they cross policy boun= daries. =A0This
> > > =A0 =A0means that TCP session breakage and packet loss shoul= d be avoided,
> > > =A0 =A0when possible.
> > >
> > > =A0 =A0This requirement is driven by use case 2.1. =A0Today&= #39;s endpoints are
> > > =A0 =A0mobile and transition often between different network= s (from 4G to
> > > =A0 =A0WiFi and among various WiFi networks).
> >
> > This cannot come from case 2.1, as that is endpoint to endpoint, = so
> > there is no gateway at all there. I would expect this would come = from
> > 2.3 i.e. the endpoint to gateway use case.
> >
> > Or does this mean gateways should allow handoff from the
> > endpoint-gateway-endpoint to direct endpoint-endpoint link withou= t
> > breaking TCP sessions?
> >
> The intent was the first paragraph you mention= , but I do not see any
> reason we should now allow for a direct connectivity either as you men= tion
> in the second paragraph.

I am lost now. I think this requirement needs to be specified more clearly, so I can understand what is mean by it.

The intent of the document wa= s to allow for handoff between gateways for endpoint-gateway-endpoint conne= ctivity. What I was saying was, we can look at the use case you mention of = handing off a connection from endpoint-gateway-endpoint to endpoint-to-endp= oint.
=A0
> > > =A0 =A08. =A0Gateways and endpoints MUST be able to work whe= n they are behind
> > > =A0 =A0NAT boxes. =A0However, it is especially difficult to = handle cases where
> > > =A0 =A0gateways are behind NATs and where two endpoints are = both behind
> > > =A0 =A0separate NATs. =A0In those cases, workarounds MAY be = used such as port
> > > =A0 =A0forwarding by the NAT or detecting when two spokes ar= e behind
> > > =A0 =A0uncooperative NATs and using a hub in that case.
> > >
> > > =A0 =A0This requirement is driven by use cases 2.1 and 2.2. = =A0Endpoints are
> > > =A0 =A0often behind NATs and gateways sometimes are. =A0IPse= c should continue
> > > =A0 =A0to work seamlessly regardless, using AD VPN technique= s whenever
> > > =A0 =A0possible and providing graceful fallback to hub and s= poke techniques
> > > =A0 =A0as needed.
> >
> > Does this also include discovery of the addresses? How about if w= e
> > have two endpoints talking to each other and one of the nat boxes= is
> > restarted and one peers IP-address changes, and as the NATs are > > restricted nats, which means they cannot connect to each other at= all
> > after that without the help of the 3rd party. Also the 3rd party<= br> > > cannot connect to either one of them, thus the recover must then = start
> > from the endpoints so both of them connect to this 3rd party (hub= ) to
> > recover from the situation.
> >
> I think the idea here is that spokes being beh= ind NAT's, and the
> solution should allow for a tunnel setup between them. There can be > external factors however like firewall/ NAT etc which may have cause i= ssues
> and need to be dealt with seperately.

The original requirement talked about gateways and endpoints, and
gateways also includes hubs. I think we really need to define those
roles more clearly.
Got the point of clarifying the de= finitions further and will do so.

Thanks,
Vishwas
--
kivinen@iki.fi

--e0cb4efe2f080f7e4c04ca3b0f1c-- From yaronf.ietf@gmail.com Fri Sep 21 12:39: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 5080B21F8669 for ; Fri, 21 Sep 2012 12:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMADtcBXG-Qy for ; Fri, 21 Sep 2012 12:39:43 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C07D21F8667 for ; Fri, 21 Sep 2012 12:39:43 -0700 (PDT) Received: by bkty12 with SMTP id y12so1888087bkt.31 for ; Fri, 21 Sep 2012 12:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Zm5WMIr+t2oFnbDoZHLNwVsfuT2jEX4yaWhtJAOyEFU=; b=N1Eb9Ww5QX/apsKeJCOQ7wreBbYmufMpTAs8PS3xIJ9mII/2S1w+/jqvm95b+kEsCK VTj+JUPyvHB8YoqGrTBmfgv5V7SJu78CTlcGEH0+fMbfwyDsCnUMEsOQBUL6PqE3TFZU 4RHD1hyl/4NWAka5zmtDtmzi0FsxJkFmgH/J117+S6fJzQZTbazc7BTOAyvqMBzy0Lw4 DQLmds6sg6hEf9K4fGVcFA7C8pNrlDNPqkES4zIQdl1a6YNXpPIEV33EbPMUzKYZswmt epSyiIO/Y7cS/rsT78PVv5pUckfS4q3R/rc+teP7WuET3u1w4Pc+d1op0xQDl0ZmbAnE kRng== Received: by 10.204.157.151 with SMTP id b23mr2717371bkx.96.1348256382089; Fri, 21 Sep 2012 12:39:42 -0700 (PDT) Received: from [10.0.0.3] ([109.65.145.148]) by mx.google.com with ESMTPS id m26sm1504836bkw.11.2012.09.21.12.39.40 (version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 12:39:41 -0700 (PDT) Message-ID: <505CC27C.2060903@gmail.com> Date: Fri, 21 Sep 2012 22:39:40 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Paul Hoffman References: <505C7784.3080803@ieca.com> <2CB1A45B-7F15-4B2A-A3FA-BB2FD1AB1AD4@vpnc.org> In-Reply-To: <2CB1A45B-7F15-4B2A-A3FA-BB2FD1AB1AD4@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Sean Turner Subject: Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft 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, 21 Sep 2012 19:39:44 -0000 Same here. Thanks Sean! Yaron On 21/09/12 21:19, Paul Hoffman wrote: > This all works for me, adding #6) Remove the snark. > > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dharkins@lounge.org Fri Sep 21 14:43:11 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3D621F849B for ; Fri, 21 Sep 2012 14:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56vW7+XlzuVT for ; Fri, 21 Sep 2012 14:43:08 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4D421F8470 for ; Fri, 21 Sep 2012 14:43:08 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8662710224008; Fri, 21 Sep 2012 14:42:58 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 21 Sep 2012 14:42:59 -0700 (PDT) Message-ID: <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> In-Reply-To: <505C7784.3080803@ieca.com> References: <505C7784.3080803@ieca.com> Date: Fri, 21 Sep 2012 14:42:59 -0700 (PDT) From: "Dan Harkins" To: "Sean Turner" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org Subject: Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft 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, 21 Sep 2012 21:43:12 -0000 Hi Sean, There's some missing (pre)history and context. Let me try to fill it in. Back in early July, Johannes Merkle sent a note to the list saying he wanted to use the elliptic curves proposed by the ECC Brainpool with IKE and IPsec. He asked a series of questions, one of which was: "Should we include IKEv1 in the specs as well?" I voiced support but there was some opposition along the lines of: * we cannot update the IANA registry of an obsoleted protocol. * it is not appropriate for a protocol other than RFC 2409 to use the IANA registry created by RFC 2409. Both of these are wrong. RFC 5114 updated this very same registry after RFC 2409 was obsoleted and there was no hullabaloo over that action. And RFC 5931 (EAP-pwd) uses that registry and it got approved for publication long after RFC 2409 was obsoleted, again without any hullabaloo. There is no valid process reason to not just let Johannes's draft update the IKEv1 registry while it's updating the IKEv2 registry (just like RFC 5114 did) and there is precedence which we could just follow to avoid all this mess. In spite of that. it was decided to not update the IKEv1 registry with the Brainpool curves. When IEEE got wind of this, they sent a request, via the IEEE-to-IETF liaison, to please reconsider since they have more than 1 protocol used in 802.11 that reference that registry (i.e. it's not just SAE). The concern was that there may be administrative or regulatory reasons for some entity to desire or require using the Brainpool curves and 802.11 wants to ensure that it can be used everywhere, or at least not prohibited from being used because of a misguided effort by the IETF to kill off use of a different protocol. It is the nature of this reconsideration-- forbid IKEv1 from using the updated registry or create some new registry and forbid IKEv1 from using it-- that is causing this whole kerfuffle. IEEE 802.11's long (from our standpoint) revision schedule is not the cause of the problem here. The reason to not just update the IKEv1 registry with the Brainpool curves and to prohibit it's use with these curves is, apparently, the concern that someone somewhere might actually use them with IKEv1. It is not a certainty that that will happen and, furthermore, it is not apparent to me what calamity will befall us all if somebody did. So my preference would be to follow existing precedence and let Johannes's draft update both registries without any ridiculous notes. If that were to happen we could let my draft die a natural death and end the kerfuffle. If that just cannot be then I'll update my draft to reflect your proposed edits, with the modification that this is not just for SAE and not just for 802.11. Also, if you want to limit the number of curves (item #4) you should coordinate with Johannes on his draft for the IKEv2 registry as well as his TLS draft. regards, Dan. On Fri, September 21, 2012 7:19 am, Sean Turner wrote: > I'd like to discuss the IEEE's request for brainpool code points > additions in the Group Description registry > (https://www.iana.org/assignments/ipsec-registry) on this mailing list. > I realize it's not in scope of the WG, but all the right people are > here so I'd like to ask for the wg chair's and member's indulgence on > this matter. > > Here's the summary of events as I remember them: > > Stephen and I got an informal liaison from IEEE 802.11 requesting code > point assignments in the Group Description section of > https://www.iana.org/assignments/ipsec-registry. Since then we've > received the official liaison. And we figured inviting Dorthy along to > secir would cut down on some email. > > My initial thought was that adding anything to this registry was an > update to IKEv1 and that was pretty much a no-go because IKEv1 is > obsolete. But, the registry is RFC required so that's not strictly > true. That is, other code points have been assigned after IKEv1 was > obsoleted. > > The other thing that came to light was that the code points were in fact > not going to be used by IKEv1 they were being used by another protocol, > the IEEE 802.11 SAE (Simultaneous Authentication of Equals) protocol. > > I think it's fair to say that at the meeting most people weren't > thrilled that IEEE plans to reuse the registry. We discussed setting up > a new registry or pointing from the existing registry to a new registry, > but the IEEE folks didn't like that because their spec is apparently not > up for change until 2015 (Tero has submitted comments on this topic in > IEEE). > > What I thought we came to was that Dan would publish a draft that > requested the points and that the "notes" column would contain "not for > IKEv1" - and then we'd talk about it. Dan submitted the draft > requesting 14 code points with "not for IKEv1" in the notes column for > each code point. I forwarded it to secdir and here we are. > > ^ > | summary > > | way ahead discussion > v > > From the discussion following publication, it's still clear the dual > use of the registry is still unloved. I share that view. I think it > comes down to this: > > - On the one hand, putting "not for IKEv1" in the notes column assumes > that whoever consults the registry will make note of the note and not > implement (or ask for them to be implemented) the code points in IKEv1. > Concerns have been expressed that the note won't be enough to stop > people asking for IKEv1 products to support these new code points - not > thrilled about this prospect. > > - On the other hand, getting the IEEE spec to point to a new registry is > (or might be) a no-go because of their publishing cycle. Assuming the > IEEE spec can't be changed and we don't assign the code points, I'm sure > some kind of inter-SDO struggle/spat will occur - not thrilled about > this this prospect either. > > In this unfortunate situation, I'd like everyone to consider the (third > surgically attached) hand that shares the burden: reserve the code > points for 802.11 SAE in the Group Description registry, be very > explicit about it in the draft/regstry, and then point from the Group > Description registry to another registry (thanks to whoever suggested > this at the secdir lunch we probably should have explored this more). > The burden is then shared by the IETF assigning code points for > something some despise/dislike and the IEEE implementers following an > additional link from the registry they've already got to consult (they > have to follow the link because the registry values aren't copied to > their spec). The registry entries would appear as follows (well Value, > Group, Reference, and Notes would normally appear on one line but it > wraps in email and I thought this would be easier to follow): > > Value > ----- > 27-y > > Group > ----------------------- > Reserved for 802.11 SAE > > Description > ------------------ > This specification > > Notes > ----------------------------------------- > Not for use with IKEv1 - see xyz registry > > and then link 27-y to the curve names in the xyz registry (more on the > number of code points at the end): > > Value Group Reference > ----- ------------------------------ ------------------ > 27 X-bit Brainpool: brainpoolPXr1 This specification > ... ... .... > > > Thoughts about this? > > > | comments on draft > v > > I'd like to make to the draft clearer about what's going on: > > #1) Retitle: > > OLD: > > Brainpool Elliptic Curves for the IKE Group Description Registry > > NEW: > > Brainpool Elliptic Curves for 802.11 SAE in the > IKE Group Description Registry > > #2) tweak abstract: > > OLD: > > This memo allocates code points for fourteen new > elliptic curve domain parameter sets over finite > prime fields into a registry established by The > Internet Key Exchange (IKE). > > NEW (where X is TBD at this point): > > This memo allocates code points for X new elliptic > curve domain parameter sets over finite prime fields > into a registry established by The Internet Key > Exchange (IKE). These values are used by the IEEE > 802.11 SAE (Simultaneous Authentication > of Equals) protocol. The values found in this > document are not for use in IKEv1. > > #3) tweak intro: > > OLD: > > IANA maintains a registry for [RFC2409] to map > complete domain parameter sets to numbers. Other > protocols, for example [IEEE802.11], refer to this > registry for its convenience. Therefore, this memo > instructs IANA to allocate new code points for the > Brainpool curves defined in [RFC5639] to the registry > established by [RFC2409]. > > NEW: > > [RFC2409] defined the Group Description registry that > other protocols, for example [IEEE802.11], refer to for > convenience. Non-IKE protocols referring to the registry > is not ideal but also not a problem until the non-IKE > protocol(s) want values added to the registry and these > values are not for use by IKE. This is the case with the > values in this document; they are not for use with IKEv1. > The values in this document are for the Brainpool curves > defined in [RFC5639] use with 802.11 SAE and the > documents only purpose is to instruct IANA to allocate > new code points. > > #4) Pick fewer curves. Not sure which ones but if we end up doing > brainpool in TLS I'd like to see us pick the same ones. Not sure which > ones those will be. I'm thinking like 3 - probably lining up with the 3 > ECP groups. > > #5) Once we've settled on the format for the registry put it exactly as > agreed in the IANA section. > > spt > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kivinen@iki.fi Tue Sep 25 04:03:08 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1C921F8893 for ; Tue, 25 Sep 2012 04:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdyDm2URHCrf for ; Tue, 25 Sep 2012 04:03:07 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3862721F886A for ; Tue, 25 Sep 2012 04:03:04 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q8PB2uTd012250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 14:02:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q8PB2raQ018123; Tue, 25 Sep 2012 14:02:53 +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=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <20577.36701.382728.671118@fireball.kivinen.iki.fi> Date: Tue, 25 Sep 2012 14:02:53 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 98 min X-Total-Time: 77 min Cc: ipsec@ietf.org, Sean Turner Subject: Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft 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, 25 Sep 2012 11:03:08 -0000 Dan Harkins writes: > I voiced support but there was some opposition along the lines of: >=20 > * we cannot update the IANA registry of an obsoleted protocol. > * it is not appropriate for a protocol other than RFC 2409 to use > the IANA registry created by RFC 2409. >=20 > Both of these are wrong. RFC 5114 updated this very same registry > after RFC 2409 was obsoleted and there was no hullabaloo over > that action. When draft-lepinski-dh-groups was discussed in the ipsec-list we were most concerned about the format of the KE payloads and so on, and I do not think anybody actually even reacted to the fact that it updates IKEv1 registry too. At that point it was also 2 years since the IKEv1 was obsoleted, now it is 7 years, so I do think there is a difference. > And RFC 5931 (EAP-pwd) uses that registry and it > got approved for publication long after RFC 2409 was obsoleted, > again without any hullabaloo. Never knew that RFC 5931 is using that same registry. This was not pointed out in the IPsec list, thus I think most peoples just didn't realize the issue. The fact that it uses the registry of the obsoleted IKEv1 protocol, is said like this in the RFC: The Group Description field value is taken from the IANA registry fo= r "Group Description" created by IKE [RFC2409]. There is no link to the registry itself, no IANA considerations section comment, only saying the group description field is taken from that registry. I think one of the problems we have in IANA registries is that, we do not have back pointers. I.e. it is impossible to know which protocols use which registries. If the protocol just uses (instead of making additions to it) the IANA registry, there is no need for IANA actions, thus IANA (or the expert or WG etc) is not even aware of the fact that some protocol is using some registry. Perhaps we should start adding some kind of back pointers to the IANA registries, i.e. which protocols use which registry.=20 > There is no valid process reason to not just let Johannes's draft > update the IKEv1 registry while it's updating the IKEv2 registry > (just like RFC 5114 did) and there is precedence which we could > just follow to avoid all this mess. It is time to stop updating obsoleted IKEv1 protocol. Even when there has been case where it was approved 5 years ago, that does not mean we are going to do it forever. > In spite of that. it was decided to not update the IKEv1 registry > with the Brainpool curves. When IEEE got wind of this, they sent > a request, via the IEEE-to-IETF liaison, to please reconsider since > they have more than 1 protocol used in 802.11 that reference > that registry (i.e. it's not just SAE). I could not find any other protocol than SAE, can you give me references to which other IEEE protocols use that registry directly (i.e. not through some RFC). > The concern was that there may be administrative or regulatory > reasons for some entity to desire or require using the Brainpool > curves and 802.11 wants to ensure that it can be used everywhere, or > at least not prohibited from being used because of a misguided > effort by the IETF to kill off use of a different protocol. Which is exacty the reason why protocols should not reuse registries from other protocols. If IETF wants to kill of some protocol, it should be able to do so. And if IETF wants to say that there is no more additions to that protocol, that should be possible, even when some other STD (or RFC) uses that protocol. > It is the nature of this reconsideration-- forbid IKEv1 from using > the updated registry or create some new registry and forbid IKEv1 > from using it-- that is causing this whole kerfuffle. IEEE 802.11's > long (from our standpoint) revision schedule is not the cause of > the problem here. I do not think IEEE revision schedule is that long. Our drafts to RFCs cycles are around 2-4 years in normal case (and close to 10 years for slow documents) I do not think IEEEs revision cycle is that long. I think there is also errata for IEEE documents, but I do not know how that works. There is also some kind of faster and more lightway way of making some fixes/additions to documents, at least that was told to me in the 802.15.9 session when we were talking about that we need some changes to some other documents. For example I think updating the pointer from IKEv1 registry to its own registry for this IEEE document is something that could be done on errata. Checking at the errata documents for other IEEE documents (http://standards.ieee.org/findstds/errata/index.html) they do seem to change things like "32 s" -> "32 =B5s", which is quite big technical change (http://standards.ieee.org/findstds/errata/802.11h-2003.pdf), compared to this pointer change. Especially if the IKEv1 registry is made so that it points to the new registry, so regardless whether IEEE users notice the errata or not, they finally get to the right place. > So my preference would be to follow existing precedence and let > Johannes's draft update both registries without any ridiculous notes.= > If that were to happen we could let my draft die a natural death and > end the kerfuffle. If that just cannot be then I'll update my draft t= o > reflect your proposed edits, with the modification that this is not j= ust > for SAE and not just for 802.11. You should actually enumerate for which protocols it is then. If there is even more than 802.11 SAE and RFC 5931, then it will affect the discussion here. For example the RFC5931 can be Updated by your new draft and RFC 5931 should now use the newly created registry for groups, and we can add another note to the old IKEv1 registry pointing RFC 5931 users to this new registry.=20 > Also, if you want to limit the number of curves (item #4) you should > coordinate with Johannes on his draft for the IKEv2 registry as well > as his TLS draft. Yes. --=20 kivinen@iki.fi From kivinen@iki.fi Tue Sep 25 05:56: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 AC09121F882F for ; Tue, 25 Sep 2012 05:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBrzDVORe3Df for ; Tue, 25 Sep 2012 05:56:03 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id A9F8621F87A0 for ; Tue, 25 Sep 2012 05:56:02 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q8PCttgY017654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 15:55:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q8PCtsZv000295; Tue, 25 Sep 2012 15:55:54 +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: <20577.43482.630385.491671@fireball.kivinen.iki.fi> Date: Tue, 25 Sep 2012 15:55:54 +0300 From: Tero Kivinen To: Sean Turner In-Reply-To: <505C7784.3080803@ieca.com> References: <505C7784.3080803@ieca.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 40 min X-Total-Time: 16 min Cc: ipsec@ietf.org Subject: [IPsec] brainpool summary, suggested way ahead, and comments on draft 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, 25 Sep 2012 12:56:03 -0000 Sean Turner writes: > From the discussion following publication, it's still clear the dual > use of the registry is still unloved. I share that view. I think it Actually as Dan pointed out it is not only dual use, as there is other protocols using the registry. I think this makes it even more clear that we want them to refer to another registry, not reuse the IKEv1 registry. > comes down to this: > > - On the one hand, putting "not for IKEv1" in the notes column assumes > that whoever consults the registry will make note of the note and not > implement (or ask for them to be implemented) the code points in IKEv1. > Concerns have been expressed that the note won't be enough to stop > people asking for IKEv1 products to support these new code points - not > thrilled about this prospect. And next questions comes to implementors reading the registry: "This is IKEv1 registry, and these entries are 'not for IKEv1', so for what reason they are added here?" Which means we still need to add pointer to other protocols / specifications using the registry. > - On the other hand, getting the IEEE spec to point to a new registry is > (or might be) a no-go because of their publishing cycle. Assuming the > IEEE spec can't be changed and we don't assign the code points, I'm sure > some kind of inter-SDO struggle/spat will occur - not thrilled about > this this prospect either. Actually we should propably make formal request to ask from IEEE what other options there are, i.e. I know they have errata, they also make amendments which are then rolled in to the their actual standards, and most implementors actually already implement those amendments as soon as they are ready. I also think they have some kind of maintenance process which is allowed to make changes (additions etc) to the standards without going through the full amendment process for simple things (for example allocating just one number). I think all this also depends on the working group (i.e. 802.11 here), so it would need to get some 802.11 WG officials to answer whats their processing rules for all those. Unfortunately I was not able to be in the last IEEE interm meeting, and I am going to miss next plenary too, so I cannot ask those questions from the people who know more in person. > In this unfortunate situation, I'd like everyone to consider the (third > surgically attached) hand that shares the burden: reserve the code > points for 802.11 SAE in the Group Description registry, be very > explicit about it in the draft/regstry, and then point from the Group > Description registry to another registry (thanks to whoever suggested > this at the secdir lunch we probably should have explored this more). > The burden is then shared by the IETF assigning code points for > something some despise/dislike and the IEEE implementers following an > additional link from the registry they've already got to consult (they > have to follow the link because the registry values aren't copied to > their spec). The registry entries would appear as follows (well Value, > Group, Reference, and Notes would normally appear on one line but it > wraps in email and I thought this would be easier to follow): I think that would be good way forward. Also it might be possible to make errata for their specification to point to the right registry directly. There is also the RFC 5931 which reuses same registry. Is there other RFCs? > #4) Pick fewer curves. Not sure which ones but if we end up doing > brainpool in TLS I'd like to see us pick the same ones. Not sure which > ones those will be. I'm thinking like 3 - probably lining up with the 3 > ECP groups. Actually if the new registry is going to be Generic Group Description registry, I see no reason to limit the number of groups that it can include. It will most likely be 16-bit registry or similar, thus there is enough space for everything. On the IKEv2 and TLS we can limit the number of groups if we like, but I see no reason why this generic "group description" <-> "group number" registry should be limited to only certain groups. Actually it could be something like "first come first served"-allocation policy and anybody could allocate any group from there just to get number it can use in other protocols. If this is going to be registry only for IEEE 802.11 SAE, then we most likely need to ask from them what do they want to have for allocation policy. -- kivinen@iki.fi From kivinen@iki.fi Tue Sep 25 06:14: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 B98D421F86A1 for ; Tue, 25 Sep 2012 06:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCp6LKDDTm8e for ; Tue, 25 Sep 2012 06:14:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 043E121F88D2 for ; Tue, 25 Sep 2012 06:14:36 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q8PDEWsp016995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Sep 2012 16:14:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q8PDEWFr021694; Tue, 25 Sep 2012 16:14:32 +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: <20577.44600.597261.533593@fireball.kivinen.iki.fi> Date: Tue, 25 Sep 2012 16:14:32 +0300 From: Tero Kivinen To: Vishwas Manral In-Reply-To: References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20557.56357.878183.593537@fireball.kivinen.iki.fi> <20567.3710.740450.2640@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 45 min X-Total-Time: 17 min Cc: IPsecme WG Subject: Re: [IPsec] STRONG NUDGE: Revised AD VPN Requirements 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, 25 Sep 2012 13:14:38 -0000 Vishwas Manral writes: > > Vishwas Manral writes: > > > > > 3.2. Star Topology > > > > ... > > > > > This solution however does not work when the spokes get dynamic IP > > > > > address which the "hub gateways" cannot be configured with. > > > > > > > > I think star topology works fine with dynamic IP addresses. You just > > > > need to make sure that the spokes are the entities which brings up the > > > > link, i.e. immediately when they boot up they put up the IPsec link > > > > and keep it up all the time. There is other identities in the IPsec > > > > world than IP-addresses... > > > > > > > > I would remove the whole sentence. > > > > > > > I think what we need to talk here is that in case IP address is used > > > as an identifier, we need to make sure that it works even as the IP > > address > > > changes or we can put it that IP address should not be ever used as > > > identifiers in such cases. > > > > There is quite big difference "cannot be configured with" and "cannot > > use IP-addresses as identifiers". And I agree IP addresses should not > > be used as identifiers in these cases, but that actually DOES NOT > > prevent it working. The ID is just identifier that can be used for > > policy lookup, and the RFC5996 says: > > > > When using the > > ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 > > does not require this address to match the address in the IP header > > of IKEv2 packets, or anything in the TSi/TSr payloads. The contents > > of IDi/IDr are used purely to fetch the policy and authentication > > data related to the other party. > > > > So even when the spokes have dynamic IP addresses they can use > > whatever ID_IPV4_ADDR/ID_IPV6_ADDR they like to identify themselves to > > the other end. For example they could always use their internal > > IP-address, i.e. something like 10.22.8.1 when this device is > > responsible for the traffic to 10.22.8.0-10.22.12.255, or it could use > > IP address of 0.0.0.1 as this is first gateway and second gateway > > could use 0.0.0.2 etc... Both of those are completely legal in RFC5996 > > sense, but neither of them might not be good idea in practice. > > > Perfect. Though we are not solving the problems yet, I guess those are > great inputs for the solution. The text in the document claiming that Star topology does not work when the spokes get dynamic IP address is still wrong. As I explained in my examples there is nothing in the current protocol specifications which makes them "not work" or "cannot be configured with". > > Spoke - The edge devices in the a star topology, or gateway which > > forwards traffic from multiple cleartext devices to other > > hubs or spokes, and some of those other devices are > > connected to it in clear (i.e. it encrypt data coming from > > cleartext device and forwards it to the AD VPN). > > Great inputs will update the definitions in the document based on the > inputs here. > > From our perspective the difference in terminology (between what you have > said and what the draft says) seems to be the spoke. In our definition a > Spoke is an edge device in the star topology which can be an end-point or a > gateway. Other definitions look good to me. As we are trying to get rid of the rigid star topology (it was listed in the "Inadequacy of Existing Solutions"), I think we need more relaxed definition for the spoke. If our star topology is no longer strict rigid star, but more like dynamic mesh kind of thing, then talking about what spokes needs to do and what they do not need to do, gets very confusing. > > I meant to say is that requirement that it should work in such setup > > too, or do we just say that there is no such requirement, and on end > > of the connection must have static ip-address. > > > > Also talking about NATs which classes can be behind NAT? > > > > I assume we do require that endpoint devices MUST be able to be behind > > NAT. Cleartext devices does not matter, as they do not do IPsec > > themselves. Do we require that spokes also can be behind NATs? What > > about hubs? > > > Yes the aim is ADVPN end points can be behind NAT's. I agree a hub may not > require to be behind NAT, but if two spokes communicate both of them can be > behind NAT's. Then we might want to add specific requirements for each class of devices. > > > > > 3. Gateways MUST allow tunnel binding, such that applications > > like > > > > > Routing using the tunnels can work seamlessly without any updates > > to > > > > > the higher level application configuration i.e. OSPF > > configuration. > > > > > > > > I have no idea what this requirement means. What is "tunnel binding"? > > > > Where does this requirement come? Which use case drives this? > > > > > > > Do let me know if the mail to Yoav makes it any clearer? > > > > Not really. I still do not understand what you mean by tunnel binding. > > > The requirement is that in an Enterprise, we may want the branch addresses > to be propagated to the Hub, and run routing protocol over the IPsec > tunnels, even as they change their end point IP addresses. If this is not > clear, would it be possible to expand the question? As you said it yourself and appended with the rest of the old text: Gateways MUST be able to run routing protocol over the IPsec tunnels, even as they change their end point IP addresses. This means that applications like Routing using the tunnels can work seamlessly without any updates to the higher level configuration i.e. OSPF configuraiton. I did understand that end part of it, but I did not know whether there was something hidden meaning with the "tunnel binding" part that I did not get. I mean if there is some other requirements coming from the "tunnel binding" part then we should explictly say it out here, not trust that someone who reads the "tunnel binding" knows what those requirements are. > > > > > 5. One spoke MUST NOT be able to impersonate another spoke. > > > > > > > > If spoke does not imply endpoints, then we should say that this also > > > > applies to the endpoints, i.e. One endpoint or spoke MUST NOT be able > > > > to impersonate another spokes or endpoints. > > > > > > > > What about hubs? Are they allowed to impersonate other hubs? I assume > > > > yes, but then next question comes are hubs allowed to impersonate as a > > > > spoke or endpoint? Is there any requirement that when endpoint makes > > > > direct connection to other endpoint it knows that there cannot be any > > > > other parties listening on the link? If there is such requirement then > > > > also the hubs are not allowed to impersonate endpoints, but on the > > > > other hand if we use CA infrastructure, then the CA can always issue > > > > certificate allowing this kind of impersonation. > > > > > > > > > > In my view for the ADVPN case Hubs and spokes have permanent > > > connections. > > > > This is not specified anywhere. If such requirement exists, we need to > > list it as requirement. I for example do not agree on that. I think > > hub-to-hub connections should be permanent, but hub-to-spoke > > connections might not be permanent, as one spoke might decide it is > > forwarding stuff so much to some other hub, that it might be better to > > connect directly to that hub, and only use local hub for more local > > traffic. > > > I am trying to impose the typical enterprise connectivity scenario here - > where the hubs and spokes have permanent connections, while the spoke to > spoke connections come up and go down. I can add your use case too to the > document, but I do not see in cases I know of. That is fine if we think that spoke-to-hub connections are permanent and do not change. I think there would be uses for where spoke realizes that it would be better served by an another hub than the one which is primarly connected to, and it could connect to another hub in addition than connecting directly to the all the spokes behind that hub. If you feel there is no use case, then we can leave it out. > > > > > 6. Gateways SHOULD allow for easy handoff of sessions in case > > > > > endpoints are roaming, even if they cross policy boundaries. This > > > > > means that TCP session breakage and packet loss should be avoided, > > > > > when possible. > > > > > > > > > > This requirement is driven by use case 2.1. Today's endpoints are > > > > > mobile and transition often between different networks (from 4G to > > > > > WiFi and among various WiFi networks). > > > > > > > > This cannot come from case 2.1, as that is endpoint to endpoint, so > > > > there is no gateway at all there. I would expect this would come from > > > > 2.3 i.e. the endpoint to gateway use case. > > > > > > > > Or does this mean gateways should allow handoff from the > > > > endpoint-gateway-endpoint to direct endpoint-endpoint link without > > > > breaking TCP sessions? > > > > > > > The intent was the first paragraph you mention, but I do not see any > > > reason we should now allow for a direct connectivity either as you > > > mention > > > in the second paragraph. > > > > I am lost now. I think this requirement needs to be specified more > > clearly, so I can understand what is mean by it. > > > The intent of the document was to allow for handoff between gateways for > endpoint-gateway-endpoint connectivity. So you mean that when we have endpoint-gateway-endpoint connection, and for some reason the gateway wants to hand that connection to so that connection will be endpoint-another gateway-endpoint? > What I was saying was, we can look > at the use case you mention of handing off a connection from > endpoint-gateway-endpoint to endpoint-to-endpoint. -- kivinen@iki.fi From dharkins@lounge.org Tue Sep 25 10:59:48 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CBB21F8813 for ; Tue, 25 Sep 2012 10:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqrXQviUPPap for ; Tue, 25 Sep 2012 10:59:48 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 263FE21F85FC for ; Tue, 25 Sep 2012 10:59:48 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B4EBF10224008; Tue, 25 Sep 2012 10:59:47 -0700 (PDT) Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 25 Sep 2012 10:59:47 -0700 (PDT) Message-ID: In-Reply-To: <20577.36701.382728.671118@fireball.kivinen.iki.fi> References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <20577.36701.382728.671118@fireball.kivinen.iki.fi> Date: Tue, 25 Sep 2012 10:59:47 -0700 (PDT) From: "Dan Harkins" To: "Tero Kivinen" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: ipsec@ietf.org, Sean Turner Subject: Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft 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, 25 Sep 2012 17:59:48 -0000 On Tue, September 25, 2012 4:02 am, Tero Kivinen wrote: > Dan Harkins writes: >> I voiced support but there was some opposition along the lines of: >> >> * we cannot update the IANA registry of an obsoleted protocol. >> * it is not appropriate for a protocol other than RFC 2409 to use >> the IANA registry created by RFC 2409. >> >> Both of these are wrong. RFC 5114 updated this very same registry >> after RFC 2409 was obsoleted and there was no hullabaloo over >> that action. > > When draft-lepinski-dh-groups was discussed in the ipsec-list we were > most concerned about the format of the KE payloads and so on, and I do > not think anybody actually even reacted to the fact that it updates > IKEv1 registry too. At that point it was also 2 years since the IKEv1 > was obsoleted, now it is 7 years, so I do think there is a difference. There is no time limit that I'm aware of that suddenly makes an acceptable process suddenly become unacceptable. >> And RFC 5931 (EAP-pwd) uses that registry and it >> got approved for publication long after RFC 2409 was obsoleted, >> again without any hullabaloo. > > Never knew that RFC 5931 is using that same registry. This was not > pointed out in the IPsec list, thus I think most peoples just didn't > realize the issue. I brought it up at the SAAG meeting back in Vancouver. You were there. >> There is no valid process reason to not just let Johannes's draft >> update the IKEv1 registry while it's updating the IKEv2 registry >> (just like RFC 5114 did) and there is precedence which we could >> just follow to avoid all this mess. > > It is time to stop updating obsoleted IKEv1 protocol. Even when there > has been case where it was approved 5 years ago, that does not mean we > are going to do it forever. I will admit that you are repeatedly making that assertion but it's just some sort of argumentum ad infinitum/absurdum statement. There is no reasoning behind your assertion. Just "we must stop!" and "we cannot continue forever!" You essentially admit that there is no process reason to not just update the registry and there's really no prohibition on other protocols referring to the registry that was created by another protocol. You may not like it, but that is not a legitimate reason. You snipped out the portion of my email where I noted that I did not foresee any calamity that would befall us all if the IKEv1 registry is merely updated in the same way it was by RFC 5114-- just add the code points without any back pointers or front pointers or ridiculous notes. So let me ask you directly: What calamity will befall us all if the IKEv1 registry is just updated in exactly the same way that RFC 5114 updated the registry? >> In spite of that. it was decided to not update the IKEv1 registry >> with the Brainpool curves. When IEEE got wind of this, they sent >> a request, via the IEEE-to-IETF liaison, to please reconsider since >> they have more than 1 protocol used in 802.11 that reference >> that registry (i.e. it's not just SAE). > > I could not find any other protocol than SAE, can you give me > references to which other IEEE protocols use that registry directly > (i.e. not through some RFC). There is a novel use of an unauthenticated Diffie-Hellman by the audio/visual streaming protocol (added by TGaa). Dan. From kivinen@iki.fi Thu Sep 27 06:47: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 56E2421F8518 for ; Thu, 27 Sep 2012 06:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ONijnrpBzQ7 for ; Thu, 27 Sep 2012 06:47:00 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id C4D7421F850C for ; Thu, 27 Sep 2012 06:46:58 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id q8RDkkE6011664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Sep 2012 16:46:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q8RDkiUv010905; Thu, 27 Sep 2012 16:46:44 +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: <20580.22724.785502.954877@fireball.kivinen.iki.fi> Date: Thu, 27 Sep 2012 16:46:44 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <20577.36701.382728.671118@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 86 min X-Total-Time: 163 min Cc: ipsec@ietf.org, Sean Turner Subject: Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft 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, 27 Sep 2012 13:47:01 -0000 Dan Harkins writes: > > When draft-lepinski-dh-groups was discussed in the ipsec-list we were > > most concerned about the format of the KE payloads and so on, and I do > > not think anybody actually even reacted to the fact that it updates > > IKEv1 registry too. At that point it was also 2 years since the IKEv1 > > was obsoleted, now it is 7 years, so I do think there is a difference. > > There is no time limit that I'm aware of that suddenly makes an > acceptable process suddenly become unacceptable. There is no time limit that suddenly causes that, but the longer the protocol has been obsoleted, the more questionable there is to make additions to it. I do think there is difference whether the addition is proposed 1 day after the new version is out or whether it is done 20 years later. What the exact number of years will be is of course personal opionion, and at least for me it should be less than 7 years, meaning we are already past it... It seems you disagree on me on that, so it is better just agree that we disagree on this issue. > >> And RFC 5931 (EAP-pwd) uses that registry and it > >> got approved for publication long after RFC 2409 was obsoleted, > >> again without any hullabaloo. > > > > Never knew that RFC 5931 is using that same registry. This was not > > pointed out in the IPsec list, thus I think most peoples just didn't > > realize the issue. > > I brought it up at the SAAG meeting back in Vancouver. You were > there. Saag meeting? I assume you mean secdir lunch. I did miss some of the discussion in the secdir lunch as sometimes it is hard to hear people there (no microphones, people talking over each other), and especially RFC numbers do tend to go past me, as I people do say them very quickly, and I need to parse them before I can know which number it is and even after that I usually do not have any idea what protocol that is. Meaning: I did miss that statement there even when I was there. That happens. This means it is good that you pointed it up here too. > I will admit that you are repeatedly making that assertion but it's just > some sort of argumentum ad infinitum/absurdum statement. There is > no reasoning behind your assertion. Just "we must stop!" and "we > cannot continue forever!" We did obsolete the IKEv1 protocol. So I assume that was supposed to mean something. If we continue to make additions to it, why did we obsolete it? I think there is good thing to have some kind of grace period after the protocol is obsoleted, and replaced with new, during which there is still some work that can be done (or most likely finished) for the old protocol, before we move all work to new protocol. You seem to feel that the fact that the protocol is obsoleted does not mean anything, and that we should continue work for that forever. You ar just making that sort of arguments over and over again, without providing any reasoning behind that. If you want reasons I can give you some: IKEv1 is BAD protocol. IKEv2 is much better protocol. IKEv2 include standardized ways of doing lots of things that are done in undocumented (incompatible) vendor specific extensions in the IKEv1. IKEv1 do have known security vulnerabilities especially for those vendor specific extensions, as vendor ID payloads and notifications are not authenticated at all during the initial main mode / aggressive mode exchange. IKEv1 vendor specific configuration payload and xauth exchanges do have known security vulnerailities by using group shared keys (there are some vendor specific extensions which do not have those problems (hybrid-mode)). Then there is lots of smaller things in the implementations, for example retransmission logic, dead peer detection, crash recovery etc. I do think there was good reasons why IKEv1 was obsoleted. I do know that some of those could have been fixed quite easily by making additions to IKEv1, but that was not allowed because of the IETF policy reasons, thus we had fix it by making the IKEv2 and fix all known issues there. > You essentially admit that there is no process reason to not just > update the registry and there's really no prohibition on other protocols > referring to the registry that was created by another protocol. You > may not like it, but that is not a legitimate reason. As far as I know there is no reason for random protocol Y using registry from protocol X. That does not mean that protocol Y has any saying whether anything is added to the registry X. Depending on the IANA allocation policies different parties decide whether that is allowed or not. In this case it is up to the IESG to decide as the registry is RFC required. At least this is my understanding of the issue, but I am not IETF policy person, so I might be wrong... Security area director asked us on this mailing list to comment about the issue, so thats why I am commenting. I personally do think it would be much better to create separate registry for these other generic group description to identifier mappings for these other protocols, and leave them out from IPsec registry. That would fix the problem, that we do not need to modify IKEv1 registry, and those other protocols can add their numbers to the registries at will. What do you have against that solution? > You snipped out the portion of my email where I noted that I did > not foresee any calamity that would befall us all if the IKEv1 registry > is merely updated in the same way it was by RFC 5114-- just add the > code points without any back pointers or front pointers or ridiculous > notes. So let me ask you directly: > > What calamity will befall us all if the IKEv1 registry is just updated > in exactly the same way that RFC 5114 updated the registry? I see some of our customers asking when are we going to implement them for IKEv1. We do IPsec toolkit. Some of our customers go through RFCs and IANA registries and make tick marks for every single option there is, and want to have support for it, regardless whether it makes sense or not. In first I would most likely be able to say that those numbers are not meant to be used for IKEv1, but if there is no note or so in the registry, they would ask why not? Later if some of the other vendors after similar perssurce happens to implement them, then our customers would be more and more asking why we do not implement them. As it just going to be tick mark in their sheets they do not care that we already implement them in IKEv2 and that would mean we would have again added new feature to already obsoleted protocol, which should have died several years ago. > > I could not find any other protocol than SAE, can you give me > > references to which other IEEE protocols use that registry directly > > (i.e. not through some RFC). > > There is a novel use of an unauthenticated Diffie-Hellman by > the audio/visual streaming protocol (added by TGaa). Good to know, need to check that one too. -- kivinen@iki.fi