From turners@ieca.com Thu Oct 11 18:23:21 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43A41F0C5F for ; Thu, 11 Oct 2012 18:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.97 X-Spam-Level: X-Spam-Status: No, score=-100.97 tagged_above=-999 required=5 tests=[AWL=-1.119, 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 tJxCioOQd1jP for ; Thu, 11 Oct 2012 18:23:21 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.66.25]) by ietfa.amsl.com (Postfix) with ESMTP id 24D151F0417 for ; Thu, 11 Oct 2012 18:23:21 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 721BC484704B3; Thu, 11 Oct 2012 20:23:19 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 6762C48470490 for ; Thu, 11 Oct 2012 20:23:19 -0500 (CDT) Received: from [198.180.150.230] (port=56076 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TMTyB-0004DD-1A; Thu, 11 Oct 2012 20:23:19 -0500 Message-ID: <50775B98.2000406@ieca.com> Date: Thu, 11 Oct 2012 18:51:52 -0500 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: Michael Richardson References: <505C7784.3080803@ieca.com> <23189.1348249141@obiwan.sandelman.ca> In-Reply-To: <23189.1348249141@obiwan.sandelman.ca> 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) [198.180.150.230]:56076 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 21 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= 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, 12 Oct 2012 01:23:21 -0000 On 9/21/12 12:39 PM, Michael Richardson wrote: > >>>>>> "Sean" == Sean Turner writes: > Sean> that requested the points and that the "notes" column would > Sean> contain "not for IKEv1" - and then we'd talk about it. Dan > > ... > > Sean> In this unfortunate situation, I'd like everyone to consider > Sean> the (third surgically attached) hand that shares the burden: > Sean> reserve the code points for 802.11 SAE in the Group > Sean> Description registry, be very explicit about it in the > > As I was reading up just before this, my thought was to write, rather > than "not for IKEv1", instead write: > "only for 802.11 SAE" > > but it would actually say what they were. > > Sean> more). The burden is then shared by the IETF assigning code > Sean> points for something some despise/dislike and the IEEE > Sean> implementers following an additional link from the registry > Sean> they've already got to consult (they have to follow the link > Sean> because the registry values aren't copied to their spec). The > > I understand that you are hacking on the dumb customer reading registry > is also too dumb to follow the breadcrumbs over to IEEE in order to find > out what the groups are, in order to properly demand things. > > > I don't like this. > I want to know what the code point is for. tcpdump is not implementing > the protocol, just decoding it. I don't know if IEEE 802.11 will let > me see the assignments without jumping through hoops, of it they > will get mad if someone who has access to documents, submits a patch. > > > I claim that customers are actually too dumb to read the IANA registry > anyway, at most they grep rfc-index.txt for "IPSEC" and list that. So > actually it doesn't matter what we say in the IANA registry, as long > as implementers get it, it's okay. > > if: "Reserved for 802.11 SAE Brainpool Group 14" > will fit, I say go for that. It means that tcpdump will print something > like that out if it sees things (and if this is used in the parent SA, > it will be visible). Michael, I can see your point. I can see that the additional layer of redirection I added could be considered useless. From a procedural point of view though, I think we should discourage dual use of registries. spt From turners@ieca.com Thu Oct 11 18:23: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 13ECF21F84C9 for ; Thu, 11 Oct 2012 18:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.168 X-Spam-Level: X-Spam-Status: No, score=-101.168 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_20=-0.74, 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 RFynMgMNyFmv for ; Thu, 11 Oct 2012 18:23:32 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.93.154.37]) by ietfa.amsl.com (Postfix) with ESMTP id 89F2B21F8447 for ; Thu, 11 Oct 2012 18:23:32 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id ED0814D83B832; Thu, 11 Oct 2012 20:23:31 -0500 (CDT) Received: from ham01.websitewelcome.com (ham.websitewelcome.com [173.192.111.52]) by gateway05.websitewelcome.com (Postfix) with ESMTP id D7EC54D83B811 for ; Thu, 11 Oct 2012 20:23:31 -0500 (CDT) Received: by ham01.websitewelcome.com (Postfix, from userid 666) id 3F1AB7F7303C0; Thu, 11 Oct 2012 20:23:34 -0500 (CDT) X-Spam-Flag2999: NO X-Spam-Level2999: X-Spam-Status2999: "No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by ham01.websitewelcome.com (Postfix) with ESMTP id 985937F7302E7 for ; Thu, 11 Oct 2012 20:23:33 -0500 (CDT) Received: from [198.180.150.230] (port=56078 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TMTyL-0004GC-CE; Thu, 11 Oct 2012 20:23:31 -0500 Message-ID: <50776898.5010103@ieca.com> Date: Thu, 11 Oct 2012 19:47:20 -0500 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: Dan Harkins References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> In-Reply-To: <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> 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) [198.180.150.230]:56078 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 28 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= 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, 12 Oct 2012 01:23:34 -0000 Dan, Thanks for the backfill (ack that's it's not just for SAE). Question: If Johannes's draft had gone through for IKEv1 you wouldn't have needed to make the request for the code points? Because a clock is apparently ticking on the request I think we need to address the request in front of us not the combined issue. If at a later date, the registry is updated to add Brainpool curves then the "Group Description" rows for those can be updated. I'm going to run my proposal and Michael's by the IESG on an informal telechat to see which one's got the best chance of getting through the process to resolve the IEEE's request. spt On 9/21/12 4:42 PM, Dan Harkins wrote: > > 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 >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dharkins@lounge.org Thu Oct 11 23:32: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 9B87321F84EC for ; Thu, 11 Oct 2012 23:32:15 -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 isu7nmK1qrwW for ; Thu, 11 Oct 2012 23:32:14 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1B721F84A6 for ; Thu, 11 Oct 2012 23:32:14 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 5926B10224008; Thu, 11 Oct 2012 23:32:13 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 11 Oct 2012 23:32:13 -0700 (PDT) Message-ID: <9ce2776fdee6900ce0b6cc2952aa9d9e.squirrel@www.trepanning.net> In-Reply-To: <50776898.5010103@ieca.com> References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> Date: Thu, 11 Oct 2012 23:32:13 -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, Dan Harkins 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, 12 Oct 2012 06:32:15 -0000 Hi Sean, On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: > Dan, > > Thanks for the backfill (ack that's it's not just for SAE). > > Question: If Johannes's draft had gone through for IKEv1 you wouldn't > have needed to make the request for the code points? Yes, that's correct because the code points would just be there and the other protocols that use this registry would just blissfully start to refer to them. This whole problem started because some people decided that it was some sort of process issue to update this registry (Note: it's not). Again, this could've been just like RFC 5114-- no fuss, no mess, no hullaballo. If precedence has been followed, none of this nonsense would've happened. These notes and pointers that people may or may not pay attention to are just meta problems and they're all completely manufactured. They will all just go away if we just follow the path that RFC 5114 blazed. > Because a clock is apparently ticking on the request I think we need to > address the request in front of us not the combined issue. If at a > later date, the registry is updated to add Brainpool curves then the > "Group Description" rows for those can be updated. I don't understand your proposal. What is "the combined issue"? If the registry is not updated now and, instead is updated at a later date, then what is being done now? I have a draft that will need to get updated and the clock is ticking on that (cut-off date is 22 Oct). I need to know what you want my draft to say. > I'm going to run my proposal and Michael's by the IESG on an informal > telechat to see which one's got the best chance of getting through the > process to resolve the IEEE's request. Can you ask the IESG to just do what it has done in the past? That is, just update the registry to include code points for new curves without any bizarre notes or pointers? No fuss, no mess, just a few new rows in a table. The worst that could happen if the IESG agrees to do that is that someone somewhere might use a brainpool curve with IKEv1. The odds are slim, but they're not zero. And if that happens then so what? Really. So what? Dan. > spt > > On 9/21/12 4:42 PM, Dan Harkins wrote: >> >> 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 >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > From dharkins@lounge.org Thu Oct 11 23:32: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 3FA4121F84EC for ; Thu, 11 Oct 2012 23:32:16 -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 sY5zfgI0dn8x for ; Thu, 11 Oct 2012 23:32:16 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1571A21F84A6 for ; Thu, 11 Oct 2012 23:32:16 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 55E341022400A; Thu, 11 Oct 2012 23:32:15 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 11 Oct 2012 23:32:15 -0700 (PDT) Message-ID: In-Reply-To: <50776898.5010103@ieca.com> References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> Date: Thu, 11 Oct 2012 23:32:15 -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, Dan Harkins 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, 12 Oct 2012 06:32:16 -0000 Hi Sean, On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: > Dan, > > Thanks for the backfill (ack that's it's not just for SAE). > > Question: If Johannes's draft had gone through for IKEv1 you wouldn't > have needed to make the request for the code points? Yes, that's correct because the code points would just be there and the other protocols that use this registry would just blissfully start to refer to them. This whole problem started because some people decided that it was some sort of process issue to update this registry (Note: it's not). Again, this could've been just like RFC 5114-- no fuss, no mess, no hullaballo. If precedence has been followed, none of this nonsense would've happened. These notes and pointers that people may or may not pay attention to are just meta problems and they're all completely manufactured. They will all just go away if we just follow the path that RFC 5114 blazed. > Because a clock is apparently ticking on the request I think we need to > address the request in front of us not the combined issue. If at a > later date, the registry is updated to add Brainpool curves then the > "Group Description" rows for those can be updated. I don't understand your proposal. What is "the combined issue"? If the registry is not updated now and, instead is updated at a later date, then what is being done now? I have a draft that will need to get updated and the clock is ticking on that (cut-off date is 22 Oct). I need to know what you want my draft to say. > I'm going to run my proposal and Michael's by the IESG on an informal > telechat to see which one's got the best chance of getting through the > process to resolve the IEEE's request. Can you ask the IESG to just do what it has done in the past? That is, just update the registry to include code points for new curves without any bizarre notes or pointers? No fuss, no mess, just a few new rows in a table. The worst that could happen if the IESG agrees to do that is that someone somewhere might use a brainpool curve with IKEv1. The odds are slim, but they're not zero. And if that happens then so what? Really. So what? Dan. > spt > > On 9/21/12 4:42 PM, Dan Harkins wrote: >> >> 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 >>> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > From kivinen@iki.fi Fri Oct 12 04:56:49 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D206D21F8503 for ; Fri, 12 Oct 2012 04:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61zqP-1R7E9K for ; Fri, 12 Oct 2012 04:56:49 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 00CF321F84EF for ; Fri, 12 Oct 2012 04:56:48 -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 q9CBucbH013928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Oct 2012 14:56:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q9CBuZlo011502; Fri, 12 Oct 2012 14:56:35 +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: <20600.1394.960316.398546@fireball.kivinen.iki.fi> Date: Fri, 12 Oct 2012 14:56:34 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 39 min X-Total-Time: 17 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: Fri, 12 Oct 2012 11:56:49 -0000 Dan Harkins writes: > Again, this could've been just like RFC 5114-- no fuss, no mess, > no hullaballo. If precedence has been followed, none of this nonsense > would've happened. It is even easier to just drop the whole issue, and leave brainpool curves completely out, no fuss, no mess, no hullaballo. There has been precedence for that too, we have had proposals for IKEv1 which have been dropped and never gone forward or never even implemented (for example my revised hash format, notify message payload format etc). All additions / modifications etc do require some considerations before they are accepted. Things in the documents are not same (for example number of groups, the fact that 5114 already defines ECP groups for IKEv1 etc), time is not same (IKEv1 has been obsoleted almost 5 more years after the 5114 was published) etc. Also we do make mistakes, and we are supposed to be able to fix them. If we are never allowed doing anything else than what was done before, there is no way we can fix mistakes afterwards as this is how it was done once before, this is how it must be done forever in the future too. > I have a draft that will need to get updated and the clock is > ticking on that (cut-off date is 22 Oct). I need to know what you > want my draft to say. What is this draft you are refering here? Some IETF draft or some IEEE document? > Can you ask the IESG to just do what it has done in the past? That is, > just update the registry to include code points for new curves without > any bizarre notes or pointers? No fuss, no mess, just a few new rows > in a table. How about asking instead that do nothing, do not update the registry, and if IEEE has problems with that they can fix their document to refer to their own registries, or ask IANA to allocate new registry which they can manage and use that... I think the compromise Sean is proposing (i.e. add them as reserved values to the IKEv1 registry, add note to point them to new registry which defines them and create that new registry containing them) is good proposal, and I do not see why you are so much against it? It will allow using the groups in the IEEE, it does add one extra redirection, but only implementors should ever need that thus they should be able to follow pointers, it makes it clear for IKEv1 implementors that these numbers are not for IKEv1, which will make some people (including me) happy. -- kivinen@iki.fi From dharkins@lounge.org Fri Oct 12 09:43:54 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9315E21F8687 for ; Fri, 12 Oct 2012 09:43:54 -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=[AWL=-0.000, 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 qABt9FRsT6E8 for ; Fri, 12 Oct 2012 09:43:54 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E1F4721F868A for ; Fri, 12 Oct 2012 09:43:53 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CCD3810224008; Fri, 12 Oct 2012 09:43:52 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 12 Oct 2012 09:43:53 -0700 (PDT) Message-ID: <81c47f8322aa2f3f60bd7e7435a85ec4.squirrel@www.trepanning.net> In-Reply-To: <20600.1394.960316.398546@fireball.kivinen.iki.fi> References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> <20600.1394.960316.398546@fireball.kivinen.iki.fi> Date: Fri, 12 Oct 2012 09:43:53 -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 , Dan Harkins 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, 12 Oct 2012 16:43:54 -0000 On Fri, October 12, 2012 4:56 am, Tero Kivinen wrote: > Dan Harkins writes: >> Again, this could've been just like RFC 5114-- no fuss, no mess, >> no hullaballo. If precedence has been followed, none of this nonsense >> would've happened. > > It is even easier to just drop the whole issue, and leave brainpool > curves completely out, no fuss, no mess, no hullaballo. There has been > precedence for that too, we have had proposals for IKEv1 which have > been dropped and never gone forward or never even implemented (for > example my revised hash format, notify message payload format etc). You're conflating two different issues. This has nothing to do with the protocol. > All additions / modifications etc do require some considerations > before they are accepted. Things in the documents are not same (for > example number of groups, the fact that 5114 already defines ECP > groups for IKEv1 etc), time is not same (IKEv1 has been obsoleted > almost 5 more years after the 5114 was published) etc. But this is not a modification. This is an RFC required change to a registry. We're talking about making an RFC to update the registry. >> I have a draft that will need to get updated and the clock is >> ticking on that (cut-off date is 22 Oct). I need to know what you >> want my draft to say. > > What is this draft you are refering here? Some IETF draft or some IEEE > document? The draft that is referred to in the subject of this email. The draft that is going to end up having all these nonsensical notes and pointers and crap in it. That draft. >> Can you ask the IESG to just do what it has done in the past? That is, >> just update the registry to include code points for new curves without >> any bizarre notes or pointers? No fuss, no mess, just a few new rows >> in a table. > > How about asking instead that do nothing, do not update the registry, > and if IEEE has problems with that they can fix their document to > refer to their own registries, or ask IANA to allocate new registry > which they can manage and use that... We've already been through that. It's not a productive use of time to bring this up again. > I think the compromise Sean is proposing (i.e. add them as reserved > values to the IKEv1 registry, add note to point them to new registry > which defines them and create that new registry containing them) is > good proposal, and I do not see why you are so much against it? It > will allow using the groups in the IEEE, it does add one extra > redirection, but only implementors should ever need that thus they > should be able to follow pointers, it makes it clear for IKEv1 > implementors that these numbers are not for IKEv1, which will make > some people (including me) happy. It's not so much that I'm against this, it's that there is this huge discussion about notes and pointers and whether people will respect the notes and whether they can follow the pointers and making sure there is a sufficiently large enough firewall to keep IKEv1 implementers out while allowing others in... All of this is manufactured. These are all solutions to problems that we are imposing on ourselves. If we just decide not to impose those problems on ourselves then there is no need for these convoluted and ridiculous "solutions". H.L. Mencken once said that "puritanism is the haunting fear that someone somewhere might be having a good time." I think you have a haunting fear that someone somewhere might actually be working on IKEv1. And because of this haunting fear of yours you have succeeded in creating the problems and issues that require this convoluted and bizarre "way ahead" that we are all discussing. All of these problems just go away if we follow process and precedence. If you will just stop being afraid that someone somewhere might do something you don't like we can get this nonsense behind us. We're discussing a way ahead in this thread. I think that way is clear: let's just let Johannes follow the path that draft-lepinski-dh-groups did. A short, simple draft to update both registries without any cruft and notes and pointers and nonsense. It's easy, it's problem-free! Dan. From dharkins@lounge.org Fri Oct 12 16:02:21 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4935721F8508 for ; Fri, 12 Oct 2012 16:02:21 -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 sdH96VaRCtqZ for ; Fri, 12 Oct 2012 16:02:20 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7D80D21F8510 for ; Fri, 12 Oct 2012 16:02:20 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 24E0F10224008 for ; Fri, 12 Oct 2012 16:02:20 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 12 Oct 2012 16:02:20 -0700 (PDT) Message-ID: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> Date: Fri, 12 Oct 2012 16:02:20 -0700 (PDT) From: "Dan Harkins" To: ipsec@ietf.org 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 Subject: [IPsec] New I-D on IKEv3 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, 12 Oct 2012 23:02:21 -0000 Hello, I just submitted a new I-D that defines version 3 of IKE. The goals of this draft are to make a more easily understood, and simpler protocol that has a high degree of probability of achieving interoperability. It should be easier to read, easier to understand, and easier to implement. To those ends it: - severely limits the negotiable parameters and options - no long-term IKE SA, it's one and done - has a simple state machine which, if followed, should ensure the implementation interoperates with other implementations - is a true peer-to-peer protocol Please take a look and send me your comments! If you plan on implementing this protocol then definitely contact me, I want to interoperate with you. regards, Dan. ----------------------------------------------------------- Filename: draft-harkins-ikev3 Revision: 00 Title: The (Real) Internet Key Exchange Creation date: 2012-10-12 WG ID: Individual Submission Number of pages: 41 URL: http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt Status: http://datatracker.ietf.org/doc/draft-harkins-ikev3 Htmlized: http://tools.ietf.org/html/draft-harkins-ikev3-00 From paul@cypherpunks.ca Sat Oct 13 14:36: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 0F1A01F041C for ; Sat, 13 Oct 2012 14:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.175 X-Spam-Level: X-Spam-Status: No, score=-2.175 tagged_above=-999 required=5 tests=[AWL=0.424, 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 LfhoU4Aj1XH0 for ; Sat, 13 Oct 2012 14:36:10 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1BF1F0417 for ; Sat, 13 Oct 2012 14:36:10 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 2EB5D81995; Sat, 13 Oct 2012 17:35:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2045A81161; Sat, 13 Oct 2012 17:35:51 -0400 (EDT) Date: Sat, 13 Oct 2012 17:35:51 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Dan Harkins In-Reply-To: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> Message-ID: References: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] New I-D on IKEv3 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, 13 Oct 2012 21:36:11 -0000 On Fri, 12 Oct 2012, Dan Harkins wrote: > Subject: [IPsec] New I-D on IKEv3 Some remarks - stateless IKE I like not dealing with lingering IKE SA's, but how to tell if a connection is dead? idletime on the IPsec SA? How to do DPD? When a roadwarrior pops up at IP A, and then at IP B, etc, how do we get rid of IPsec SA A, B etc. Or do we ignore the outer IP completely and don't care about SRC/DST of the ESP packets and just send answers the the latest IP-port we saw? - "Only one instance of the IKEv3 protocol SHALL be run at time between any two peers." What about NAT, I guess you do mean "peers" and not "IPs" but can we always tell? - algorithm selection The responder can look at the initiator SPI and match up its SPI lower bits to give its own proposal a slight edge. Could that be problematic? - ID_BLOB_ID I like this! And already have a use for it - "and two Traffic Selector payloads (TS)" In IKEv2 and here I always found it very confusing to talk about "Traffic Selector payload" payload and the "Traffic Selector" payload. There should really be better terms for that. - I'm still not a fan of narrowing, see my earlier comments on ipsecme. It destroys the concept of a tunnel being "up" or "down". If you insist on narrowing, clearly state what should happen for traffic selectors outside the narrowed set, DROPed or ACCEPTed plaintext? Related: all the IKEv2 text about meaning of the first and second TS payload is missing (eg the src/dst of the trigger and the src/dst of the negiating SA). Was that intentional? - Why still support AH? - What happened to NAT Traversal negotiation? back to vendorids? - Should compression be disallowed? Paul From svanru@gmail.com Mon Oct 15 06:55:51 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6052721F86DF for ; Mon, 15 Oct 2012 06:55:51 -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, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] 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 DfofUVFq154Q for ; Mon, 15 Oct 2012 06:55:51 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6C521F86DE for ; Mon, 15 Oct 2012 06:55:50 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3865299lam.31 for ; Mon, 15 Oct 2012 06:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=WVueYHlx4qr6GxBb7JbxXMBrGPNAB3fINNFfj/qFuPw=; b=u/uS0i2T9Oh76qBfDfSzzEkZLACwxUYsoD+7EY7aXk2gO+YLhujuN/GpqUHRB8WrNN ekewDKNOOusEbxot1n95BSjxxdEPq/gGkTNnRsWh3uEuswIk1MMWmPlBFBymR+tu3saE ZbWG5prbKCSItt6p5p7ewlq2Lfm0xkRLKMU4Wa0uIrD0wrv+VI/JUfILncrrohaHQPgs 7K5Rhiy4tljbMvH1C7RprC83tuFIOto+DdqmwkSw3yjkNd588HbKUFpvdUcb4/M4KQNk yT6PyjPa7VFLJDjUrWgvMuQg0nWaJwfpQ3cntiXNe6mUAYiALzgPn3g6VGkdCIpGKQ5S bLag== Received: by 10.152.105.174 with SMTP id gn14mr9986916lab.55.1350309349193; Mon, 15 Oct 2012 06:55:49 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id q2sm4636047lbd.14.2012.10.15.06.55.46 (version=SSLv3 cipher=OTHER); Mon, 15 Oct 2012 06:55:48 -0700 (PDT) Message-ID: <6790B6A40D544ED29AA9A0B04DCA4BB5@buildpc> From: "Valery Smyslov" To: Date: Mon, 15 Oct 2012 17:55:43 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-fragmentation-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 13:55:51 -0000 Hi, I submited an I-D describing a way to avoid IP fragmentation of large IKE messages by fragmenting them on IKE level. Comments are appreciated. Regards, Valery Smyslov. --------------------------------------------------------- A new version of I-D, draft-smyslov-ipsecme-ikev2-fragmentation-00.txt has been successfully submitted by Valery Smyslov and posted to the IETF repository. Filename: draft-smyslov-ipsecme-ikev2-fragmentation Revision: 00 Title: IKEv2 Fragmentation Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-fragmentation-00.txt Status: http://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-fragmentation Htmlized: http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-fragmentation-00 Abstract: This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. The IETF Secretariat From nico@cryptonector.com Mon Oct 15 10:26: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 DE74421F871D for ; Mon, 15 Oct 2012 10:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.015 X-Spam-Level: X-Spam-Status: No, score=-2.015 tagged_above=-999 required=5 tests=[AWL=-0.038, 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 vxl0qTQtY6JE for ; Mon, 15 Oct 2012 10:26:01 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 261E321F86EF for ; Mon, 15 Oct 2012 10:26:01 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 8BD5426C079 for ; Mon, 15 Oct 2012 10:26:00 -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=hqjGWsnJLDZhI3wzgQxv edrZJR4=; b=nz8cMtDB0NndMd2d4/HyUW3ZAJj73WaSgIpih966QjYHcR+ad5b4 aldipRHUYEYN2kHoEHVj5TuAgIpmReyYQxRDRXzmOSdjOwj7GLibibZKkqYZiFoE WKIEFYrL8ZKwf3qjeVnzQ2M4ds9TXCBqggbwc9AUG9OxW4FLjossHgg= 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-a87.g.dreamhost.com (Postfix) with ESMTPSA id 5F22526C07D for ; Mon, 15 Oct 2012 10:26:00 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id ro8so5082129pbb.31 for ; Mon, 15 Oct 2012 10:25:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.204.132 with SMTP id ky4mr38824103pbc.164.1350321959916; Mon, 15 Oct 2012 10:25:59 -0700 (PDT) Received: by 10.68.20.194 with HTTP; Mon, 15 Oct 2012 10:25:59 -0700 (PDT) In-Reply-To: References: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> Date: Mon, 15 Oct 2012 12:25:59 -0500 Message-ID: From: Nico Williams To: Paul Wouters Content-Type: text/plain; charset=UTF-8 Cc: "ipsec@ietf.org WG" , Dan Harkins Subject: Re: [IPsec] New I-D on IKEv3 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, 15 Oct 2012 17:26:02 -0000 On Sat, Oct 13, 2012 at 4:35 PM, Paul Wouters wrote: > On Fri, 12 Oct 2012, Dan Harkins wrote: > - I'm still not a fan of narrowing, see my earlier comments on ipsecme. > It destroys the concept of a tunnel being "up" or "down". If you > insist on narrowing, clearly state what should happen for traffic > selectors outside the narrowed set, DROPed or ACCEPTed plaintext? > Related: all the IKEv2 text about meaning of the first and second TS > payload is missing (eg the src/dst of the trigger and the src/dst of > the negiating SA). Was that intentional? There's been some discussion of this and I don't think tunnel state is that simple a concept even w/o SA narrowing. Quite aside from that there are non-VPN use cases for narrowing SAs, so I'd like that to remain. > - Why still support AH? Indeed, just remove AH. > - Should compression be disallowed? Or at least NOT RECOMMENDED. Nico -- From paul.hoffman@vpnc.org Mon Oct 15 12:02:52 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F353121F88E2 for ; Mon, 15 Oct 2012 12:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 pizbD4RNSA0S for ; Mon, 15 Oct 2012 12:02:51 -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 BBA4F21F88DD for ; Mon, 15 Oct 2012 12:02:49 -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 q9FJ2lOi088147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 15 Oct 2012 12:02:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 15 Oct 2012 12:02:48 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPsec] Nudge on discussion of WG work item: IKE over TCP 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, 15 Oct 2012 19:02:52 -0000 Greetings again. draft-ietf-ipsecme-ike-tcp-00.txt has been out for over = a month and has received no discussion. Please review this short draft = and comment on the mailing list. --Paul Hoffman= From turners@ieca.com Mon Oct 15 17:00:55 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CB221F8859 for ; Mon, 15 Oct 2012 17:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, 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 15AxxPUv-ZZ8 for ; Mon, 15 Oct 2012 17:00:54 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.93.115.20]) by ietfa.amsl.com (Postfix) with ESMTP id 634A121F883D for ; Mon, 15 Oct 2012 17:00:54 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 624644153F13C; Mon, 15 Oct 2012 19:00:54 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 56D854153F11C for ; Mon, 15 Oct 2012 19:00:54 -0500 (CDT) Received: from [96.241.97.104] (port=61619 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TNuab-0004H3-IO; Mon, 15 Oct 2012 19:00:53 -0500 Message-ID: <507CA3B4.1070303@ieca.com> Date: Mon, 15 Oct 2012 20:00:52 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Dan Harkins References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.241.97.104]:61619 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= 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: Tue, 16 Oct 2012 00:00:55 -0000 Hi Dan, See inline. spt On 10/12/12 2:32 AM, Dan Harkins wrote: > > Hi Sean, > > On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: >> Dan, >> >> Thanks for the backfill (ack that's it's not just for SAE). >> >> Question: If Johannes's draft had gone through for IKEv1 you wouldn't >> have needed to make the request for the code points? > > Yes, that's correct because the code points would just be there and > the other protocols that use this registry would just blissfully start > to refer to them. This whole problem started because some people > decided that it was some sort of process issue to update this registry > (Note: it's not). > > Again, this could've been just like RFC 5114-- no fuss, no mess, > no hullaballo. If precedence has been followed, none of this nonsense > would've happened. > > These notes and pointers that people may or may not pay attention > to are just meta problems and they're all completely manufactured. > They will all just go away if we just follow the path that RFC 5114 blazed. Okay so I get it now. If a brainpool curves for IKEv1 was published the IEEE wouldn't have made the request. >> Because a clock is apparently ticking on the request I think we need to >> address the request in front of us not the combined issue. If at a >> later date, the registry is updated to add Brainpool curves then the >> "Group Description" rows for those can be updated. > > I don't understand your proposal. What is "the combined issue"? If > the registry is not updated now and, instead is updated at a later date, > then what is being done now? Sorry by combined issue I'm referring to waiting on figuring out whether the registry values will be included without the not for IKEv1 note. > I have a draft that will need to get updated and the clock is ticking on > that (cut-off date is 22 Oct). I need to know what you want my draft > to say. I should have an answer by Thursday. >> I'm going to run my proposal and Michael's by the IESG on an informal >> telechat to see which one's got the best chance of getting through the >> process to resolve the IEEE's request. > > Can you ask the IESG to just do what it has done in the past? That is, > just update the registry to include code points for new curves without > any bizarre notes or pointers? No fuss, no mess, just a few new rows > in a table. > > The worst that could happen if the IESG agrees to do that is that someone > somewhere might use a brainpool curve with IKEv1. The odds are slim, > but they're not zero. And if that happens then so what? Really. So what? The RFC 5114 example wasn't published to address another SDO request for a code point so I don't think it's the same situation. spt > Dan. > >> spt >> >> On 9/21/12 4:42 PM, Dan Harkins wrote: >>> >>> 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 >>>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> > > From dharkins@lounge.org Mon Oct 15 19:54:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C808E21F86DF for ; Mon, 15 Oct 2012 19:54:04 -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 PG6wAIqzM7zt for ; Mon, 15 Oct 2012 19:54:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id DFDE721F86F9 for ; Mon, 15 Oct 2012 19:54:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 37B7510224008; Mon, 15 Oct 2012 19:54:03 -0700 (PDT) Received: from 115.125.248.113 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 15 Oct 2012 19:54:03 -0700 (PDT) Message-ID: <6f873581eff8119db139416e44a0d0d2.squirrel@www.trepanning.net> In-Reply-To: <507CA3B4.1070303@ieca.com> References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> <507CA3B4.1070303@ieca.com> Date: Mon, 15 Oct 2012 19:54:03 -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, Dan Harkins 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, 16 Oct 2012 02:54:04 -0000 Hi Sean, On Mon, October 15, 2012 5:00 pm, Sean Turner wrote: > > On 10/12/12 2:32 AM, Dan Harkins wrote: >> >> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: >>> >>> I'm going to run my proposal and Michael's by the IESG on an informal >>> telechat to see which one's got the best chance of getting through the >>> process to resolve the IEEE's request. >> >> Can you ask the IESG to just do what it has done in the past? That >> is, >> just update the registry to include code points for new curves without >> any bizarre notes or pointers? No fuss, no mess, just a few new rows >> in a table. >> >> The worst that could happen if the IESG agrees to do that is that >> someone >> somewhere might use a brainpool curve with IKEv1. The odds are slim, >> but they're not zero. And if that happens then so what? Really. So what? > > The RFC 5114 example wasn't published to address another SDO request for > a code point so I don't think it's the same situation. That's certainly a distinction but I don't see how that matters. You could also note that RFC 5114 added MODP groups as well as ECP groups. Also a distinction that really doesn't matter. Again, the SDO request is a _by-product_ of the opposition to just letting Johannes' draft update the registry. It is this same opposition that is creating these problems about notes and pointers and the concern over whether they will have the desired effect and what we should do to ensure they do. If this opposition had not materialized there never would've been another SDO request. It is the same situation, indulge me here a bit: What we had was another organization (NIST) came up with some new DH groups and there was a proposal to add them to both IKEv1 and IKEv2 registries. And now, quite similarly, there's another organization (the ECC Brainpool) that came up with some new DH groups and there was a proposal to add them to both IKEv1 and IKEv2 registries. When the proposal was made to add the NIST groups to the IKEv1 registry there was no hullabaloo over updating a deprecated protocol's registry and there was no concern that someone somewhere might use the NIST groups with IKEv1. But when Johannes made his proposal to add the ECC Brainpool curves to the IKEv1 registry there was all of a sudden a hullabaloo and much concern that someone somewhere might use the ECC Brainpool groups with IKEv1. So my request to you is to ask that the IESG consider what the process defined for updating this registry is (it's RFC required) and to note that there is precedence to update the registry of this deprecated protocol. So please ask the IESG to just approve a draft (either Johannes' or mine) for publication as an RFC to update this registry in the same manner that RFC 5114 updated it (i.e. no notes, no pointers, no nonsense). Then there'd be no need for the IESG to have a discussion about the (de)merits of notes and pointers in registries and how best to ensure that no one nowhere ever even thinks about using an ECC Brainpool curve in IKEv1 and that certainly sounds like a better use of everyone's time. regards, Dan. From paul@cypherpunks.ca Mon Oct 15 20:14:43 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AC71F0C9F for ; Mon, 15 Oct 2012 20:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 LCmB7YQKCRPo for ; Mon, 15 Oct 2012 20:14:42 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id AFB501F0C9D for ; Mon, 15 Oct 2012 20:14:42 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id A19DA82A2C; Mon, 15 Oct 2012 23:14:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 953D082574; Mon, 15 Oct 2012 23:14:21 -0400 (EDT) Date: Mon, 15 Oct 2012 23:14:21 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul Hoffman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: IPsecme WG Subject: Re: [IPsec] Nudge on discussion of WG work item: IKE over TCP 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, 16 Oct 2012 03:14:43 -0000 On Mon, 15 Oct 2012, Paul Hoffman wrote: > Greetings again. draft-ietf-ipsecme-ike-tcp-00.txt has been out for over a month and has received no discussion. Please review this short draft and comment on the mailing list. Thanks for the reminder. I've read the draft and discussed it in Vancouver as well. I'm in favour of adopting it. Some notes, I know no one wants to define this for IKEv1, but I'd still prefer to keep this in sync between IKEv1 and IKEv2. I don't neccessarilly agree with the 1.1 non-goals. While I understand this is not done primarily to avoid administrative filters, I see no reason why to go out of our way to make it easy to filter IKE/IPsec. If IKE could signal a TCP port along with the IKE_TCP_SUPPORTED payload this would allow people so more freedom with running on different ports, or even kickstarting IKE over another protocol (instant message, whatever). I think the two octets are well spent for this. Should the initiator also send IKE_TCP_SUPPORTED to the responder? The initiator/responder roles could switch around at rekey, and it would be useful to the initial responder (now initiator) whether or not it can or should just start with TCP. Although it could deduce this from having received a connection on TCP in the previous exchange. I'm not sure on this one. Paul From dharkins@lounge.org Tue Oct 16 00:37: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 98EB621F8866 for ; Tue, 16 Oct 2012 00:37:25 -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=[AWL=-0.000, 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 fypWItQ3iMeT for ; Tue, 16 Oct 2012 00:37:24 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A636821F8867 for ; Tue, 16 Oct 2012 00:37:24 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A042610224008; Tue, 16 Oct 2012 00:37:23 -0700 (PDT) Received: from 115.125.248.113 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 16 Oct 2012 00:37:23 -0700 (PDT) Message-ID: In-Reply-To: References: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> Date: Tue, 16 Oct 2012 00:37:23 -0700 (PDT) From: "Dan Harkins" To: "Paul Wouters" 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 WG" Subject: Re: [IPsec] New I-D on IKEv3 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, 16 Oct 2012 07:37:25 -0000 Hi Paul, On Sat, October 13, 2012 2:35 pm, Paul Wouters wrote: > On Fri, 12 Oct 2012, Dan Harkins wrote: > >> Subject: [IPsec] New I-D on IKEv3 > > Some remarks > > - stateless IKE > > I like not dealing with lingering IKE SA's, but how to tell if a > connection is dead? idletime on the IPsec SA? How to do DPD? That's a great question. There's alot of complexity that gets added for IKE to deal with DPD and I'd just like to punt that to something else. Idletime on the IPsec SAs is probably the way to do it. > When a roadwarrior pops up at IP A, and then at IP B, etc, how do > we get rid of IPsec SA A, B etc. Or do we ignore the outer IP completely > and don't care about SRC/DST of the ESP packets and just send answers > the the latest IP-port we saw? I think any stale SA would be cleaned up by the "something else" I referred to above. Figuring out where to send packets may require some linkage between outer and inner addresses when they get plumbed into the kernel that would orphan an "old" IPsec SA (and possibly facilitate it's cleanup). Which reminds me, one thing missing from IKEv3 is a "config mode". That really needs to be there. > - "Only one instance of the IKEv3 protocol SHALL be run at time between > any two peers." > > What about NAT, I guess you do mean "peers" and not "IPs" but can we > always tell? NAT detection is another thing I left out in my rush to hit the -00 cutoff date. I mean "peers" and the way we can tell is to include a "this is what I think my address is" payload. The recipient can then tell whether the other side is behind a NAT and disambiguate multiple "peers" behind the same IP address to enforce the "only one instance" requirement. > - algorithm selection > > The responder can look at the initiator SPI and match up its SPI lower > bits to give its own proposal a slight edge. Could that be problematic? The tie is only the case where both sides initiate simultaneously and that happens when neither side has seen the other's offer. There just needs to be some way to unambiguously converge on accepted parameters. Of course, an implementation can receive the other side's offer and respond as if it did not (make a tie that it will win) but a responder will always have a slight edge because he gets to see the initiator's offer before exposing his own. Provided that they converge on acceptable parameters, is this a problem? > - ID_BLOB_ID > > I like this! And already have a use for it > > - "and two Traffic Selector payloads (TS)" > > In IKEv2 and here I always found it very confusing to talk about > "Traffic Selector payload" payload and the "Traffic Selector" payload. > There should really be better terms for that. > > - I'm still not a fan of narrowing, see my earlier comments on ipsecme. > It destroys the concept of a tunnel being "up" or "down". If you > insist on narrowing, clearly state what should happen for traffic > selectors outside the narrowed set, DROPed or ACCEPTed plaintext? > Related: all the IKEv2 text about meaning of the first and second TS > payload is missing (eg the src/dst of the trigger and the src/dst of > the negiating SA). Was that intentional? It was not intentional to lose important information, it's just that that section is kind of verbose and I think can be stated more succinctly. If the IKEv3 text is missing important information, I will try to clean it up. > - Why still support AH? I have no love of AH but is it up to the key exchange protocol to kill off an IPsec protocol? > - What happened to NAT Traversal negotiation? back to vendorids? It will be in -01. > - Should compression be disallowed? I am agnostic on the subject and willing to follow the will of the group. Thanks alot for your comments; much appreciated. regards, Dan. From ynir@checkpoint.com Tue Oct 16 04:12:02 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D533121F8898 for ; Tue, 16 Oct 2012 04:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 B2NHS04dGH7e for ; Tue, 16 Oct 2012 04:12:02 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C067921F8826 for ; Tue, 16 Oct 2012 04:12:01 -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 q9GBBkPn030067; Tue, 16 Oct 2012 13:11:46 +0200 X-CheckPoint: {507D3F39-13-1B221DC2-2FFFF} 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; Tue, 16 Oct 2012 13:11:45 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 16 Oct 2012 13:11:45 +0200 From: Yoav Nir To: Paul Wouters Date: Tue, 16 Oct 2012 13:11:48 +0200 Thread-Topic: [IPsec] Nudge on discussion of WG work item: IKE over TCP Thread-Index: Ac2rjwc7oWJEvooURluhA7r1jqSI1Q== Message-ID: <366E001B-D6D8-4CDF-8E91-CA1F25566104@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IPsecme WG , Paul Hoffman Subject: Re: [IPsec] Nudge on discussion of WG work item: IKE over TCP 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, 16 Oct 2012 11:12:02 -0000 On Oct 16, 2012, at 5:14 AM, Paul Wouters wrote: > On Mon, 15 Oct 2012, Paul Hoffman wrote: >=20 >> Greetings again. draft-ietf-ipsecme-ike-tcp-00.txt has been out for over= a month and has received no discussion. Please review this short draft and= comment on the mailing list. >=20 > Thanks for the reminder. >=20 > I've read the draft and discussed it in Vancouver as well. I'm in favour > of adopting it. Well, you got it. It's already a working group draft. > I know no one wants to define this for IKEv1, but I'd still prefer to > keep this in sync between IKEv1 and IKEv2. I agree, and there's nothing stopping you (or me) from implementing this fo= r IKEv1, but the group has spoken. See similar discussions about Brainpool = curves. > I don't neccessarilly agree with the 1.1 non-goals. While I understand > this is not done primarily to avoid administrative filters, I see no > reason why to go out of our way to make it easy to filter IKE/IPsec. > If IKE could signal a TCP port along with the IKE_TCP_SUPPORTED payload > this would allow people so more freedom with running on different ports, > or even kickstarting IKE over another protocol (instant message, > whatever). I think the two octets are well spent for this. True. But do you think it's a common case, where the responder is behind a = filter that drops TCP port 500, but that responder knows of a different por= t that is open? I suppose the responder could be behind some NAT device wit= h the ability to map a forwarded port on the NAT device. I guess this makes= sense. But then you have the initiator opening a connection to a random po= rt. That has a far greater chance of getting filtered on the initiator side= (firewalls tend to drop what they don't recognize). At least in our firewall, FTP got special treatment - the control connectio= n is monitored to recognize and allow the ports that are used by the data c= onnections, but I don't think we can expect the firewall makers repeat this= effort for IKE with random ports. > Should the initiator also send IKE_TCP_SUPPORTED to the responder? The > initiator/responder roles could switch around at rekey, and it would > be useful to the initial responder (now initiator) whether or not it > can or should just start with TCP. Although it could deduce this from > having received a connection on TCP in the previous exchange. I'm not > sure on this one. I guess, but rekey doesn't require TCP, as it doesn't have the IKE_AUTH exc= hange. It may be useful so that next time the original responder can begin = the Initial exchange with TCP. >=20 > Paul > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Tue Oct 16 05:28: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 651BC21F88B8 for ; Tue, 16 Oct 2012 05:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8khGJCfqGRN for ; Tue, 16 Oct 2012 05:28:16 -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 11A3321F88B7 for ; Tue, 16 Oct 2012 05:28:15 -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 q9GCRwXD009232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 15:27:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q9GCRsxu001222; Tue, 16 Oct 2012 15:27: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: <20605.21194.121741.913954@fireball.kivinen.iki.fi> Date: Tue, 16 Oct 2012 15:27:54 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <366E001B-D6D8-4CDF-8E91-CA1F25566104@checkpoint.com> References: <366E001B-D6D8-4CDF-8E91-CA1F25566104@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: IPsecme WG , Paul Wouters , Paul Hoffman Subject: Re: [IPsec] Nudge on discussion of WG work item: IKE over TCP 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, 16 Oct 2012 12:28:17 -0000 Yoav Nir writes: > True. But do you think it's a common case, where the responder is > behind a filter that drops TCP port 500, but that responder knows of > a different port that is open? I suppose the responder could be > behind some NAT device with the ability to map a forwarded port on > the NAT device. I guess this makes sense. But then you have the > initiator opening a connection to a random port. That has a far > greater chance of getting filtered on the initiator side (firewalls > tend to drop what they don't recognize). If initiator is behind NAT and uses some of those protocols to talk to the NAT / FW and request a TCP port that will get forwarded to it then this sending that port number inside the IKE notify payload would be useful, in case the responder ever needs to reconnect back to him. Also quite often firewalls have been set up so that all incoming connections not explicitly allowed are forbidden, but all outgoing connections not expiicitly forbidden are allowed. Now when the initiator sets up the TCP listener port by talking to the NAT / FW, then responder can connect to that port if needed, and responders NAT / FW most likely will allow responder to connect to that port without any special configuration. > At least in our firewall, FTP got special treatment - the control > connection is monitored to recognize and allow the ports that are > used by the data connections, but I don't think we can expect the > firewall makers repeat this effort for IKE with random ports. This is because firewalls try to do this without the help of the FTP client / server. There are now protocols which allows client / servers to connect to the NAT / FW and ask for this kind of services, thus there is no need for NAT / FW to look inside the data packets and find out the ports. > > Should the initiator also send IKE_TCP_SUPPORTED to the responder? The > > initiator/responder roles could switch around at rekey, and it would > > be useful to the initial responder (now initiator) whether or not it > > can or should just start with TCP. Although it could deduce this from > > having received a connection on TCP in the previous exchange. I'm not > > sure on this one. > > I guess, but rekey doesn't require TCP, as it doesn't have the > IKE_AUTH exchange. It may be useful so that next time the original > responder can begin the Initial exchange with TCP. You are assuming that only reason to use TCP is because the IKE_AUTH packet is so big it gets fragmented. There has been also some comments that using TCP also helps going through NAT / FW boxes, in which case TCP is required to do any exchanges. I have not read the latest version, it is on my todo list, I will get back with more specific comments when I have time to read it. -- kivinen@iki.fi From kivinen@iki.fi Tue Oct 16 05:51:02 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A21A21F8845 for ; Tue, 16 Oct 2012 05:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 JjlXqkEbijNA for ; Tue, 16 Oct 2012 05:51:01 -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 B96FD21F87F4 for ; Tue, 16 Oct 2012 05:50:53 -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 q9GCoqSH020329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Oct 2012 15:50:52 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q9GComFS016765; Tue, 16 Oct 2012 15:50:48 +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: <20605.22568.706182.460230@fireball.kivinen.iki.fi> Date: Tue, 16 Oct 2012 15:50:48 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 9 min Subject: [IPsec] New Version Notification for draft-kivinen-ipsecme-oob-pubkey-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2012 12:51:02 -0000 I updated the draft-kivinen-ipsecme-oob-pubkey document, the new version includes some examples in the appendix, including the actual bits on the wire examples. One thing that needs to be decided before this document is ready: "What shall we do with the old "Raw RSA Key" format?" The current draft keeps it, and RECOMMENDs this new format for all types of raw keys, and does the negotiation using the standard IKEv2 CERTREQ payloads. This means there is two ways of doing exactly same thing, i.e. sending Raw RSA keys in IKEv2. Another option would be to change this document to be Standard track document, mark it as Updating 5996, and say that using old "Raw RSA Key" format is NOT RECOMMENDED. This would mean there is only one way of sending Raw RSA keys keys in IKEv2, i.e. the new way. Third option would say that this new format is only used for non-RSA keys, and for Raw RSA keys, you always MUST use the old format. I do not like this last option as it would require minimal implementations to implement both formats, as with both of the above options the minimal implementation can just decide that it only supports this one format and uses it for everything. I would like to get feedback from the WG, which way should we go forward? ---------------------------------------------------------------------- From: internet-drafts@ietf.org Subject: New Version Notification for draft-kivinen-ipsecme-oob-pubkey-01.txt Date: Tue, 16 Oct 2012 05:40:09 -0700 A new version of I-D, draft-kivinen-ipsecme-oob-pubkey-01.txt has been successfully submitted by Tero Kivinen and posted to the IETF repository. Filename: draft-kivinen-ipsecme-oob-pubkey Revision: 01 Title: More Raw Public Keys for IKEv2 Creation date: 2012-10-16 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-oob-pubkey-01.txt Status: http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey Htmlized: http://tools.ietf.org/html/draft-kivinen-ipsecme-oob-pubkey-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-kivinen-ipsecme-oob-pubkey-01 Abstract: The Internet Key Exchange Version 2 (IKEv2) protocol currently only supports raw RSA keys. In some environments it is useful to make use of other types of public keys, such as those based on Elliptic Curve Cryptography. This documents adds support for other types of raw public keys to IKEv2. -- kivinen@iki.fi From svanru@gmail.com Tue Oct 16 06:15: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 F25B021F8955 for ; Tue, 16 Oct 2012 06:15:18 -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, RCVD_IN_DNSWL_LOW=-1, STOX_REPLY_TYPE=0.001] 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 cgj+1+t8EvQJ for ; Tue, 16 Oct 2012 06:15:18 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 23C9D21F860E for ; Tue, 16 Oct 2012 06:15:17 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so4733842lam.31 for ; Tue, 16 Oct 2012 06:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=MT+nwFUifhXUBtWrh9FBa0PZhcRPfe0HofcivFgafc0=; b=zNVtO53bcg3nFn0b7fawG/c3rGMs+MwqDyxKP9MkLXcNKprCR9fgSLHcYEOHnD51/6 3xuhW6/Bx+hTdjjOWzPzk924JJfTFwvCQZrvwYqD1gaN1yiDp2E3a6sHO/Rb1VBS+wPQ /ItLrWSFhGh0quMd/Qhri4/3qWxSze72i4pwwryTSe7seMkZ0siqAhLc6HrqgC5i5cIT Nn1kVKKTy3XvJra8IMCiStG3nLWVf5Wk6ZuniU0ekTuIRSrMrmy7TTzPnsTfZj/rsIvz NOXaJL4CPKd7xMSwuMaSXkuTx/oR8He+NAZ8S04pj/rB3xC5imwF+I+qR0CBKsIGWaAW miFw== Received: by 10.112.82.33 with SMTP id f1mr5230045lby.121.1350393316925; Tue, 16 Oct 2012 06:15:16 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPS id sy1sm5503360lab.16.2012.10.16.06.15.14 (version=SSLv3 cipher=OTHER); Tue, 16 Oct 2012 06:15:15 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "IPsecme WG" References: Date: Tue, 16 Oct 2012 17:15:11 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Subject: Re: [IPsec] Nudge on discussion of WG work item: IKE over TCP 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, 16 Oct 2012 13:15:19 -0000 Hi, a few remarks regarding interaction with NAT traversal. 1. In case there's a NAT in between and IKE_AUTH is done over TCP, there's no event of switching to UDP ports 4500 (which usually takes place in IKE_AUTH). a) Which ports should use responder if it wants itself to initiate new Exchange over UDP or just wants to send a UDP encapsulated ESP packet to initiator? I see one possibility - responder must wait untill Initiator initiates any subsequent Exchange over UDP 4500 or sends some UDP encapsulated traffic - only after that responder could learn the ports NAT is allocated for this mapping. But in general this may never happen - IKE SA could be established with no triggering packet from initiator ("Connect" button). b) In case initiator is behind NAT it seems that responder can't use ephemeral TCP for any exchange it initiates, can it? And it can't initiate over UDP untill get learned the ports NAT has allocated (see clause above). 2. Draft says that retransissions could be done over different transport. In case IKE_SA_INIT request is first sent over UDP and then retransmitted over TCP, what about NAT_DETECTION_SOURCE_IP content? According to RFC5996 the retransmitted message MUST be identical to original, but in this case source port of TCP session will most likely be different from port original message was sent from, that will lead to erroneous NAT detection. 3. Related to above: RFC5996 allows to make IKE_SA_INIT request directly to UDP 4500 instead of 500. The draft says that TCP transport is using port 500. Because only one NAT_DETECTION_DESTINATION_IP can be included In IKE_SA_INIT, we again face the problem of erroneous NAT detection. 4. If ports are included in COOKIE calculation, retransmissions of IKE_SA_INIT containing COOKIE over different transport will be rejected. Regards, Valery Smyslov. From paul.hoffman@vpnc.org Wed Oct 17 07:38:45 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8CE21F8514 for ; Wed, 17 Oct 2012 07:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 CX01gJGJHAP6 for ; Wed, 17 Oct 2012 07:38:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CCD7221F851C for ; Wed, 17 Oct 2012 07:38:44 -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 q9HEcf9I076416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 17 Oct 2012 07:38:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 17 Oct 2012 07:38:42 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 14:38:45 -0000 Greetings again. We have a 2-hour time slot in Atlanta, which is way = more than we asked for. We don't need to be talking about = draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and = is being sent to the AD for review. This is a call for agenda items. = Strong preference is given to those which are in the WG charter. draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and hopefully = there will be more discussion of it before the meeting --Paul Hoffman= From Chris.Ulliott@cesg.gsi.gov.uk Wed Oct 17 07:47:49 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE7021F85D5 for ; Wed, 17 Oct 2012 07:47:49 -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 cv3OaBRZO4oQ for ; Wed, 17 Oct 2012 07:47:48 -0700 (PDT) Received: from mail204.messagelabs.com (mail204.messagelabs.com [85.158.143.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5992B21F8596 for ; Wed, 17 Oct 2012 07:47:48 -0700 (PDT) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-7.tower-204.messagelabs.com!1350485266!4404532!1 X-Originating-IP: [195.92.40.48] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 19717 invoked from network); 17 Oct 2012 14:47:46 -0000 Received: from gateway-201.energis.gsi.gov.uk (HELO mx.hosting-e.gsi.gov.uk) (195.92.40.48) by server-7.tower-204.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Oct 2012 14:47:46 -0000 From: "Ulliott, Chris" To: IPsecme WG Date: Wed, 17 Oct 2012 15:47:40 +0100 Thread-Topic: [IPsec] STRONG NUDGE: Revised AD VPN Requirements Thread-Index: Ac2N33XdbFzxrkPhSLSCns+6QkFpnwelKpkA Message-ID: <20549DD10769DA47A86F0F0FAF8012DD03955054E2@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 17 Oct 2012 14:47:49 -0000 Apologies for the delay in replying... I think the Gateway to gateway use case (para 2.2) doesn't cover the probl= em I'm suffering. What if the use case was reworded such that it says som= ething along the lines of: -- start -- A typical Enterprise traffic model is hub and spoke, with the gateways con= necting to each other using IPsec tunnels. However for the voice and other rich media traffic that occupies a lot of = bandwidth or is performance sensative, the traffic tromboning to the hub c= an create traffic bottlenecks on the hub and can lead to an increase in co= st. A fully meshed solution is would make best use of the available netwo= rk capacity and performance but the deployment of a fully meshed solution = involves considerable configuration, especially when a large number of nod= es are involved. For the reasons of cost and manual error reduction, it i= s desired that there be minimal configuration on each gateway. It is highly desirable that the solution works where the endpoints are adm= inistrated by separate management domains, albeit, ones that have an exist= ing trust relationship (for example two organisations who are collaboratin= g on a project, they may wish to join their networks, whilst retaining ind= ependent control over configuration) When two gateways communicate, they must use a mechanism for authenticatio= n, such that they do not expose themselves to the risk of impersonation by= the other entities. -- end -- In section 3.2, it would be nice if we could again mention that rather loo= king for a solution that makes a star architecture work, actually enables = a dynamic, fully meshed solution to be practical. In section 4.1, there are comments about minimising the configuration chan= ges... should we word this a bit stronger and say that after initial confi= guration, there should be no need for a manual configuration change as dev= ices (endpoint or gateways) are added, removed or changed? For the use case where end points need to find the optimum gateway to conn= ect to, do we need a requirement that enables an endpoint to identify whic= h is the best gateway to connect to, the nearest may not be the best, depe= nding on the network cost behind the gateway... but this may be complicati= ng the problem too much. Thoughts? Chris -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = Paul Hoffman Sent: Saturday, September 08, 2012 5: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 > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem > > A summary of the changes in this version is included at > the end of this message. > > Please review this document and provide any comments on > the existing requirements or suggestions for new ones. > > 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. > > Thanks, > > Steve > > ------------ > > Summary of Changes in draft-ietf-ipsecme-ad-vpn-00.txt > > * Changed draft name from p2p-vpn to ad-vpn. > > * Added a paragraph for each requirement, explaining how > that requirement is driven by the use cases. > > * In requirement 1, defined what we mean by minimizing > configuration changes. > > * 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. > > * Split requirement 4 into two requirements (now 4 and 5). > > * In requirement 6 (formerly 5), explained what we mean > by "easy handoff of sessions": avoid TCP session breakage > and packet loss, when possible. > > * 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. > > * Added new requirement 9 around manageability. > > * Added new requirement 10 around cross-organization use. > > * Added new requirement 11 saying that administrators should > be able to limit topologies for security and other reasons. > > * Fixed typos and other minor wording issues. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec **************************************************************************= ** 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 yaronf.ietf@gmail.com Wed Oct 17 07:52: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 4583821F86CA for ; Wed, 17 Oct 2012 07:52:37 -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 oEGhHbo1GVpt for ; Wed, 17 Oct 2012 07:52:36 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE7221F86A4 for ; Wed, 17 Oct 2012 07:52:36 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so5745134lam.31 for ; Wed, 17 Oct 2012 07:52:35 -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=Qrk1hySwGMo6YQrElFP8QlDIbAiUpYzo9ldeca179Sw=; b=uC64dr+hCtC8t0qvipDpuGwT9RvJ2I21xTfZLcAApo3P+1HGUzXmPDRlZjofowwEFj PajpSHkfc7DU3tARpbPvu42R748/4VB4S/AKSIeWJN8WpUcIUDggDVrSP7eYiQ4XjHZL zDi7tUAs+Ih9z+kYQTP2AwDoesPgkMiG6C95eBYA5bVUcIKC4DGwlvKUTFt/HmleWOfw jXyHwvRLlwSOKJiTfDkH25ap+JsB1LCsMa+YyLHVyEon/HMbLllTm91W/+jObbOWMU6Y HPWuoNAKR2qYMdkKzzlNz2C3994Zb9mDClNBDtWYNypovq9MvyXSvyIFyOcDQa+b7Vgb ytRw== Received: by 10.152.105.68 with SMTP id gk4mr15763358lab.48.1350485555298; Wed, 17 Oct 2012 07:52:35 -0700 (PDT) Received: from [10.0.0.13] ([89.139.31.225]) by mx.google.com with ESMTPS id x5sm6684947lbf.9.2012.10.17.07.52.33 (version=SSLv3 cipher=OTHER); Wed, 17 Oct 2012 07:52:34 -0700 (PDT) Message-ID: <507EC630.3080403@gmail.com> Date: Wed, 17 Oct 2012 16:52:32 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 14:52:37 -0000 A quick correction: the latest version of the now-finished draft has been renamed draft-ietf-ipsecme-ad-vpn-problem ("auto-discovery VPN", http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-00). Thanks, Yaron On 10/17/2012 04:38 PM, Paul Hoffman wrote: > Greetings again. We have a 2-hour time slot in Atlanta, which is way more than we asked for. We don't need to be talking about draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and is being sent to the AD for review. This is a call for agenda items. Strong preference is given to those which are in the WG charter. > > draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and hopefully there will be more discussion of it before the meeting > > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From paul.hoffman@vpnc.org Wed Oct 17 07:54:59 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C8F21F86E3 for ; Wed, 17 Oct 2012 07:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 pQSpxcoqwIND for ; Wed, 17 Oct 2012 07:54:59 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E219921F854A for ; Wed, 17 Oct 2012 07:54:58 -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 q9HEssOl076984 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Oct 2012 07:54:56 -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.2 \(1499\)) From: Paul Hoffman In-Reply-To: <507EC630.3080403@gmail.com> Date: Wed, 17 Oct 2012 07:54:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <382047F6-86F6-45A9-9460-888E90321243@vpnc.org> References: <507EC630.3080403@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1499) Cc: IPsecme WG Subject: Re: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 14:54:59 -0000 On Oct 17, 2012, at 7:52 AM, Yaron Sheffer = wrote: > A quick correction: the latest version of the now-finished draft has = been renamed draft-ietf-ipsecme-ad-vpn-problem ("auto-discovery VPN", = http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-00). Whoops, yes. An artifact of my sometimes-too-helpful personal document = tracking system.= From ynir@checkpoint.com Wed Oct 17 08:09: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 D360021F85EF for ; Wed, 17 Oct 2012 08:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 ie7UNqHL4MOZ for ; Wed, 17 Oct 2012 08:09:46 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id E24D821F85C4 for ; Wed, 17 Oct 2012 08:09:45 -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 q9HF9dsm004654; Wed, 17 Oct 2012 17:09:39 +0200 X-CheckPoint: {507EC86D-0-1B221DC2-2FFFF} 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; Wed, 17 Oct 2012 17:09:38 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 17 Oct 2012 17:09:38 +0200 From: Yoav Nir To: Paul Hoffman Date: Wed, 17 Oct 2012 17:09:42 +0200 Thread-Topic: [IPsec] Call for agenda items Thread-Index: Ac2seWzkCVWDxcV5Td6xTZ+dnx278A== Message-ID: <00399372-3BC9-4FF6-91C3-B83DF0D5AC49@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IPsecme WG Subject: Re: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:09:46 -0000 On Oct 17, 2012, at 4:38 PM, Paul Hoffman wrote: > Greetings again. We have a 2-hour time slot in Atlanta, which is way more= than we asked for. We don't need to be talking about draft-ietf-ipsecme-p2= p-vpn-problem because it's finished with WG LC and is being sent to the AD = for review.=20 Are we going to have a contest for a solution document, similar to the one = they had at httpbis? Yoav From paul.hoffman@vpnc.org Wed Oct 17 08:30:23 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BF721F8624 for ; Wed, 17 Oct 2012 08:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 bW6yww2fRvqf for ; Wed, 17 Oct 2012 08:30:23 -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 E409A21F85D5 for ; Wed, 17 Oct 2012 08:30:22 -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 q9HFUC8D078420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 17 Oct 2012 08:30:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <00399372-3BC9-4FF6-91C3-B83DF0D5AC49@checkpoint.com> Date: Wed, 17 Oct 2012 08:30:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <99E849A7-E146-44AD-8087-F0C0A392963B@vpnc.org> References: <00399372-3BC9-4FF6-91C3-B83DF0D5AC49@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1499) Cc: IPsecme WG Subject: Re: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:30:23 -0000 On Oct 17, 2012, at 8:09 AM, Yoav Nir wrote: > Are we going to have a contest for a solution document, similar to the = one they had at httpbis? Not in Atlanta, no, but maybe afterwards. To the best of my = understanding, none of the proposals that we heard earlier have updated = their drafts to say how they cover or don't cover what's in the = requirements and scenarios document. --Paul Hoffman= From vishwas.ietf@gmail.com Wed Oct 17 09:51:43 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCDC21F8639 for ; Wed, 17 Oct 2012 09:51:43 -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 7SwNhEak61o5 for ; Wed, 17 Oct 2012 09:51:41 -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 49A2121F8634 for ; Wed, 17 Oct 2012 09:51:41 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so5909229lbo.31 for ; Wed, 17 Oct 2012 09:51:40 -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=V4mxX9BEzYwPe1As11YpFoeHxxlKG6wS9SQuaA6C3q0=; b=zt2YP37xCfEWyCUUymzVbbeHxD9H4Z2xFX9ojV1FRGyF6B/AmubMC9YXnGTSGoyX8T b8/PMOEkOBaUqu5iGMRqmCo1Q5rCbJi8ztioidcqsU9pG+nB7mL5yyiXx1r1naT+ofu2 wb0FWG3S+2Vq/es9R1n1WQ4QWAcuI9y8ACtH1FOgHKwsoQyfP2yylACWxbXzJfhHntB0 zGLxE4nlBcHIyhi6IPQDVy5gDokawus6Q9dKxoSTcGuL1hh8KJ+A/ytukH/NCw2HAosD 6z73yu76dVvyqWkRv6oZ7nEDC7eRyxA5INZrMYeVVXcA/qgSZ+T66prPpA7YUg1IVVWf G+GQ== MIME-Version: 1.0 Received: by 10.152.105.135 with SMTP id gm7mr16345380lab.22.1350492700126; Wed, 17 Oct 2012 09:51:40 -0700 (PDT) Received: by 10.114.75.110 with HTTP; Wed, 17 Oct 2012 09:51:40 -0700 (PDT) In-Reply-To: <20549DD10769DA47A86F0F0FAF8012DD03955054E2@PIACHEVEX00.GCHQ.GOV.UK> References: <4DA36DEB-EDBE-4C18-8DE0-EEC652A16162@vpnc.org> <20549DD10769DA47A86F0F0FAF8012DD03955054E2@PIACHEVEX00.GCHQ.GOV.UK> Date: Wed, 17 Oct 2012 09:51:40 -0700 Message-ID: From: Vishwas Manral To: "Ulliott, Chris" Content-Type: multipart/alternative; boundary=f46d040711c5a9aede04cc441573 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: Wed, 17 Oct 2012 16:51:43 -0000 --f46d040711c5a9aede04cc441573 Content-Type: text/plain; charset=ISO-8859-1 Hi Chris, Thanks a lot for your comments, my points inline: On Wed, Oct 17, 2012 at 7:47 AM, Ulliott, Chris < Chris.Ulliott@cesg.gsi.gov.uk> wrote: > Apologies for the delay in replying... > > I think the Gateway to gateway use case (para 2.2) doesn't cover the > problem I'm suffering. What if the use case was reworded such that it says > something along the lines of: > > -- start -- > > A typical Enterprise traffic model is hub and spoke, with the gateways > connecting to each other using IPsec tunnels. > > However for the voice and other rich media traffic that occupies a lot of > bandwidth or is performance sensative, the traffic tromboning to the hub > can create traffic bottlenecks on the hub and can lead to an increase in > cost. A fully meshed solution is would make best use of the available > network capacity and performance but the deployment of a fully meshed > solution involves considerable configuration, especially when a large > number of nodes are involved. For the reasons of cost and manual error > reduction, it is desired that there be minimal configuration on each > gateway. VM> I agree adding the point of Full mesh having more configuration is an issue and will add it to the text. However another issue we see is that in a Full Mesh we need connectivity between all nodes which means that the weakest link is the Branch device, that is another reason we have a hub and spoke with the mesh cross connections on demand. It is highly desirable that the solution works where the endpoints are administrated by separate management domains, albeit, ones that have an existing trust relationship (for example two organisations who are collaborating on a project, they may wish to join their networks, whilst retaining independent control over configuration) VM> I agree we should state this in the requirement explicitly and is critical to the solution. When two gateways communicate, they must use a mechanism for authentication, such that they do not expose themselves to the risk of impersonation by the other entities. VM> Sounds good. -- end -- In section 3.2, it would be nice if we could again mention that rather looking for a solution that makes a star architecture work, actually enables a dynamic, fully meshed solution to be practical. VM> Agree.We call it star with temporary mesh connection, I agree we can call it dynamic mesh connectivity instead. In section 4.1, there are comments about minimising the configuration changes... should we word this a bit stronger and say that after initial configuration, there should be no need for a manual configuration change as devices (endpoint or gateways) are added, removed or changed? VM> I am ok with that, my point was we need to configure profiles when a device is added, we do not need to reconfigure if we find devices of the same profile. For the use case where end points need to find the optimum gateway to connect to, do we need a requirement that enables an endpoint to identify which is the best gateway to connect to, the nearest may not be the best, depending on the network cost behind the gateway... but this may be complicating the problem too much. VM> I think the problem of network cost is that of routing. We need a way for policy to determine when to transfer a connection from one gateway to another. The solution should allow for such signalling though. Thoughts? VM> Great comments, which I can see come from real world usecases. Thanks, Vishwas Chris > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Saturday, September 08, 2012 5: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 > 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 > > > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem > > > > A summary of the changes in this version is included at > > the end of this message. > > > > Please review this document and provide any comments on > > the existing requirements or suggestions for new ones. > > > > 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. > > > > Thanks, > > > > Steve > > > > ------------ > > > > Summary of Changes in draft-ietf-ipsecme-ad-vpn-00.txt > > > > * Changed draft name from p2p-vpn to ad-vpn. > > > > * Added a paragraph for each requirement, explaining how > > that requirement is driven by the use cases. > > > > * In requirement 1, defined what we mean by minimizing > > configuration changes. > > > > * 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. > > > > * Split requirement 4 into two requirements (now 4 and 5). > > > > * In requirement 6 (formerly 5), explained what we mean > > by "easy handoff of sessions": avoid TCP session breakage > > and packet loss, when possible. > > > > * 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. > > > > * Added new requirement 9 around manageability. > > > > * Added new requirement 10 around cross-organization use. > > > > * Added new requirement 11 saying that administrators should > > be able to limit topologies for security and other reasons. > > > > * Fixed typos and other minor wording issues. > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > **************************************************************************** > Communications with GCHQ may be monitored and/or recorded > for system efficiency and other lawful purposes. Any views or > opinions expressed in this e-mail do not necessarily reflect GCHQ > policy. This email, and any attachments, is intended for the > attention of the addressee(s) only. Its unauthorised use, > disclosure, storage or copying is not permitted. If you are not the > intended recipient, please notify postmaster@gchq.gsi.gov.uk. > > This information is exempt from disclosure under the Freedom of > Information Act 2000 and may be subject to exemption under > other UK information legislation. Refer disclosure requests to > 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 > Secure Intranet virus scanning service supplied by Cable&Wireless Worldwide > in partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) On > leaving the GSi this email was certified virus free. > Communications via the GSi may be automatically logged, monitored and/or > recorded for legal purposes. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --f46d040711c5a9aede04cc441573 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Chris,
=A0
Thanks a lot for your comments, my points inline:
=A0
On Wed, Oct 17, 2012 at 7:47 AM, Ulliott, Chris = <Chris.Ulliott@cesg.gsi.gov.uk> wrote:
Apologies for the delay in replying..= .

I think the Gateway to gateway use case (para 2.2) doesn't cov= er the problem I'm suffering. =A0What if the use case was reworded such= that it says something along the lines of:

-- start --

A typical Enterprise traffic model is hub and spoke,= with the gateways connecting to each other using IPsec tunnels.

How= ever for the voice and other rich media traffic that occupies a lot of band= width or is performance sensative, the traffic tromboning to the hub can cr= eate traffic bottlenecks on the hub and can lead to an increase in cost. = =A0A fully meshed solution is would make best use of the available network = capacity and performance but the deployment of a fully meshed solution invo= lves considerable configuration, especially when a large number of nodes ar= e involved. =A0For the reasons of cost and manual error reduction, it is de= sired that there be minimal configuration on each gateway.
VM> I agree adding the point of Full mesh having more configuration= is an issue and will add it to the text. However another issue we see is t= hat in a Full Mesh we need connectivity between all nodes which means that = the weakest link is the Branch device, that is another reason we have=A0a h= ub and spoke with the mesh cross connections on demand.

It is highly desirable that the solution works where the endpoints= are administrated by separate management domains, albeit, ones that have a= n existing trust relationship (for example two organisations who are collab= orating on a project, they may wish to join their networks, whilst retainin= g independent control over configuration)
VM> I agree we should state this in the requirement explicitly and is cr= itical to the solution.

When two gateways communicate, they must use a mechanism for authe= ntication, such that they do not expose themselves to the risk of impersona= tion by the other entities.
VM> Sounds good.

-- end --

In section 3.2, it would be nice if we could agai= n mention that rather looking for a solution that makes a star architecture= work, actually enables a dynamic, fully meshed solution to be practical. VM> Agree.We call it star with temporary mesh connection, I agree we can= call it dynamic mesh connectivity instead.

In section 4.1, there are comments about minimising the configurat= ion changes... should we word this a bit stronger and say that after initia= l configuration, there should be no need for a manual configuration change = as devices (endpoint or gateways) are added, removed or changed?
VM> I am ok with that, my point was we need to configure profiles when a= device is added, we do not need to reconfigure if we find devices of the s= ame profile.

For the use case where end points need to find the optimum gateway= to connect to, do we need a requirement that enables an endpoint to identi= fy which is the best gateway to connect to, the nearest may not be the best= , depending on the network cost behind the gateway... but this may be compl= icating the problem too much.
VM> I think the problem of network cost is that of routing. We need a wa= y for policy to determine when to transfer a connection from one gateway to= another. The solution should allow for such signalling though.

Thoughts?
VM> Great comments, which I can see come from real= world usecases.
=A0
Thanks,
Vishwas
Chris

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Ho= ffman
Sent: Saturday, September 08, 2012 5:31 PM
To: IPsecme WG
Subject: [I= Psec] STRONG NUDGE: Revised AD VPN Requirements

This appeared on the= list over two weeks ago and it has received no comments since. This is sup= posed to be the WG's main work item, folks.

--Paul Hoffman

On Aug 23, 2012, at 9:02 AM, Stephen Hanna <shanna@juniper.net> 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 em= ail discussions. The new version is available at
>
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-prob= lem
>
> A summary of the changes in this version is included at
>= ; the end of this message.
>
> Please review this document and = provide any comments on
> the existing requirements or suggestions fo= r new ones.
>
> For requirement 3, Vishwas will be starting an email
> t= hread soon so that the WG can discuss what this text
> means, whether= we want to keep it, and how it can be
> made clearer.
>
> Thanks,
>
> Steve
>
> ------------
>
= > Summary of Changes in draft-ietf-ipsecme-ad-vpn-00.txt
>
>= * Changed draft name from p2p-vpn to ad-vpn.
>
> * Added a par= agraph for each requirement, explaining how
> =A0that requirement is driven by the use cases.
>
> * In r= equirement 1, defined what we mean by minimizing
> =A0configuration c= hanges.
>
> * In requirement 2, explained that this requirement= implies
> =A0that SPD entries and other configuration based on peer
> =A0I= P address will need to be automatically updated when
> =A0the peer= 9;s IP address changes.
>
> * Split requirement 4 into two requ= irements (now 4 and 5).
>
> * In requirement 6 (formerly 5), explained what we mean
>= ; =A0by "easy handoff of sessions": avoid TCP session breakage> =A0and packet loss, when possible.
>
> * In requirement 8= (formerly 7), acknowledged the difficulty
> =A0of handling cases where gateways are behind NATs or where
> = =A0two endpoints are both behind separate NATs. In those cases,
> =A0= we may need to use workarounds such as port forwarding by
> =A0the NA= Ts or falling back to a hub and spoke architecture.
>
> * Added new requirement 9 around manageability.
>
>= ; * Added new requirement 10 around cross-organization use.
>
>= * Added new requirement 11 saying that administrators should
> =A0be= able to limit topologies for security and other reasons.
>
> * Fixed typos and other minor wording issues.
>
> = _______________________________________________
> IPsec mailing list<= br>> IPsec@ietf.org
> https:/= /www.ietf.org/mailman/listinfo/ipsec
>

_______________________________________________
IPsec mailin= g list
IPsec@ietf.org
https://= www.ietf.org/mailman/listinfo/ipsec

***********************************************************= *****************
Communications with GCHQ may be monitored and/or recor= ded
for system efficiency and other lawful purposes. Any views or
opinions expressed in this e-mail do not necessarily reflect GCHQ
policy= . =A0This email, and any attachments, is intended for the
attention of t= he addressee(s) only. Its unauthorised use,
disclosure, storage or copyi= ng is not permitted. =A0If you are not the
intended recipient, please notify postmaster@gchq.gsi.gov.uk.

This information is exempt from= disclosure under the Freedom of
Information Act 2000 and may be subject= to exemption under
other UK information legislation. Refer disclosure requests to
GCHQ on 0= 1242 221491 ext 30306 (non-secure) or email
infoleg@gchq.gsi.gov.uk

*************************= ***************************************************


The original of this email was scanned for viruses by the Governmen= t Secure Intranet virus scanning service supplied by Cable&Wireless Wor= ldwide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/00= 52.) On leaving the GSi this email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or re= corded for legal purposes.
_______________________________________________
IPsec = mailing list
IPsec@ietf.org
http= s://www.ietf.org/mailman/listinfo/ipsec

--f46d040711c5a9aede04cc441573-- From dbrownhi@cisco.com Wed Oct 17 11:36:20 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F07221F8618 for ; Wed, 17 Oct 2012 11:36:20 -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 DFAQvrRxjexr for ; Wed, 17 Oct 2012 11:36:19 -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 5898121F8629 for ; Wed, 17 Oct 2012 11:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1816; q=dns/txt; s=iport; t=1350498979; x=1351708579; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=oht5lbT0jma0EB2mV3zuivgQ1LZtSG0yoh/d6VenRQM=; b=FeUQS6a7V7Klmux0Lp673DdrcXxGN8D5FZTUR1Ou49WDiveNEFWFw/ue Hhqvjbck7svyfT04BSp9BPYlHZQ0U984fyRR88RQf8mM8HTYOjjm78Nn/ G4/9C6Zw20o7EB3oqxiJJrhMzGxrkiI76pTC86xTWEyySnOmBX/tGrD8n s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALn5flCtJV2Z/2dsb2JhbABFwCaBCIIgAQEBBAEBAQ8BJzQXBAIBCA4DBAEBCxQJBycLFAkIAgQBEggBGYdiC5tSoCmLWIViYAOXAI00gWuCb4IX X-IronPort-AV: E=Sophos;i="4.80,602,1344211200"; d="scan'208";a="129701217" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 17 Oct 2012 18:36:19 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9HIaIvT018622 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Oct 2012 18:36:18 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 13:36:18 -0500 From: "David Brownhill (dbrownhi)" To: Dan Harkins , "ipsec@ietf.org" Thread-Topic: [IPsec] New I-D on IKEv3 Thread-Index: AQHNqM2osFbHjGi3cUeSprbHov6lCJe92o6A Date: Wed, 17 Oct 2012 18:36:17 +0000 Message-ID: References: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> In-Reply-To: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.64.193] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--22.593600-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 Subject: Re: [IPsec] New I-D on IKEv3 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, 17 Oct 2012 18:36:20 -0000 Hi Dan, The lack or EAP authentication would be a non-starter for us to implement t= his in our remote access VPN client. Why not support EAP authentication? Regards, David -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of D= an Harkins Sent: Friday, October 12, 2012 7:02 PM To: ipsec@ietf.org Subject: [IPsec] New I-D on IKEv3 Hello, I just submitted a new I-D that defines version 3 of IKE. The goals of th= is draft are to make a more easily understood, and simpler protocol that ha= s a high degree of probability of achieving interoperability. It should be = easier to read, easier to understand, and easier to implement. To those ends it: - severely limits the negotiable parameters and options - no long-term IKE SA, it's one and done - has a simple state machine which, if followed, should ensure the implementation interoperates with other implementations - is a true peer-to-peer protocol Please take a look and send me your comments! If you plan on implementing= this protocol then definitely contact me, I want to interoperate with you. regards, Dan. ----------------------------------------------------------- Filename: draft-harkins-ikev3 Revision: 00 Title: The (Real) Internet Key Exchange Creation date: 2012-10-12 WG ID: Individual Submission Number of pages: 41 URL: =20 http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt Status: http://datatracker.ietf.org/doc/draft-harkins-ikev3 Htmlized: http://tools.ietf.org/html/draft-harkins-ikev3-00 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Wed Oct 17 11:52:33 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332B521F86AD for ; Wed, 17 Oct 2012 11:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.577 X-Spam-Level: X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGc9x1NHhu2E for ; Wed, 17 Oct 2012 11:52:30 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3B77421F869E for ; Wed, 17 Oct 2012 11:52:29 -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 q9HIqMru026506; Wed, 17 Oct 2012 20:52:22 +0200 X-CheckPoint: {507EFC9E-8-1B221DC2-2FFFF} 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; Wed, 17 Oct 2012 20:52:21 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 17 Oct 2012 20:52:22 +0200 From: Yoav Nir To: "David Brownhill (dbrownhi)" Date: Wed, 17 Oct 2012 20:52:21 +0200 Thread-Topic: [IPsec] New I-D on IKEv3 Thread-Index: Ac2smIn1Kv0X4cCOQFaTfnqPDg8mGg== Message-ID: References: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" , Dan Harkins Subject: Re: [IPsec] New I-D on IKEv3 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, 17 Oct 2012 18:52:33 -0000 Add a CFG payload to the list. By the time we add all the things that we feel must be in an IKEv3, would i= t be any simpler than IKEv2? Yoav On Oct 17, 2012, at 8:36 PM, David Brownhill (dbrownhi) wrote: > Hi Dan, >=20 > The lack or EAP authentication would be a non-starter for us to implement= this in our remote access VPN client. Why not support EAP authentication? >=20 > Regards, > David >=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of= Dan Harkins > Sent: Friday, October 12, 2012 7:02 PM > To: ipsec@ietf.org > Subject: [IPsec] New I-D on IKEv3 >=20 >=20 > Hello, >=20 > I just submitted a new I-D that defines version 3 of IKE. The goals of t= his draft are to make a more easily understood, and simpler protocol that h= as a high degree of probability of achieving interoperability. It should be= easier to read, easier to understand, and easier to implement. > To those ends it: >=20 > - severely limits the negotiable parameters and options > - no long-term IKE SA, it's one and done > - has a simple state machine which, if followed, should ensure the > implementation interoperates with other implementations > - is a true peer-to-peer protocol >=20 > Please take a look and send me your comments! If you plan on implementin= g this protocol then definitely contact me, I want to interoperate with you= . >=20 > regards, >=20 > Dan. >=20 > ----------------------------------------------------------- >=20 > Filename: draft-harkins-ikev3 > Revision: 00 > Title: The (Real) Internet Key Exchange > Creation date: 2012-10-12 > WG ID: Individual Submission > Number of pages: 41 > URL: =20 > http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt > Status: http://datatracker.ietf.org/doc/draft-harkins-ikev3 > Htmlized: http://tools.ietf.org/html/draft-harkins-ikev3-00 >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From dharkins@lounge.org Wed Oct 17 17:26:54 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7015921F8534 for ; Wed, 17 Oct 2012 17:26:54 -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 LoOoZ9Ps5J6n for ; Wed, 17 Oct 2012 17:26:54 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E383521F8532 for ; Wed, 17 Oct 2012 17:26:53 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9E3E710224008; Wed, 17 Oct 2012 17:26:45 -0700 (PDT) Received: from 115.125.248.113 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 17 Oct 2012 17:26:45 -0700 (PDT) Message-ID: In-Reply-To: References: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> Date: Wed, 17 Oct 2012 17:26:45 -0700 (PDT) From: "Dan Harkins" To: "David Brownhill (dbrownhi)" 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" , Dan Harkins Subject: Re: [IPsec] New I-D on IKEv3 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, 18 Oct 2012 00:26:54 -0000 Hi David, On Wed, October 17, 2012 11:36 am, David Brownhill (dbrownhi) wrote: > Hi Dan, > > The lack or EAP authentication would be a non-starter for us to implement > this in our remote access VPN client. Why not support EAP authentication? What credential are you interested in using with EAP? Dan. > Regards, > David > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Dan Harkins > Sent: Friday, October 12, 2012 7:02 PM > To: ipsec@ietf.org > Subject: [IPsec] New I-D on IKEv3 > > > Hello, > > I just submitted a new I-D that defines version 3 of IKE. The goals of > this draft are to make a more easily understood, and simpler protocol > that has a high degree of probability of achieving interoperability. It > should be easier to read, easier to understand, and easier to implement. > To those ends it: > > - severely limits the negotiable parameters and options > - no long-term IKE SA, it's one and done > - has a simple state machine which, if followed, should ensure the > implementation interoperates with other implementations > - is a true peer-to-peer protocol > > Please take a look and send me your comments! If you plan on > implementing this protocol then definitely contact me, I want to > interoperate with you. > > regards, > > Dan. > > ----------------------------------------------------------- > > Filename: draft-harkins-ikev3 > Revision: 00 > Title: The (Real) Internet Key Exchange > Creation date: 2012-10-12 > WG ID: Individual Submission > Number of pages: 41 > URL: > http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt > Status: http://datatracker.ietf.org/doc/draft-harkins-ikev3 > Htmlized: http://tools.ietf.org/html/draft-harkins-ikev3-00 > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dharkins@lounge.org Wed Oct 17 17:28: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 0953E21F854A for ; Wed, 17 Oct 2012 17:28:25 -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 lthJ2YUN43A9 for ; Wed, 17 Oct 2012 17:28:24 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 61B3921F853B for ; Wed, 17 Oct 2012 17:28:24 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 039FE10224008; Wed, 17 Oct 2012 17:28:24 -0700 (PDT) Received: from 115.125.248.113 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 17 Oct 2012 17:28:24 -0700 (PDT) Message-ID: <036482e7d1b801a85abe19571cf7ee36.squirrel@www.trepanning.net> In-Reply-To: References: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> Date: Wed, 17 Oct 2012 17:28:24 -0700 (PDT) From: "Dan Harkins" To: "Yoav Nir" 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" , Dan Harkins , David Brownhill Subject: Re: [IPsec] New I-D on IKEv3 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, 18 Oct 2012 00:28:25 -0000 Hi Yoav, On Wed, October 17, 2012 11:52 am, Yoav Nir wrote: > Add a CFG payload to the list. Already noted! CFG and NAT indication. > By the time we add all the things that we feel must be in an IKEv3, would > it be any simpler than IKEv2? Yes, I believe so. Simpler, more clear, and easier to implement with a high degree of interoperability. Dan. > Yoav > > On Oct 17, 2012, at 8:36 PM, David Brownhill (dbrownhi) wrote: > >> Hi Dan, >> >> The lack or EAP authentication would be a non-starter for us to >> implement this in our remote access VPN client. Why not support EAP >> authentication? >> >> Regards, >> David >> >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Dan Harkins >> Sent: Friday, October 12, 2012 7:02 PM >> To: ipsec@ietf.org >> Subject: [IPsec] New I-D on IKEv3 >> >> >> Hello, >> >> I just submitted a new I-D that defines version 3 of IKE. The goals of >> this draft are to make a more easily understood, and simpler protocol >> that has a high degree of probability of achieving interoperability. It >> should be easier to read, easier to understand, and easier to >> implement. >> To those ends it: >> >> - severely limits the negotiable parameters and options >> - no long-term IKE SA, it's one and done >> - has a simple state machine which, if followed, should ensure the >> implementation interoperates with other implementations >> - is a true peer-to-peer protocol >> >> Please take a look and send me your comments! If you plan on >> implementing this protocol then definitely contact me, I want to >> interoperate with you. >> >> regards, >> >> Dan. >> >> ----------------------------------------------------------- >> >> Filename: draft-harkins-ikev3 >> Revision: 00 >> Title: The (Real) Internet Key Exchange >> Creation date: 2012-10-12 >> WG ID: Individual Submission >> Number of pages: 41 >> URL: >> http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt >> Status: http://datatracker.ietf.org/doc/draft-harkins-ikev3 >> Htmlized: http://tools.ietf.org/html/draft-harkins-ikev3-00 >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dharkins@lounge.org Wed Oct 17 17:32: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 1C26721F8610 for ; Wed, 17 Oct 2012 17:32:16 -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 zyU+7a3BE5n3 for ; Wed, 17 Oct 2012 17:32:15 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A537021F8557 for ; Wed, 17 Oct 2012 17:32:15 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2A2CA10224008; Wed, 17 Oct 2012 17:32:15 -0700 (PDT) Received: from 115.125.248.113 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 17 Oct 2012 17:32:15 -0700 (PDT) Message-ID: <4877f6a502ed7435b2d0d357431d6ba4.squirrel@www.trepanning.net> In-Reply-To: References: Date: Wed, 17 Oct 2012 17:32:15 -0700 (PDT) From: "Dan Harkins" To: "Paul Hoffman" 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: IPsecme WG Subject: Re: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 00:32:16 -0000 On Wed, October 17, 2012 7:38 am, Paul Hoffman wrote: > Greetings again. We have a 2-hour time slot in Atlanta, which is way more > than we asked for. We don't need to be talking about > draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and is > being sent to the AD for review. This is a call for agenda items. Strong > preference is given to those which are in the WG charter. I would be happy to discuss IKEv3. Please let me know if you'll put me on the agenda and I'll prepare some slides to talk to. Dan. > draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and hopefully > there will be more discussion of it before the meeting > > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From ynir@checkpoint.com Wed Oct 17 23: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 BD27C21F85AC for ; Wed, 17 Oct 2012 23:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.58 X-Spam-Level: X-Spam-Status: No, score=-10.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 b5cSHdD6P8kj for ; Wed, 17 Oct 2012 23:19:05 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C977521F8599 for ; Wed, 17 Oct 2012 23:19:04 -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 q9I6IvvE020346; Thu, 18 Oct 2012 08:18:57 +0200 X-CheckPoint: {507F9D84-0-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 18 Oct 2012 08:18:56 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 18 Oct 2012 08:18:57 +0200 From: Yoav Nir To: Dan Harkins Date: Thu, 18 Oct 2012 08:18:55 +0200 Thread-Topic: [IPsec] New I-D on IKEv3 Thread-Index: Ac2s+HO3RL5a/25uQFCay/20vUuRJA== Message-ID: References: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" , "David Brownhill \(dbrownhi\)" Subject: Re: [IPsec] New I-D on IKEv3 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, 18 Oct 2012 06:19:05 -0000 On Oct 18, 2012, at 2:26 AM, Dan Harkins wrote: >=20 > Hi David, >=20 > On Wed, October 17, 2012 11:36 am, David Brownhill (dbrownhi) wrote: >> Hi Dan, >>=20 >> The lack or EAP authentication would be a non-starter for us to implemen= t >> this in our remote access VPN client. Why not support EAP authenticatio= n? >=20 > What credential are you interested in using with EAP? I'm not David, but with remote access VPN into an enterprise network, it's = usually the passwords stored on the directory they are using. These directo= ry servers support EAP over RADIUS or DIAMETER to the VPN gateway. The PSK = method in the draft requires the VPN gateway to know the password (or a has= h thereof). EAP (even EAP-dragonfly) doesn't. Yoav From dbrownhi@cisco.com Thu Oct 18 05:50:55 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372E521F87D6 for ; Thu, 18 Oct 2012 05:50:54 -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 oSkbyYXCGGXa for ; Thu, 18 Oct 2012 05:50:53 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 276A321F87A9 for ; Thu, 18 Oct 2012 05:50:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2472; q=dns/txt; s=iport; t=1350564653; x=1351774253; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=i9Oh3qojE03bonV6NmmDuLDRFOQsRFU3aAk0EqKS5X0=; b=ZMg83p/z6NT9OPTrEeg9m4tEE3Cu0zB2W4Vx9lxyVPwlzJLIP0F9qbZ1 Kt/zrcI1+pjpUhTgdmZe48vo6fLE+1TTPyuiXY1msoBRjOMPmeKrZPjpr eRDTsN2GT39ScCdtiRmfQ1MJxIZpUGK5L1ri5TRAAQZ78ZNSYXDtUzNGP 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOb5f1CtJV2Z/2dsb2JhbABFwD2BCIIgAQEBAwEBAQEPASc0CwUHBAIBCA4DBAEBAQoOBgkHJwsUCQgCBA4FCAEZh1wGC5wzoCyLWIMhgkFgA5cAjTSBa4Jvghc X-IronPort-AV: E=Sophos;i="4.80,607,1344211200"; d="scan'208";a="132992309" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 18 Oct 2012 12:50:52 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9ICoqCp012801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Oct 2012 12:50:52 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Thu, 18 Oct 2012 07:50:52 -0500 From: "David Brownhill (dbrownhi)" To: Dan Harkins Thread-Topic: [IPsec] New I-D on IKEv3 Thread-Index: AQHNqM2osFbHjGi3cUeSprbHov6lCJe92o6AgAC2KoCAAHossA== Date: Thu, 18 Oct 2012 12:50:51 +0000 Message-ID: References: <4f4e246af91b6850545df86389648eb3.squirrel@www.trepanning.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.64.193] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19284.002 x-tm-as-result: No--35.950400-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: "ipsec@ietf.org" Subject: Re: [IPsec] New I-D on IKEv3 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, 18 Oct 2012 12:50:55 -0000 Hi Dan, The most common credentials that our customers use are username/password (i= ncluding variants such as one-time passwords) and there are others. David -----Original Message----- From: Dan Harkins [mailto:dharkins@lounge.org]=20 Sent: Wednesday, October 17, 2012 8:27 PM To: David Brownhill (dbrownhi) Cc: Dan Harkins; ipsec@ietf.org Subject: RE: [IPsec] New I-D on IKEv3 Hi David, On Wed, October 17, 2012 11:36 am, David Brownhill (dbrownhi) wrote: > Hi Dan, > > The lack or EAP authentication would be a non-starter for us to=20 > implement this in our remote access VPN client. Why not support EAP auth= entication? What credential are you interested in using with EAP? Dan. > Regards, > David > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf=20 > Of Dan Harkins > Sent: Friday, October 12, 2012 7:02 PM > To: ipsec@ietf.org > Subject: [IPsec] New I-D on IKEv3 > > > Hello, > > I just submitted a new I-D that defines version 3 of IKE. The goals=20 > of this draft are to make a more easily understood, and simpler=20 > protocol that has a high degree of probability of achieving=20 > interoperability. It should be easier to read, easier to understand, and = easier to implement. > To those ends it: > > - severely limits the negotiable parameters and options > - no long-term IKE SA, it's one and done > - has a simple state machine which, if followed, should ensure the > implementation interoperates with other implementations > - is a true peer-to-peer protocol > > Please take a look and send me your comments! If you plan on=20 > implementing this protocol then definitely contact me, I want to=20 > interoperate with you. > > regards, > > Dan. > > ----------------------------------------------------------- > > Filename: draft-harkins-ikev3 > Revision: 00 > Title: The (Real) Internet Key Exchange > Creation date: 2012-10-12 > WG ID: Individual Submission > Number of pages: 41 > URL: > http://www.ietf.org/internet-drafts/draft-harkins-ikev3-00.txt > Status: http://datatracker.ietf.org/doc/draft-harkins-ikev3 > Htmlized: http://tools.ietf.org/html/draft-harkins-ikev3-00 > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kivinen@iki.fi Thu Oct 18 06:31:14 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2128C21F876A for ; Thu, 18 Oct 2012 06:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 TUSnh40B+gdJ for ; Thu, 18 Oct 2012 06:31:13 -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 4AFEE21F873C for ; Thu, 18 Oct 2012 06:31:12 -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 q9IDV8fu027979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 18 Oct 2012 16:31:08 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q9IDV6gu026698; Thu, 18 Oct 2012 16:31:06 +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: <20608.1178.765684.923417@fireball.kivinen.iki.fi> Date: Thu, 18 Oct 2012 16:31:06 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 10 min Cc: IPsecme WG Subject: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 13:31:14 -0000 Paul Hoffman writes: > Greetings again. We have a 2-hour time slot in Atlanta, which is way > more than we asked for. We don't need to be talking about > draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC > and is being sent to the AD for review. This is a call for agenda > items. Strong preference is given to those which are in the WG > charter. draft-ietf-ipsecme-p2p-vpn-problem? I assume you mean draft-ietf-ipsecme-ad-vpn-problem-00? I did send quite a lot of comments to the draft at 2012-09-10, and I have not seen those taken into the draft yet. Also as I noted in my email I am quite sure we are still missing some requirements, but as the current document is bit hard to read with the terminology of different nodes, hubs, endpoints etc so it is bit hard to understand if all requirements are there or not. http://www.ietf.org/mail-archive/web/ipsec/current/msg07910.html http://www.ietf.org/mail-archive/web/ipsec/current/msg07914.html I myself do think that the draft-ietf-ipsecme-ad-vpn-problem-00 is NOT yet ready, I have been waiting for the next version of the document before rereading it. > draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and > hopefully there will be more discussion of it before the meeting My draft-kivinen-ipsecme-ikev2-minimal-01 will be moving to the lwig WG, so there is no need to discuss it here, and the draft-kivinen-ipsecme-oob-pubkey-01 would need the straw poll of which option we are going to do and we need to do that on the email list anyways, so there is no point of discussing that in the meeting (unless people are unsure what the options are, and what they mean). -- kivinen@iki.fi From turners@ieca.com Thu Oct 18 07:58:07 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB1021F87CC for ; Thu, 18 Oct 2012 07:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.173 X-Spam-Level: X-Spam-Status: No, score=-102.173 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, 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 eSzbYDJH-c9w for ; Thu, 18 Oct 2012 07:58:06 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.44.25]) by ietfa.amsl.com (Postfix) with ESMTP id CB21421F86FC for ; Thu, 18 Oct 2012 07:58:06 -0700 (PDT) Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id 83C064329AC99; Thu, 18 Oct 2012 09:58:08 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id 758724329AC62 for ; Thu, 18 Oct 2012 09:58:08 -0500 (CDT) Received: from [96.241.97.104] (port=62342 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TOrXx-0005PV-Ay; Thu, 18 Oct 2012 09:58:05 -0500 Message-ID: <508018FC.8020300@ieca.com> Date: Thu, 18 Oct 2012 10:58:04 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Dan Harkins References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> <507CA3B4.1070303@ieca.com> <6f873581eff8119db139416e44a0d0d2.squirrel@www.trepanning.net> In-Reply-To: <6f873581eff8119db139416e44a0d0d2.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.241.97.104]:62342 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= 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: Thu, 18 Oct 2012 14:58:07 -0000 Dan, There's not need to ask the IESG about the process to update the registry in question it's clear: RFC required. You can get an RFC through a WG, through an AD, or through the ISE. spt On 10/15/12 10:54 PM, Dan Harkins wrote: > > Hi Sean, > > On Mon, October 15, 2012 5:00 pm, Sean Turner wrote: >> >> On 10/12/12 2:32 AM, Dan Harkins wrote: >>> >>> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: >>>> >>>> I'm going to run my proposal and Michael's by the IESG on an informal >>>> telechat to see which one's got the best chance of getting through the >>>> process to resolve the IEEE's request. >>> >>> Can you ask the IESG to just do what it has done in the past? That >>> is, >>> just update the registry to include code points for new curves without >>> any bizarre notes or pointers? No fuss, no mess, just a few new rows >>> in a table. >>> >>> The worst that could happen if the IESG agrees to do that is that >>> someone >>> somewhere might use a brainpool curve with IKEv1. The odds are slim, >>> but they're not zero. And if that happens then so what? Really. So what? >> >> The RFC 5114 example wasn't published to address another SDO request for >> a code point so I don't think it's the same situation. > > That's certainly a distinction but I don't see how that matters. You > could also > note that RFC 5114 added MODP groups as well as ECP groups. Also a > distinction that really doesn't matter. > > Again, the SDO request is a _by-product_ of the opposition to just letting > Johannes' draft update the registry. It is this same opposition that is > creating > these problems about notes and pointers and the concern over whether they > will have the desired effect and what we should do to ensure they do. If this > opposition had not materialized there never would've been another SDO > request. > > It is the same situation, indulge me here a bit: > > What we had was another organization (NIST) came up with some new DH > groups and there was a proposal to add them to both IKEv1 and IKEv2 > registries. And now, quite similarly, there's another organization (the ECC > Brainpool) that came up with some new DH groups and there was a proposal > to add them to both IKEv1 and IKEv2 registries. > > When the proposal was made to add the NIST groups to the IKEv1 > registry there was no hullabaloo over updating a deprecated protocol's > registry and there was no concern that someone somewhere might use > the NIST groups with IKEv1. > > But when Johannes made his proposal to add the ECC Brainpool curves > to the IKEv1 registry there was all of a sudden a hullabaloo and much > concern that someone somewhere might use the ECC Brainpool groups > with IKEv1. > > So my request to you is to ask that the IESG consider what the process > defined for updating this registry is (it's RFC required) and to note that > there is precedence to update the registry of this deprecated protocol. > So please ask the IESG to just approve a draft (either Johannes' or mine) > for publication as an RFC to update this registry in the same manner that > RFC 5114 updated it (i.e. no notes, no pointers, no nonsense). > > Then there'd be no need for the IESG to have a discussion about the > (de)merits of notes and pointers in registries and how best to ensure that > no one nowhere ever even thinks about using an ECC Brainpool curve in > IKEv1 and that certainly sounds like a better use of everyone's time. > > regards, > > Dan. > > > From turners@ieca.com Thu Oct 18 09:12: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 B0FED21F8858 for ; Thu, 18 Oct 2012 09:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.186 X-Spam-Level: X-Spam-Status: No, score=-102.186 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, 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 MpqDtsEWjPaE for ; Thu, 18 Oct 2012 09:12:38 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.139.30]) by ietfa.amsl.com (Postfix) with ESMTP id B9F6721F883B for ; Thu, 18 Oct 2012 09:12:37 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 97BD74A00C5CE; Thu, 18 Oct 2012 11:12:38 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 4A13B4A00C59C for ; Thu, 18 Oct 2012 11:12:38 -0500 (CDT) Received: from [96.241.97.104] (port=62613 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TOsi4-0001bs-3Z; Thu, 18 Oct 2012 11:12:36 -0500 Message-ID: <50802A73.10205@ieca.com> Date: Thu, 18 Oct 2012 12:12:35 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Dan Harkins References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> <507CA3B4.1070303@ieca.com> <6f873581eff8119db139416e44a0d0d2.squirrel@www.trepanning.net> <508018FC.8020300@ieca.com> In-Reply-To: <508018FC.8020300@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.241.97.104]:62613 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= 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: Thu, 18 Oct 2012 16:12:38 -0000 Dan, After talking it over the preferred* approach to answer the 802.11 request is to include them in the IKEv1 registry (as suggested by Michael R.) with a tweaked note. Rationale being that if you used what I suggested you'd have to make sure two registries were updated if a change was made to the registry at some later time. i.e.,: Value ----- 27 ... y Group ----- Reserved for 802.11 Brainpool Group 1 ... Reserved for 802.11 Brainpool Group n Description ----------- This specification ... This specification Notes ----- Only for 802.11 - Not for use with IKEv1 Only for 802.11 - Not for use with IKEv1 Only for 802.11 - Not for use with IKEv1 spt * I say preferred because you can try another approach if you want. On 10/18/12 10:58 AM, Sean Turner wrote: > Dan, > > There's not need to ask the IESG about the process to update the > registry in question it's clear: RFC required. You can get an RFC > through a WG, through an AD, or through the ISE. > > spt > > On 10/15/12 10:54 PM, Dan Harkins wrote: >> >> Hi Sean, >> >> On Mon, October 15, 2012 5:00 pm, Sean Turner wrote: >>> >>> On 10/12/12 2:32 AM, Dan Harkins wrote: >>>> >>>> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: >>>>> >>>>> I'm going to run my proposal and Michael's by the IESG on an informal >>>>> telechat to see which one's got the best chance of getting through the >>>>> process to resolve the IEEE's request. >>>> >>>> Can you ask the IESG to just do what it has done in the past? That >>>> is, >>>> just update the registry to include code points for new curves without >>>> any bizarre notes or pointers? No fuss, no mess, just a few new rows >>>> in a table. >>>> >>>> The worst that could happen if the IESG agrees to do that is that >>>> someone >>>> somewhere might use a brainpool curve with IKEv1. The odds are slim, >>>> but they're not zero. And if that happens then so what? Really. So >>>> what? >>> >>> The RFC 5114 example wasn't published to address another SDO request for >>> a code point so I don't think it's the same situation. >> >> That's certainly a distinction but I don't see how that matters. You >> could also >> note that RFC 5114 added MODP groups as well as ECP groups. Also a >> distinction that really doesn't matter. >> >> Again, the SDO request is a _by-product_ of the opposition to just >> letting >> Johannes' draft update the registry. It is this same opposition that is >> creating >> these problems about notes and pointers and the concern over whether they >> will have the desired effect and what we should do to ensure they do. >> If this >> opposition had not materialized there never would've been another SDO >> request. >> >> It is the same situation, indulge me here a bit: >> >> What we had was another organization (NIST) came up with some new DH >> groups and there was a proposal to add them to both IKEv1 and IKEv2 >> registries. And now, quite similarly, there's another organization >> (the ECC >> Brainpool) that came up with some new DH groups and there was a proposal >> to add them to both IKEv1 and IKEv2 registries. >> >> When the proposal was made to add the NIST groups to the IKEv1 >> registry there was no hullabaloo over updating a deprecated protocol's >> registry and there was no concern that someone somewhere might use >> the NIST groups with IKEv1. >> >> But when Johannes made his proposal to add the ECC Brainpool curves >> to the IKEv1 registry there was all of a sudden a hullabaloo and much >> concern that someone somewhere might use the ECC Brainpool groups >> with IKEv1. >> >> So my request to you is to ask that the IESG consider what the process >> defined for updating this registry is (it's RFC required) and to note >> that >> there is precedence to update the registry of this deprecated protocol. >> So please ask the IESG to just approve a draft (either Johannes' or mine) >> for publication as an RFC to update this registry in the same manner that >> RFC 5114 updated it (i.e. no notes, no pointers, no nonsense). >> >> Then there'd be no need for the IESG to have a discussion about the >> (de)merits of notes and pointers in registries and how best to ensure >> that >> no one nowhere ever even thinks about using an ECC Brainpool curve in >> IKEv1 and that certainly sounds like a better use of everyone's time. >> >> regards, >> >> Dan. >> >> >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From Chris.Ulliott@cesg.gsi.gov.uk Thu Oct 18 10:04: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 94E9A21F876A for ; Thu, 18 Oct 2012 10:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, 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 OwmI4p2nYo75 for ; Thu, 18 Oct 2012 10:04:30 -0700 (PDT) Received: from mail205.messagelabs.com (mail205.messagelabs.com [85.158.140.179]) by ietfa.amsl.com (Postfix) with ESMTP id B119121F86DC for ; Thu, 18 Oct 2012 10:04:29 -0700 (PDT) X-Env-Sender: Chris.Ulliott@cesg.gsi.gov.uk X-Msg-Ref: server-15.tower-205.messagelabs.com!1350579867!11894364!1 X-Originating-IP: [195.92.40.48] X-StarScan-Received: X-StarScan-Version: 6.6.1.3; banners=cesg.gsi.gov.uk,-,- X-VirusChecked: Checked Received: (qmail 22547 invoked from network); 18 Oct 2012 17:04:27 -0000 Received: from gateway-201.energis.gsi.gov.uk (HELO mx.hosting-e.gsi.gov.uk) (195.92.40.48) by server-15.tower-205.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Oct 2012 17:04:27 -0000 From: "Ulliott, Chris" CC: IPsecme WG Date: Thu, 18 Oct 2012 18:04:20 +0100 Thread-Topic: [IPsec] STRONG NUDGE: Revised AD VPN Requirements Thread-Index: Ac2sh7Vz3tKqH6XRTxaJuhXtn5j6CgAymeew Message-ID: <20549DD10769DA47A86F0F0FAF8012DD039600DA74@PIACHEVEX00.GCHQ.GOV.UK> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] 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: Thu, 18 Oct 2012 17:04:31 -0000 For my scenario, having hub and spoke doesn't really work. What happens w= ith multiple organisations, do they each have a hub? - how do they communi= cate between them. I'd like to set the challenge of trying to do full mes= h - it may be that we need a mechanism that notifies gateways if one has g= one rogue, but that doesn't necessarily require a hub and spoke architectu= re for the tunnels. Does that make sense? Chris -----Original Message----- From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] Sent: Wednesday, October 17, 2012 5:52 PM To: Ulliott, Chris Cc: IPsecme WG Subject: Re: [IPsec] STRONG NUDGE: Revised AD VPN Requirements Hi Chris, Thanks a lot for your comments, my points inline: On Wed, Oct 17, 2012 at 7:47 AM, Ulliott, Chris wrote: Apologies for the delay in replying... I think the Gateway to gateway use case (para 2.2) doesn't cover t= he problem I'm suffering. What if the use case was reworded such that it = says something along the lines of: -- start -- A typical Enterprise traffic model is hub and spoke, with the gate= ways connecting to each other using IPsec tunnels. However for the voice and other rich media traffic that occupies a= lot of bandwidth or is performance sensative, the traffic tromboning to t= he hub can create traffic bottlenecks on the hub and can lead to an increa= se in cost. A fully meshed solution is would make best use of the availab= le network capacity and performance but the deployment of a fully meshed s= olution involves considerable configuration, especially when a large numbe= r of nodes are involved. For the reasons of cost and manual error reducti= on, it is desired that there be minimal configuration on each gateway. VM> I agree adding the point of Full mesh having more configuration is an = issue and will add it to the text. However another issue we see is that in= a Full Mesh we need connectivity between all nodes which means that the w= eakest link is the Branch device, that is another reason we have a hub and= spoke with the mesh cross connections on demand. It is highly desirable that the solution works where the endpoints are adm= inistrated by separate management domains, albeit, ones that have an exist= ing trust relationship (for example two organisations who are collaboratin= g on a project, they may wish to join their networks, whilst retaining ind= ependent control over configuration) VM> I agree we should state this in the requirement explicitly and is crit= ical to the solution. When two gateways communicate, they must use a mechanism for authenticatio= n, such that they do not expose themselves to the risk of impersonation by= the other entities. VM> Sounds good. -- end -- In section 3.2, it would be nice if we could again mention that rather loo= king for a solution that makes a star architecture work, actually enables = a dynamic, fully meshed solution to be practical. VM> Agree.We call it star with temporary mesh connection, I agree we can c= all it dynamic mesh connectivity instead. In section 4.1, there are comments about minimising the configuration chan= ges... should we word this a bit stronger and say that after initial confi= guration, there should be no need for a manual configuration change as dev= ices (endpoint or gateways) are added, removed or changed? VM> I am ok with that, my point was we need to configure profiles when a d= evice is added, we do not need to reconfigure if we find devices of the sa= me profile. For the use case where end points need to find the optimum gateway to conn= ect to, do we need a requirement that enables an endpoint to identify whic= h is the best gateway to connect to, the nearest may not be the best, depe= nding on the network cost behind the gateway... but this may be complicati= ng the problem too much. VM> I think the problem of network cost is that of routing. We need a way = for policy to determine when to transfer a connection from one gateway to = another. The solution should allow for such signalling though. Thoughts? VM> Great comments, which I can see come from real world=20usecases. Thanks, Vishwas Chris -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Be= half Of Paul Hoffman Sent: Saturday, September 08, 2012 5: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 n= o 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 wr= ote: > 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 > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-probl= em > > 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. > > 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. > > Thanks, > > Steve > > ------------ > > Summary of Changes in draft-ietf-ipsecme-ad-vpn-00.txt > > * Changed draft name from p2p-vpn to ad-vpn. > > * Added a paragraph for each requirement, explaining how > that requirement is driven by the use cases. > > * In requirement 1, defined what we mean by minimizing > configuration changes. > > * 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. > > * Split requirement 4 into two requirements (now 4 and 5). > > * In requirement 6 (formerly 5), explained what we mean > by "easy handoff of sessions": avoid TCP session breakage > and packet loss, when possible. > > * 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. > > * Added new requirement 9 around manageability. > > * Added new requirement 10 around cross-organization use. > > * Added new requirement 11 saying that administrators should > be able to limit topologies for security and other reasons. > > * Fixed typos and other minor wording issues. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ******************************************************************= ********** Communications with GCHQ may be monitored and/or recorded for system efficiency and other lawful purposes. Any views or opinions expressed in this e-mail do not necessarily reflect GCHQ policy. This email, and any attachments, is intended for the attention of the addressee(s) only. Its unauthorised use, disclosure, storage or copying is not permitted. If you are not t= he intended recipient, please notify postmaster@gchq.gsi.gov.uk. This information is exempt from disclosure under the Freedom of Information Act 2000 and may be subject to exemption under other UK information legislation. Refer disclosure requests to 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 Governme= nt Secure Intranet virus scanning service supplied by Cable&Wireless World= wide in partnership with MessageLabs. (CCTM Certificate Number 2009/09/005= 2.) On leaving the GSi this email was certified virus free. Communications via the GSi may be automatically logged, monitored = and/or recorded for legal purposes. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec This email was received from the INTERNET and scanned by the Government Se= cure Intranet anti-virus service supplied by Cable&Wireless Worldwide=20in= partnership with MessageLabs. (CCTM Certificate Number 2009/09/0052.) In = case of problems, please call your organisation's IT Helpdesk. Communications via the GSi may be automatically logged, monitored and/or r= ecorded for legal purposes. 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 turners@ieca.com Thu Oct 18 10:36: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 599C921F85ED for ; Thu, 18 Oct 2012 10:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.21 X-Spam-Level: X-Spam-Status: No, score=-102.21 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, 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 C3D5KRBiUy4g for ; Thu, 18 Oct 2012 10:36:15 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.223.19]) by ietfa.amsl.com (Postfix) with ESMTP id C1DD921F846F for ; Thu, 18 Oct 2012 10:36:15 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 008EB4A263622; Thu, 18 Oct 2012 12:36:17 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id E9F274A2635F7 for ; Thu, 18 Oct 2012 12:36:16 -0500 (CDT) Received: from [96.241.97.104] (port=62886 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TOu11-0000TP-1v; Thu, 18 Oct 2012 12:36:15 -0500 Message-ID: <50803E0E.7030809@ieca.com> Date: Thu, 18 Oct 2012 13:36:14 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Tero Kivinen References: <20605.22568.706182.460230@fireball.kivinen.iki.fi> In-Reply-To: <20605.22568.706182.460230@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.241.97.104]:62886 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-oob-pubkey-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 17:36:16 -0000 Tero, Gotta ask: Should this draft update RFC 5996? On the one hand, it's optional and existing implementations don't need to support it. On the other hand, if you're really trying to deprecate the old RSA raw key format shouldn't it update the base doc? Could add an informative reference to RFC 5480 in App A for the 04 byte to indicate it's uncompressed. But, it's not absolutely necessary. spt On 10/16/12 8:50 AM, Tero Kivinen wrote: > I updated the draft-kivinen-ipsecme-oob-pubkey document, the new > version includes some examples in the appendix, including the actual > bits on the wire examples. > > One thing that needs to be decided before this document is ready: > "What shall we do with the old "Raw RSA Key" format?" > > The current draft keeps it, and RECOMMENDs this new format for all > types of raw keys, and does the negotiation using the standard IKEv2 > CERTREQ payloads. This means there is two ways of doing exactly same > thing, i.e. sending Raw RSA keys in IKEv2. > > Another option would be to change this document to be Standard track > document, mark it as Updating 5996, and say that using old "Raw RSA > Key" format is NOT RECOMMENDED. This would mean there is only one way > of sending Raw RSA keys keys in IKEv2, i.e. the new way. > > Third option would say that this new format is only used for non-RSA > keys, and for Raw RSA keys, you always MUST use the old format. I do > not like this last option as it would require minimal implementations > to implement both formats, as with both of the above options the > minimal implementation can just decide that it only supports this one > format and uses it for everything. > > I would like to get feedback from the WG, which way should we go > forward? > > ---------------------------------------------------------------------- > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-kivinen-ipsecme-oob-pubkey-01.txt > Date: Tue, 16 Oct 2012 05:40:09 -0700 > > > A new version of I-D, draft-kivinen-ipsecme-oob-pubkey-01.txt > has been successfully submitted by Tero Kivinen and posted to the > IETF repository. > > Filename: draft-kivinen-ipsecme-oob-pubkey > Revision: 01 > Title: More Raw Public Keys for IKEv2 > Creation date: 2012-10-16 > WG ID: Individual Submission > Number of pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-oob-pubkey-01.txt > Status: http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey > Htmlized: http://tools.ietf.org/html/draft-kivinen-ipsecme-oob-pubkey-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-kivinen-ipsecme-oob-pubkey-01 > > Abstract: > The Internet Key Exchange Version 2 (IKEv2) protocol currently only > supports raw RSA keys. In some environments it is useful to make use > of other types of public keys, such as those based on Elliptic Curve > Cryptography. This documents adds support for other types of raw > public keys to IKEv2. > From paul.hoffman@vpnc.org Thu Oct 18 19:31:06 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE9021F84EA for ; Thu, 18 Oct 2012 19:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 cMZStd4zxq57 for ; Thu, 18 Oct 2012 19:31: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 A6FB821F84E8 for ; Thu, 18 Oct 2012 19:31:05 -0700 (PDT) Received: from [10.20.30.101] (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 q9J2UwRB047683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Oct 2012 19:30:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: <20608.1178.765684.923417@fireball.kivinen.iki.fi> Date: Thu, 18 Oct 2012 19:30:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20608.1178.765684.923417@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1499) Cc: IPsecme WG Subject: [IPsec] Waiting for new version of draft-ietf-ipsecme-ad-vpn-problem 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, 19 Oct 2012 02:31:06 -0000 On Oct 18, 2012, at 6:31 AM, Tero Kivinen wrote: > I did send quite a lot of comments to the draft at 2012-09-10, and I > have not seen those taken into the draft yet. Also as I noted in my > email I am quite sure we are still missing some requirements, but as > the current document is bit hard to read with the terminology of > different nodes, hubs, endpoints etc so it is bit hard to understand > if all requirements are there or not. >=20 > http://www.ietf.org/mail-archive/web/ipsec/current/msg07910.html > http://www.ietf.org/mail-archive/web/ipsec/current/msg07914.html >=20 > I myself do think that the draft-ietf-ipsecme-ad-vpn-problem-00 is NOT > yet ready, I have been waiting for the next version of the document > before rereading it. You did ask for changes during WG Last Call, and the authors agreed on = many of them, but then did not produce the -01 draft (and I did not = notice this). I *really* hope they produce a new version before the = submission cutoff on Monday; we can then either continue the discussion = or send the document to IETF Last Call. --Paul Hoffman= From paul.hoffman@vpnc.org Thu Oct 18 19:35:02 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B9221F8435 for ; Thu, 18 Oct 2012 19:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 3XOa5QuK-oVA for ; Thu, 18 Oct 2012 19:35:02 -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 05E3B21F842F for ; Thu, 18 Oct 2012 19:35:01 -0700 (PDT) Received: from [10.20.30.101] (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 q9J2Z0aH047781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Oct 2012 19:35:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman X-Priority: 3 (Normal) In-Reply-To: <4877f6a502ed7435b2d0d357431d6ba4.squirrel@www.trepanning.net> Date: Thu, 18 Oct 2012 19:35:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3F23F26B-771F-456D-A98F-AD135CDDE632@vpnc.org> References: <4877f6a502ed7435b2d0d357431d6ba4.squirrel@www.trepanning.net> To: Dan Harkins X-Mailer: Apple Mail (2.1499) Cc: IPsecme WG , Tero Kivinen Subject: Re: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 02:35:02 -0000 On Oct 17, 2012, at 5:32 PM, Dan Harkins wrote: > I would be happy to discuss IKEv3. Please let me know if you'll put = me > on the agenda and I'll prepare some slides to talk to. It would be good if you put together a short (less than 15 minutes) = presentation on your motivations for the new protocol. That is, we don't = need a presentation on what is in the document, but what isn't there: = what are the problems that are to be solved. Tero: even though you are taking draft-kivinen-ipsecme-ikev2-minimal to = the LWIG WG, could you do a similar presentation on the problems that = your document solves for the IPsecME WG? Yaron and I suspect that there = is overlap, and having good lists of the similarities and differences = behind the documents would help the two WGs decide what should be in = them. --Paul Hoffman= From dharkins@lounge.org Fri Oct 19 00:06:30 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E586521F8620 for ; Fri, 19 Oct 2012 00:06:30 -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=[AWL=-0.000, 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 L1TPvHkPvf0H for ; Fri, 19 Oct 2012 00:06:30 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id EA8B821F858C for ; Fri, 19 Oct 2012 00:06:29 -0700 (PDT) Received: from colo.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 824D010224008; Fri, 19 Oct 2012 00:06:24 -0700 (PDT) Received: from 118.21.136.4 (SquirrelMail authenticated user dharkins@lounge.org) by colo.trepanning.net with HTTP; Fri, 19 Oct 2012 00:06:24 -0700 (PDT) Message-ID: <41cc5f87c1fc8fb4f7307b824b15a4df.squirrel@colo.trepanning.net> In-Reply-To: <50802A73.10205@ieca.com> References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> <507CA3B4.1070303@ieca.com> <6f873581eff8119db139416e44a0d0d2.squirrel@www.trepanning.net> <508018FC.8020300@ieca.com> <50802A73.10205@ieca.com> Date: Fri, 19 Oct 2012 00:06:24 -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, Dan Harkins 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, 19 Oct 2012 07:06:31 -0000 Sean, The thing is, they're not just for 802.11. RFC 5931 uses them too. Dan. On Thu, October 18, 2012 9:12 am, Sean Turner wrote: > Dan, > > After talking it over the preferred* approach to answer the 802.11 > request is to include them in the IKEv1 registry (as suggested by > Michael R.) with a tweaked note. Rationale being that if you used what > I suggested you'd have to make sure two registries were updated if a > change was made to the registry at some later time. i.e.,: > > Value > ----- > 27 > ... > y > > Group > ----- > Reserved for 802.11 Brainpool Group 1 > ... > Reserved for 802.11 Brainpool Group n > > Description > ----------- > This specification > ... > This specification > > Notes > ----- > Only for 802.11 - Not for use with IKEv1 > Only for 802.11 - Not for use with IKEv1 > Only for 802.11 - Not for use with IKEv1 > > spt > > * I say preferred because you can try another approach if you want. > > On 10/18/12 10:58 AM, Sean Turner wrote: >> Dan, >> >> There's not need to ask the IESG about the process to update the >> registry in question it's clear: RFC required. You can get an RFC >> through a WG, through an AD, or through the ISE. >> >> spt >> >> On 10/15/12 10:54 PM, Dan Harkins wrote: >>> >>> Hi Sean, >>> >>> On Mon, October 15, 2012 5:00 pm, Sean Turner wrote: >>>> >>>> On 10/12/12 2:32 AM, Dan Harkins wrote: >>>>> >>>>> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: >>>>>> >>>>>> I'm going to run my proposal and Michael's by the IESG on an >>>>>> informal >>>>>> telechat to see which one's got the best chance of getting through >>>>>> the >>>>>> process to resolve the IEEE's request. >>>>> >>>>> Can you ask the IESG to just do what it has done in the past? >>>>> That >>>>> is, >>>>> just update the registry to include code points for new curves >>>>> without >>>>> any bizarre notes or pointers? No fuss, no mess, just a few new rows >>>>> in a table. >>>>> >>>>> The worst that could happen if the IESG agrees to do that is that >>>>> someone >>>>> somewhere might use a brainpool curve with IKEv1. The odds are slim, >>>>> but they're not zero. And if that happens then so what? Really. So >>>>> what? >>>> >>>> The RFC 5114 example wasn't published to address another SDO request >>>> for >>>> a code point so I don't think it's the same situation. >>> >>> That's certainly a distinction but I don't see how that matters. You >>> could also >>> note that RFC 5114 added MODP groups as well as ECP groups. Also a >>> distinction that really doesn't matter. >>> >>> Again, the SDO request is a _by-product_ of the opposition to just >>> letting >>> Johannes' draft update the registry. It is this same opposition that is >>> creating >>> these problems about notes and pointers and the concern over whether >>> they >>> will have the desired effect and what we should do to ensure they do. >>> If this >>> opposition had not materialized there never would've been another SDO >>> request. >>> >>> It is the same situation, indulge me here a bit: >>> >>> What we had was another organization (NIST) came up with some new DH >>> groups and there was a proposal to add them to both IKEv1 and IKEv2 >>> registries. And now, quite similarly, there's another organization >>> (the ECC >>> Brainpool) that came up with some new DH groups and there was a >>> proposal >>> to add them to both IKEv1 and IKEv2 registries. >>> >>> When the proposal was made to add the NIST groups to the IKEv1 >>> registry there was no hullabaloo over updating a deprecated protocol's >>> registry and there was no concern that someone somewhere might use >>> the NIST groups with IKEv1. >>> >>> But when Johannes made his proposal to add the ECC Brainpool curves >>> to the IKEv1 registry there was all of a sudden a hullabaloo and much >>> concern that someone somewhere might use the ECC Brainpool groups >>> with IKEv1. >>> >>> So my request to you is to ask that the IESG consider what the >>> process >>> defined for updating this registry is (it's RFC required) and to note >>> that >>> there is precedence to update the registry of this deprecated protocol. >>> So please ask the IESG to just approve a draft (either Johannes' or >>> mine) >>> for publication as an RFC to update this registry in the same manner >>> that >>> RFC 5114 updated it (i.e. no notes, no pointers, no nonsense). >>> >>> Then there'd be no need for the IESG to have a discussion about the >>> (de)merits of notes and pointers in registries and how best to ensure >>> that >>> no one nowhere ever even thinks about using an ECC Brainpool curve in >>> IKEv1 and that certainly sounds like a better use of everyone's time. >>> >>> regards, >>> >>> Dan. >>> >>> >>> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > From dharkins@lounge.org Fri Oct 19 00: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 0FDDD21F85E8 for ; Fri, 19 Oct 2012 00:20:44 -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=[AWL=-0.000, 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 THRWcw2p4Ws8 for ; Fri, 19 Oct 2012 00:20:43 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7006C21F844B for ; Fri, 19 Oct 2012 00:20:43 -0700 (PDT) Received: from colo.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9460410224008; Fri, 19 Oct 2012 00:20:42 -0700 (PDT) Received: from 118.21.136.4 (SquirrelMail authenticated user dharkins@lounge.org) by colo.trepanning.net with HTTP; Fri, 19 Oct 2012 00:20:43 -0700 (PDT) Message-ID: <6c2da556f3555c85b87a09df0e440e3d.squirrel@colo.trepanning.net> In-Reply-To: <508018FC.8020300@ieca.com> References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> <507CA3B4.1070303@ieca.com> <6f873581eff8119db139416e44a0d0d2.squirrel@www.trepanning.net> <508018FC.8020300@ieca.com> Date: Fri, 19 Oct 2012 00:20:43 -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, Dan Harkins 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, 19 Oct 2012 07:20:44 -0000 Sean, It was a two-part request. I'd like the IESG to follow the same process they followed for what became RFC 5114. Is there a way to get an RFC published to update this registry that does not need to go through the IESG? If not then the 2nd part is the critical one; if so then we can just end this fiasco now. regards, Dan. On Thu, October 18, 2012 7:58 am, Sean Turner wrote: > Dan, > > There's not need to ask the IESG about the process to update the > registry in question it's clear: RFC required. You can get an RFC > through a WG, through an AD, or through the ISE. > > spt > > On 10/15/12 10:54 PM, Dan Harkins wrote: >> >> Hi Sean, >> >> On Mon, October 15, 2012 5:00 pm, Sean Turner wrote: >>> >>> On 10/12/12 2:32 AM, Dan Harkins wrote: >>>> >>>> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: >>>>> >>>>> I'm going to run my proposal and Michael's by the IESG on an informal >>>>> telechat to see which one's got the best chance of getting through >>>>> the >>>>> process to resolve the IEEE's request. >>>> >>>> Can you ask the IESG to just do what it has done in the past? That >>>> is, >>>> just update the registry to include code points for new curves without >>>> any bizarre notes or pointers? No fuss, no mess, just a few new rows >>>> in a table. >>>> >>>> The worst that could happen if the IESG agrees to do that is that >>>> someone >>>> somewhere might use a brainpool curve with IKEv1. The odds are slim, >>>> but they're not zero. And if that happens then so what? Really. So >>>> what? >>> >>> The RFC 5114 example wasn't published to address another SDO request >>> for >>> a code point so I don't think it's the same situation. >> >> That's certainly a distinction but I don't see how that matters. You >> could also >> note that RFC 5114 added MODP groups as well as ECP groups. Also a >> distinction that really doesn't matter. >> >> Again, the SDO request is a _by-product_ of the opposition to just >> letting >> Johannes' draft update the registry. It is this same opposition that is >> creating >> these problems about notes and pointers and the concern over whether >> they >> will have the desired effect and what we should do to ensure they do. If >> this >> opposition had not materialized there never would've been another SDO >> request. >> >> It is the same situation, indulge me here a bit: >> >> What we had was another organization (NIST) came up with some new DH >> groups and there was a proposal to add them to both IKEv1 and IKEv2 >> registries. And now, quite similarly, there's another organization (the >> ECC >> Brainpool) that came up with some new DH groups and there was a proposal >> to add them to both IKEv1 and IKEv2 registries. >> >> When the proposal was made to add the NIST groups to the IKEv1 >> registry there was no hullabaloo over updating a deprecated protocol's >> registry and there was no concern that someone somewhere might use >> the NIST groups with IKEv1. >> >> But when Johannes made his proposal to add the ECC Brainpool curves >> to the IKEv1 registry there was all of a sudden a hullabaloo and much >> concern that someone somewhere might use the ECC Brainpool groups >> with IKEv1. >> >> So my request to you is to ask that the IESG consider what the >> process >> defined for updating this registry is (it's RFC required) and to note >> that >> there is precedence to update the registry of this deprecated protocol. >> So please ask the IESG to just approve a draft (either Johannes' or >> mine) >> for publication as an RFC to update this registry in the same manner >> that >> RFC 5114 updated it (i.e. no notes, no pointers, no nonsense). >> >> Then there'd be no need for the IESG to have a discussion about the >> (de)merits of notes and pointers in registries and how best to ensure >> that >> no one nowhere ever even thinks about using an ECC Brainpool curve in >> IKEv1 and that certainly sounds like a better use of everyone's time. >> >> regards, >> >> Dan. >> >> >> > From mglt.ietf@gmail.com Fri Oct 19 00:21: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 5EB2321F8630 for ; Fri, 19 Oct 2012 00:21: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 Ntl9D8115YrL for ; Fri, 19 Oct 2012 00:21:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1B1E21F84F8 for ; Fri, 19 Oct 2012 00:21:45 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fc26so165313vbb.31 for ; Fri, 19 Oct 2012 00:21:45 -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=I0Sfo5xucJvs/cBiPlJamC8g9WKjc3igCfmQLL7qZ+s=; b=ClGTC3AT+AjAZfPkW6UVV6iq93mIX3ETX5FTOpyVPsYc6DI23tll8jXoJ/NgfmjGSV AwZSgKyNJsS+ykHoj/PUjAuejfkj1z6k7GmAiv2d4Zhs9/MFEtpOSKzdXFS+ufjyx6Op yhesJwi8J68uwix4CcXqYb+hXcG75SurGavavhxK+JQVFE+9PF/nFsi+FFtGDbckNSpV B60bCDLFAM/Pu3KWtyWgMYEoGq8Emsl48oCY1NTokK81/eGNlKLCsJGQtbSLfOS++wHB dIhfiCa839QO4k5XQt3O76C+eM8TPICsQoX3CsfYNgXI2O90wEKvvNEX6BVmsYzM8kXw XqHg== MIME-Version: 1.0 Received: by 10.52.76.103 with SMTP id j7mr360683vdw.22.1350631304999; Fri, 19 Oct 2012 00:21:44 -0700 (PDT) Received: by 10.58.203.68 with HTTP; Fri, 19 Oct 2012 00:21:44 -0700 (PDT) In-Reply-To: <3F23F26B-771F-456D-A98F-AD135CDDE632@vpnc.org> References: <4877f6a502ed7435b2d0d357431d6ba4.squirrel@www.trepanning.net> <3F23F26B-771F-456D-A98F-AD135CDDE632@vpnc.org> Date: Fri, 19 Oct 2012 09:21:44 +0200 Message-ID: From: Daniel Migault To: Paul Hoffman Content-Type: multipart/alternative; boundary=bcaec50162332832c804cc645b2e Cc: IPsecme WG , Dan Harkins , Tero Kivinen Subject: Re: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 07:21:46 -0000 --bcaec50162332832c804cc645b2e Content-Type: text/plain; charset=ISO-8859-1 Hi, I would also like to have a slot to present our ongoing work on IPsec and Multiple Interfaces. One of the document is also presented in MIF. I will update the document presented to MIF by end of next week. Best Regards, Daniel On Fri, Oct 19, 2012 at 4:35 AM, Paul Hoffman wrote: > On Oct 17, 2012, at 5:32 PM, Dan Harkins wrote: > > > I would be happy to discuss IKEv3. Please let me know if you'll put me > > on the agenda and I'll prepare some slides to talk to. > > > It would be good if you put together a short (less than 15 minutes) > presentation on your motivations for the new protocol. That is, we don't > need a presentation on what is in the document, but what isn't there: what > are the problems that are to be solved. > > Tero: even though you are taking draft-kivinen-ipsecme-ikev2-minimal to > the LWIG WG, could you do a similar presentation on the problems that your > document solves for the IPsecME WG? Yaron and I suspect that there is > overlap, and having good lists of the similarities and differences behind > the documents would help the two WGs decide what should be in them. > > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --bcaec50162332832c804cc645b2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I would also like to have a slot to present our ongoing work on IPsec= =20 and Multiple Interfaces. One of the document is also presented in MIF. I wi= ll update the document presented to MIF by=20 end of next week.

Best Regards,

Daniel

On Fri, Oct 19, 2012 at 4:35 AM, Paul Ho= ffman <paul.hoffman@vpnc.org> wrote:
On Oct 17, 2012, at 5:32 PM, Dan Harkins <dharkins@lounge.org> wrote:

> =A0I would be happy to discuss IKEv3. Please let me know if you'll= put me
> on the agenda and I'll prepare some slides to talk to.


It would be good if you put together a short (less than 15 minutes) p= resentation on your motivations for the new protocol. That is, we don't= need a presentation on what is in the document, but what isn't there: = what are the problems that are to be solved.

Tero: even though you are taking draft-kivinen-ipsecme-ikev2-minimal to the= LWIG WG, could you do a similar presentation on the problems that your doc= ument solves for the IPsecME WG? Yaron and I suspect that there is overlap,= and having good lists of the similarities and differences behind the docum= ents would help the two WGs decide what should be in them.

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



--
Daniel Miga= ult
Orange Labs -- Security
+33 6 70 72 69 58
--bcaec50162332832c804cc645b2e-- From kivinen@iki.fi Fri Oct 19 03:50: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 D831E21F8522 for ; Fri, 19 Oct 2012 03:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 DOqmAEHjNRJA for ; Fri, 19 Oct 2012 03:50:15 -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 1089C21F84EE for ; Fri, 19 Oct 2012 03:50:14 -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 q9JAo2dH021720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 13:50:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q9JAo2KQ017941; Fri, 19 Oct 2012 13:50:02 +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: <20609.12378.3354.471264@fireball.kivinen.iki.fi> Date: Fri, 19 Oct 2012 13:50:02 +0300 From: Tero Kivinen To: Sean Turner In-Reply-To: <50803E0E.7030809@ieca.com> References: <20605.22568.706182.460230@fireball.kivinen.iki.fi> <50803E0E.7030809@ieca.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 11 min Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-oob-pubkey-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 10:50:16 -0000 Sean Turner writes: > Gotta ask: Should this draft update RFC 5996? On the one hand, it's > optional and existing implementations don't need to support it. On the > other hand, if you're really trying to deprecate the old RSA raw key > format shouldn't it update the base doc? If we want to deprecate the old raw RSA keys, then I think this document needs to be standard track, and it needs to update RFC 5996. If we just add new format for raw public keys, and both old raw RSA certificate format and this new format then I think it can be informational and there is no need for this document to "Update" the RFC5996. Our previous additions to the IKEv2 have not updated the base spec (redirect, resumption, IPv6 address configuration, password authentication, high availability, childless etc). The EAP only authentication do update RFC5996. So the answer really depends on which way the WG wants this document to go... > Could add an informative reference to RFC 5480 in App A for the 04 byte > to indicate it's uncompressed. But, it's not absolutely necessary. Done. -- kivinen@iki.fi From kivinen@iki.fi Fri Oct 19 04:01: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 B4CCE21F8697 for ; Fri, 19 Oct 2012 04:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 AvacqvccUegb for ; Fri, 19 Oct 2012 04:01:38 -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 01D4621F8696 for ; Fri, 19 Oct 2012 04:01:37 -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 q9JB1YDd020286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Oct 2012 14:01:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q9JB1XJm018613; Fri, 19 Oct 2012 14:01:33 +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: <20609.13069.154699.199014@fireball.kivinen.iki.fi> Date: Fri, 19 Oct 2012 14:01:33 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <3F23F26B-771F-456D-A98F-AD135CDDE632@vpnc.org> References: <4877f6a502ed7435b2d0d357431d6ba4.squirrel@www.trepanning.net> <3F23F26B-771F-456D-A98F-AD135CDDE632@vpnc.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 9 min Cc: IPsecme WG , Dan Harkins Subject: Re: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 11:01:38 -0000 Paul Hoffman writes: > Tero: even though you are taking draft-kivinen-ipsecme-ikev2-minimal > to the LWIG WG, could you do a similar presentation on the problems > that your document solves for the IPsecME WG? Yaron and I suspect > that there is overlap, and having good lists of the similarities and > differences behind the documents would help the two WGs decide what > should be in them. Sure. -- kivinen@iki.fi From yaronf.ietf@gmail.com Fri Oct 19 06:47:57 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F5C21F86B0 for ; Fri, 19 Oct 2012 06:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.87 X-Spam-Level: X-Spam-Status: No, score=-102.87 tagged_above=-999 required=5 tests=[AWL=0.729, 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 ighwDzDgiqba for ; Fri, 19 Oct 2012 06:47:56 -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 2580C21F8685 for ; Fri, 19 Oct 2012 06:47:55 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id jc3so227097bkc.31 for ; Fri, 19 Oct 2012 06:47:55 -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=IQDoUDmAzimdN+NOTNPgaYe+ZNz1eERUK6mfImJM/X8=; b=Se3dBfvklZl4UKRj4TrAo92JHRzwJV3pK7VOufc6lYwdVy8h517u9aLaZJzGuNxXXu AL49ZyBJ8rCHGVfWPSs3RvBl2XRk0ukGXZRLU5PT+1UklEzYQIp2V9VpH2GBkT0daL41 draL0HRyV8ZdOuE6c0NCmwByRngD9xFGUP1Oss6rrSTYttsC7QmBBbY3Wz1xrspP8h65 5yOYs2lrofMuq7pIWkYCnYGU9TZnuu0i42dB4cVSn7z/XhBpKuK1o61MizOHBVP0+QX5 7Wb6UzxWSdXtEtEq2Qhh978tUIOiCFE4ZPLbBxKatu7kS9ntt5j+akOmpEOTyayaCi9y yQig== Received: by 10.204.156.202 with SMTP id y10mr498033bkw.6.1350654475215; Fri, 19 Oct 2012 06:47:55 -0700 (PDT) Received: from [10.0.0.4] (bzq-79-182-158-129.red.bezeqint.net. [79.182.158.129]) by mx.google.com with ESMTPS id fm5sm1096887bkc.5.2012.10.19.06.47.53 (version=SSLv3 cipher=OTHER); Fri, 19 Oct 2012 06:47:54 -0700 (PDT) Message-ID: <50815A00.3070500@gmail.com> Date: Fri, 19 Oct 2012 15:47:44 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Tero Kivinen References: <20605.22568.706182.460230@fireball.kivinen.iki.fi> <50803E0E.7030809@ieca.com> <20609.12378.3354.471264@fireball.kivinen.iki.fi> In-Reply-To: <20609.12378.3354.471264@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Sean Turner Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-oob-pubkey-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 13:47:57 -0000 Personally, I think it would be less confusing for everyone involved if this document is Standards Track (and "updates 5996"). Whether we deprecate the old format depends IMO on the level of implementation/use of the old format. I would like to hear from people who care about the old format (i.e. who have it in products, and do not intend to move quickly to the more general solution if it is standardized). If we don't hear any screams, then I definitely support deprecating it. Thanks, Yaron On 19.10.2012 12:50, Tero Kivinen wrote: > Sean Turner writes: >> Gotta ask: Should this draft update RFC 5996? On the one hand, it's >> optional and existing implementations don't need to support it. On the >> other hand, if you're really trying to deprecate the old RSA raw key >> format shouldn't it update the base doc? > If we want to deprecate the old raw RSA keys, then I think this > document needs to be standard track, and it needs to update RFC 5996. > If we just add new format for raw public keys, and both old raw RSA > certificate format and this new format then I think it can be > informational and there is no need for this document to "Update" the > RFC5996. Our previous additions to the IKEv2 have not updated the base > spec (redirect, resumption, IPv6 address configuration, password > authentication, high availability, childless etc). The EAP only > authentication do update RFC5996. > > So the answer really depends on which way the WG wants this document > to go... > >> Could add an informative reference to RFC 5480 in App A for the 04 byte >> to indicate it's uncompressed. But, it's not absolutely necessary. > Done. From dharkins@lounge.org Fri Oct 19 15:54:14 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16C521F8461 for ; Fri, 19 Oct 2012 15:54:14 -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 c9speksFqzak for ; Fri, 19 Oct 2012 15:54:14 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6077421F8458 for ; Fri, 19 Oct 2012 15:54:14 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D02E210224008; Fri, 19 Oct 2012 15:54:13 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 19 Oct 2012 15:54:14 -0700 (PDT) Message-ID: In-Reply-To: <16716.1350652121@obiwan.sandelman.ca> References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> <507CA3B4.1070303@ieca.com> <6f873581eff8119db139416e44a0d0d2.squirrel@www.trepanning.net> <508018FC.8020300@ieca.com> <50802A73.10205@ieca.com> <41cc5f87c1fc8fb4f7307b824b15a4df.squirrel@colo.trepanning.net> <16716.1350652121@obiwan.sandelman.ca> Date: Fri, 19 Oct 2012 15:54:14 -0700 (PDT) From: "Dan Harkins" To: "Michael Richardson" 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: Fri, 19 Oct 2012 22:54:14 -0000 Hi Michael, On Fri, October 19, 2012 6:08 am, Michael Richardson wrote: > >>>>>> "Dan" == Dan Harkins writes: > Dan> The thing is, they're not just for 802.11. RFC 5931 uses them > Dan> too. > > But, you don't use the values from the IKEv1 registry do you? > It might use the curves themselves, but it doesn't identify them using > the IKEv1 registry. At least, that all I could tell where/how from > brief reading of IANA considerations, and some searches. Section 3.2.1 says, "The Group Description field value is taken from the IANA registry for 'Group Description' created by IKE [RFC2409]." That's how groups are identified, by a ushort whose value comes out of this registry. For EAP-pwd to use brainpool curves it will be necessary for the registry to not restrict it from using them (i.e. it can't say "for 802.11 only"). > (ps: it's a well written security considerations) Thank you! Dan. > -- > Michael Richardson , Sandelman Software Works > > > From paul@cypherpunks.ca Sun Oct 21 09:05: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 A75CC21F8504 for ; Sun, 21 Oct 2012 09:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.297, 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 l-tfUX+2UbfJ for ; Sun, 21 Oct 2012 09:05:44 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABC521F84FE for ; Sun, 21 Oct 2012 09:05:43 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 0ED6982B54; Sun, 21 Oct 2012 12:05:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 06FB082B53; Sun, 21 Oct 2012 12:05:18 -0400 (EDT) Date: Sun, 21 Oct 2012 12:05:18 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yaron Sheffer In-Reply-To: <50815A00.3070500@gmail.com> Message-ID: References: <20605.22568.706182.460230@fireball.kivinen.iki.fi> <50803E0E.7030809@ieca.com> <20609.12378.3354.471264@fireball.kivinen.iki.fi> <50815A00.3070500@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: "ipsec@ietf.org WG" , Sean Turner , Tero Kivinen Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-oob-pubkey-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 16:05:44 -0000 On Fri, 19 Oct 2012, Yaron Sheffer wrote: > Personally, I think it would be less confusing for everyone involved if this > document is Standards Track (and "updates 5996"). Sure. > Whether we deprecate the old format depends IMO on the level of > implementation/use of the old format. I would like to hear from people who > care about the old format (i.e. who have it in products, and do not intend to > move quickly to the more general solution if it is standardized). If we don't > hear any screams, then I definitely support deprecating it. Fine with me, Paul From turners@ieca.com Sun Oct 21 09:20: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 EC1E221F8978 for ; Sun, 21 Oct 2012 09:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.215 X-Spam-Level: X-Spam-Status: No, score=-102.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 laBOmYZRcbLV for ; Sun, 21 Oct 2012 09:20:10 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.93.154.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFC021F892E for ; Sun, 21 Oct 2012 09:20:10 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 97BC142B12BD5; Sun, 21 Oct 2012 11:20:03 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 8A2F242B12BB5 for ; Sun, 21 Oct 2012 11:20:03 -0500 (CDT) Received: from [96.241.97.104] (port=63723 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TPyG1-0004RX-9u; Sun, 21 Oct 2012 11:20:09 -0500 Message-ID: <508420B8.7040602@ieca.com> Date: Sun, 21 Oct 2012 12:20:08 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Dan Harkins References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> <507CA3B4.1070303@ieca.com> <6f873581eff8119db139416e44a0d0d2.squirrel@www.trepanning.net> <508018FC.8020300@ieca.com> <6c2da556f3555c85b87a09df0e440e3d.squirrel@colo.trepanning.net> In-Reply-To: <6c2da556f3555c85b87a09df0e440e3d.squirrel@colo.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.241.97.104]:63723 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= 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: Sun, 21 Oct 2012 16:20:11 -0000 Dan, Yes - you can ask the ISE (https://www.rfc-editor.org/indsubs.html) to publish. spt On 10/19/12 3:20 AM, Dan Harkins wrote: > > Sean, > > It was a two-part request. I'd like the IESG to follow the same process > they followed for what became RFC 5114. > > Is there a way to get an RFC published to update this registry that > does not need to go through the IESG? If not then the 2nd part is > the critical one; if so then we can just end this fiasco now. > > regards, > > Dan. > > On Thu, October 18, 2012 7:58 am, Sean Turner wrote: >> Dan, >> >> There's not need to ask the IESG about the process to update the >> registry in question it's clear: RFC required. You can get an RFC >> through a WG, through an AD, or through the ISE. >> >> spt >> >> On 10/15/12 10:54 PM, Dan Harkins wrote: >>> >>> Hi Sean, >>> >>> On Mon, October 15, 2012 5:00 pm, Sean Turner wrote: >>>> >>>> On 10/12/12 2:32 AM, Dan Harkins wrote: >>>>> >>>>> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: >>>>>> >>>>>> I'm going to run my proposal and Michael's by the IESG on an informal >>>>>> telechat to see which one's got the best chance of getting through >>>>>> the >>>>>> process to resolve the IEEE's request. >>>>> >>>>> Can you ask the IESG to just do what it has done in the past? That >>>>> is, >>>>> just update the registry to include code points for new curves without >>>>> any bizarre notes or pointers? No fuss, no mess, just a few new rows >>>>> in a table. >>>>> >>>>> The worst that could happen if the IESG agrees to do that is that >>>>> someone >>>>> somewhere might use a brainpool curve with IKEv1. The odds are slim, >>>>> but they're not zero. And if that happens then so what? Really. So >>>>> what? >>>> >>>> The RFC 5114 example wasn't published to address another SDO request >>>> for >>>> a code point so I don't think it's the same situation. >>> >>> That's certainly a distinction but I don't see how that matters. You >>> could also >>> note that RFC 5114 added MODP groups as well as ECP groups. Also a >>> distinction that really doesn't matter. >>> >>> Again, the SDO request is a _by-product_ of the opposition to just >>> letting >>> Johannes' draft update the registry. It is this same opposition that is >>> creating >>> these problems about notes and pointers and the concern over whether >>> they >>> will have the desired effect and what we should do to ensure they do. If >>> this >>> opposition had not materialized there never would've been another SDO >>> request. >>> >>> It is the same situation, indulge me here a bit: >>> >>> What we had was another organization (NIST) came up with some new DH >>> groups and there was a proposal to add them to both IKEv1 and IKEv2 >>> registries. And now, quite similarly, there's another organization (the >>> ECC >>> Brainpool) that came up with some new DH groups and there was a proposal >>> to add them to both IKEv1 and IKEv2 registries. >>> >>> When the proposal was made to add the NIST groups to the IKEv1 >>> registry there was no hullabaloo over updating a deprecated protocol's >>> registry and there was no concern that someone somewhere might use >>> the NIST groups with IKEv1. >>> >>> But when Johannes made his proposal to add the ECC Brainpool curves >>> to the IKEv1 registry there was all of a sudden a hullabaloo and much >>> concern that someone somewhere might use the ECC Brainpool groups >>> with IKEv1. >>> >>> So my request to you is to ask that the IESG consider what the >>> process >>> defined for updating this registry is (it's RFC required) and to note >>> that >>> there is precedence to update the registry of this deprecated protocol. >>> So please ask the IESG to just approve a draft (either Johannes' or >>> mine) >>> for publication as an RFC to update this registry in the same manner >>> that >>> RFC 5114 updated it (i.e. no notes, no pointers, no nonsense). >>> >>> Then there'd be no need for the IESG to have a discussion about the >>> (de)merits of notes and pointers in registries and how best to ensure >>> that >>> no one nowhere ever even thinks about using an ECC Brainpool curve in >>> IKEv1 and that certainly sounds like a better use of everyone's time. >>> >>> regards, >>> >>> Dan. >>> >>> >>> >> > > > From kivinen@iki.fi Mon Oct 22 04:25:43 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD53221F8AE0 for ; Mon, 22 Oct 2012 04:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 iUXIO8BWHH7L for ; Mon, 22 Oct 2012 04:25:43 -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 5D43A21F8B73 for ; Mon, 22 Oct 2012 04:25:42 -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 q9MBPWCd020653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Oct 2012 14:25:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q9MBPVrk011529; Mon, 22 Oct 2012 14:25:31 +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: <20613.11563.496438.164277@fireball.kivinen.iki.fi> Date: Mon, 22 Oct 2012 14:25:31 +0300 From: Tero Kivinen To: Sean Turner In-Reply-To: <508420B8.7040602@ieca.com> References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> <507CA3B4.1070303@ieca.com> <6f873581eff8119db139416e44a0d0d2.squirrel@www.trepanning.net> <508018FC.8020300@ieca.com> <6c2da556f3555c85b87a09df0e440e3d.squirrel@colo.trepanning.net> <508420B8.7040602@ieca.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 19 min Cc: ipsec@ietf.org, Dan Harkins 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: Mon, 22 Oct 2012 11:25:43 -0000 Sean Turner writes: > Yes - you can ask the ISE (https://www.rfc-editor.org/indsubs.html) to > publish. I am not sure if that helps, as RFC 5742 section 3 will still put it to IESG, and IESG still needs to consider the document and decide which conclusion it will come with it: ---------------------------------------------------------------------- The IESG review of these Independent Submission and IRTF stream documents results in one of the following five types of conclusion, any of which may be accompanied by a request to include an IESG note if the document is published. 1. The IESG has concluded that there is no conflict between this document and IETF work. 2. The IESG has concluded that this work is related to IETF work done in WG , but this relationship does not prevent publishing. 3. The IESG has concluded that publication could potentially disrupt the IETF work done in WG and recommends not publishing the document at this time. 4. The IESG has concluded that this document violates IETF procedures for and should therefore not be published without IETF review and IESG approval. 5. The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval. ---------------------------------------------------------------------- If those numbers are added to "Internet Key Exchange (IKE) Attributes" registry (hey, there is new xml version of the registry http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xml) then that would clearly be related to the IPsecME WG. This means IESG still needs to consider the document and decide whether it comes to conclusion 2 or 3. I.e. the document will still be considered by the IESG. Dan's question asked whether he can publish the RFC without it needing to go through the IESG, and I think for this specific item the answer is no, as there clearly is WG which this work is related to. >> Is there a way to get an RFC published to update this registry that >> does not need to go through the IESG? If not then the 2nd part is >> the critical one; if so then we can just end this fiasco now. I think it would be better (and faster) to solve this here and now, than waste time through the independent submission stream. -- kivinen@iki.fi From turners@ieca.com Mon Oct 22 05:26: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 6E09C21F8B7C for ; Mon, 22 Oct 2012 05:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 BmvoZW4ts+ZL for ; Mon, 22 Oct 2012 05:26:18 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [64.5.38.5]) by ietfa.amsl.com (Postfix) with ESMTP id B6F9821F8B79 for ; Mon, 22 Oct 2012 05:26:18 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 424825DAC67D9; Mon, 22 Oct 2012 07:26:18 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 2EB425DAC6752 for ; Mon, 22 Oct 2012 07:26:18 -0500 (CDT) Received: from [96.241.97.104] (port=52114 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TQH5F-0008JU-QL; Mon, 22 Oct 2012 07:26:18 -0500 Message-ID: <50853B69.8040504@ieca.com> Date: Mon, 22 Oct 2012 08:26:17 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Dan Harkins References: <505C7784.3080803@ieca.com> <190d66e2795aa601c18bf6f6f73058c2.squirrel@www.trepanning.net> <50776898.5010103@ieca.com> <507CA3B4.1070303@ieca.com> <6f873581eff8119db139416e44a0d0d2.squirrel@www.trepanning.net> <508018FC.8020300@ieca.com> <6c2da556f3555c85b87a09df0e440e3d.squirrel@colo.trepanning.net> In-Reply-To: <6c2da556f3555c85b87a09df0e440e3d.squirrel@colo.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.241.97.104]:52114 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= 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: Mon, 22 Oct 2012 12:26:19 -0000 Dan, I've exchange some emails with with Johannes Merkle about adding cipher suites to TLS. What he's agreed to do is to include only three points (BrainpoolP256r1, BrainpoolP384r1, and BrainpoolP512r1) in the draft. spt On 10/19/12 3:20 AM, Dan Harkins wrote: > > Sean, > > It was a two-part request. I'd like the IESG to follow the same process > they followed for what became RFC 5114. > > Is there a way to get an RFC published to update this registry that > does not need to go through the IESG? If not then the 2nd part is > the critical one; if so then we can just end this fiasco now. > > regards, > > Dan. > > On Thu, October 18, 2012 7:58 am, Sean Turner wrote: >> Dan, >> >> There's not need to ask the IESG about the process to update the >> registry in question it's clear: RFC required. You can get an RFC >> through a WG, through an AD, or through the ISE. >> >> spt >> >> On 10/15/12 10:54 PM, Dan Harkins wrote: >>> >>> Hi Sean, >>> >>> On Mon, October 15, 2012 5:00 pm, Sean Turner wrote: >>>> >>>> On 10/12/12 2:32 AM, Dan Harkins wrote: >>>>> >>>>> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: >>>>>> >>>>>> I'm going to run my proposal and Michael's by the IESG on an informal >>>>>> telechat to see which one's got the best chance of getting through >>>>>> the >>>>>> process to resolve the IEEE's request. >>>>> >>>>> Can you ask the IESG to just do what it has done in the past? That >>>>> is, >>>>> just update the registry to include code points for new curves without >>>>> any bizarre notes or pointers? No fuss, no mess, just a few new rows >>>>> in a table. >>>>> >>>>> The worst that could happen if the IESG agrees to do that is that >>>>> someone >>>>> somewhere might use a brainpool curve with IKEv1. The odds are slim, >>>>> but they're not zero. And if that happens then so what? Really. So >>>>> what? >>>> >>>> The RFC 5114 example wasn't published to address another SDO request >>>> for >>>> a code point so I don't think it's the same situation. >>> >>> That's certainly a distinction but I don't see how that matters. You >>> could also >>> note that RFC 5114 added MODP groups as well as ECP groups. Also a >>> distinction that really doesn't matter. >>> >>> Again, the SDO request is a _by-product_ of the opposition to just >>> letting >>> Johannes' draft update the registry. It is this same opposition that is >>> creating >>> these problems about notes and pointers and the concern over whether >>> they >>> will have the desired effect and what we should do to ensure they do. If >>> this >>> opposition had not materialized there never would've been another SDO >>> request. >>> >>> It is the same situation, indulge me here a bit: >>> >>> What we had was another organization (NIST) came up with some new DH >>> groups and there was a proposal to add them to both IKEv1 and IKEv2 >>> registries. And now, quite similarly, there's another organization (the >>> ECC >>> Brainpool) that came up with some new DH groups and there was a proposal >>> to add them to both IKEv1 and IKEv2 registries. >>> >>> When the proposal was made to add the NIST groups to the IKEv1 >>> registry there was no hullabaloo over updating a deprecated protocol's >>> registry and there was no concern that someone somewhere might use >>> the NIST groups with IKEv1. >>> >>> But when Johannes made his proposal to add the ECC Brainpool curves >>> to the IKEv1 registry there was all of a sudden a hullabaloo and much >>> concern that someone somewhere might use the ECC Brainpool groups >>> with IKEv1. >>> >>> So my request to you is to ask that the IESG consider what the >>> process >>> defined for updating this registry is (it's RFC required) and to note >>> that >>> there is precedence to update the registry of this deprecated protocol. >>> So please ask the IESG to just approve a draft (either Johannes' or >>> mine) >>> for publication as an RFC to update this registry in the same manner >>> that >>> RFC 5114 updated it (i.e. no notes, no pointers, no nonsense). >>> >>> Then there'd be no need for the IESG to have a discussion about the >>> (de)merits of notes and pointers in registries and how best to ensure >>> that >>> no one nowhere ever even thinks about using an ECC Brainpool curve in >>> IKEv1 and that certainly sounds like a better use of everyone's time. >>> >>> regards, >>> >>> Dan. >>> >>> >>> >> > > > From mcgrew@cisco.com Mon Oct 22 16:55:29 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E86D21F89F8 for ; Mon, 22 Oct 2012 16:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 sqiJemITh3HG for ; Mon, 22 Oct 2012 16:55:29 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id AC23E21F84D6 for ; Mon, 22 Oct 2012 16:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1232; q=dns/txt; s=iport; t=1350950129; x=1352159729; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=J7al4tLXQNdQXcnGHftRaWAFKMwXlBuEJ3Vso7uH1wo=; b=WOVBUCWiir8Wpl5U5/nq2m0u5iJZmu7kJ4u2YWW056Y408cCGe87BvQa azXx7C5O3JFQ0WKYX5X7eUVk7HTIbQz+IxnTHo4J8hTuvhNP4prf+EL7P fZjr0CRcAdDCJKas+wUu6mgntmRS1voxNnMcNpn86Wd0m1Dp3QyG43xEq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGvchVCtJXG+/2dsb2JhbABEwT+BCIIiAQQBAQEPAQodNAsSASoUNwslAgQBDQUIGodiC5wRoCoEj26BeWADpD+Ba4JiDYIY X-IronPort-AV: E=Sophos;i="4.80,632,1344211200"; d="scan'208";a="134267249" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 22 Oct 2012 23:55:25 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9MNtOJ5021079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 23:55:24 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 18:55:24 -0500 From: "David McGrew (mcgrew)" To: Paul Hoffman , IPsecme WG Thread-Topic: updating ESP and AH requirements (was: [IPsec] Call for agenda items) Thread-Index: AQHNsLCzX8iZ5G5xwU6qUkkx6aDs7w== Date: Mon, 22 Oct 2012 23:55:23 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F502B15@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.229] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--45.008200-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-ID: <5E604E9AFAA05940A0DDB71CE8A241F4@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "wajdi.k.feghali@intel.com" Subject: [IPsec] updating ESP and AH requirements (was: Call for agenda items) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:55:29 -0000 Hi Paul, One thing that deserves to be on the agenda is a discussion of the need to update the ESP and AH crypto requirements, which have not been updated since 2007, and to provide guidance on how to use ESP and AH to achieve security goals. I have a draft proposing what that could look like, draft-mcgrew-ipsec-me-esp-ah-reqts-00. This is off-charter, but I believe that it is something that many people would agree is worth doing. Of course, comments on the detailed requirements are welcome as well. David On 10/17/12 10:38 AM, "Paul Hoffman" wrote: >Greetings again. We have a 2-hour time slot in Atlanta, which is way more >than we asked for. We don't need to be talking about >draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and >is being sent to the AD for review. This is a call for agenda items. >Strong preference is given to those which are in the WG charter. > >draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and hopefully >there will be more discussion of it before the meeting > >--Paul Hoffman >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Mon Oct 22 17:32:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED1911E80A5 for ; Mon, 22 Oct 2012 17:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 UAkgSCFdqZiV for ; Mon, 22 Oct 2012 17:32:04 -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 3E0811F0429 for ; Mon, 22 Oct 2012 17:32:04 -0700 (PDT) Received: from [10.20.30.101] (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 q9N0W14k027419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 22 Oct 2012 17:32: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.2 \(1499\)) From: Paul Hoffman In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F502B15@xmb-rcd-x04.cisco.com> Date: Mon, 22 Oct 2012 17:32:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <08DDF08B-331F-43E7-9957-8624CBF3EE9F@vpnc.org> References: <747787E65E3FBD4E93F0EB2F14DB556B0F502B15@xmb-rcd-x04.cisco.com> To: David McGrew (mcgrew) X-Mailer: Apple Mail (2.1499) Cc: IPsecme WG , "wajdi.k.feghali@intel.com" Subject: Re: [IPsec] updating ESP and AH requirements (was: Call for agenda items) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 00:32:04 -0000 On Oct 22, 2012, at 4:55 PM, David McGrew (mcgrew) = wrote: > One thing that deserves to be on the agenda is a discussion of the = need to > update the ESP and AH crypto requirements, which have not been updated > since 2007, and to provide guidance on how to use ESP and AH to = achieve > security goals. I have a draft proposing what that could look like, > draft-mcgrew-ipsec-me-esp-ah-reqts-00. This is off-charter, but I > believe that it is something that many people would agree is worth = doing. You may be overstating that "many people" agree that it is worth doing, = but it is certainly worth discussing. > Of course, comments on the detailed requirements are welcome as well. Your listing of TripleDES as "SHOULD NOT" without any cryptographic = justification might raise some eyebrows. --Paul Hoffman= From liushucheng@huawei.com Mon Oct 22 20:59: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 B35AA21F843D for ; Mon, 22 Oct 2012 20:59:03 -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 fa5crY8rlZPz for ; Mon, 22 Oct 2012 20:59:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 273E121F843B for ; Mon, 22 Oct 2012 20:59:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKV83087; Tue, 23 Oct 2012 03:59:02 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 04:58:56 +0100 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 04:59:01 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 11:58:57 +0800 From: "Will Liu (Shucheng)" To: "ipsec@ietf.org" Thread-Topic: New Version Notification for draft-zhang-ipsecme-multi-path-ipsec-02.txt Thread-Index: AQHNsGOg1TUH9F/X2026rZRbHDKz6pfGQt/ggAABQ0CAAABPEA== Date: Tue, 23 Oct 2012 03:58:56 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.79.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [IPsec] FW: New Version Notification for draft-zhang-ipsecme-multi-path-ipsec-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 03:59:03 -0000 SGkgYWxsLA0KDQpXZSBoYXZlIG1vZGlmaWVkIG91ciBtdWx0aXBhdGggaXBzZWMgZHJhZnQgYWNj b3JkaW5nIHRvIHNvbWUgb2YgdGhlIGNvbW1lbnRzIGZyb20gdGhlIG1haWwgbGlzdDoNCg0KLSBB ZGRlZCBhIHNlY3Rpb24gdG8gZGlzY3VzcyB0aGUgcmVvcmRlciBpc3N1ZS4NCi0gQ29tcGFyZWQg d2l0aCBTQSwgaW5zdGVhZCBvZiBTQSBidW5kbGUuDQoNCllvdXIgcmV2aWV3IGFuZCBjb21tZW50 cyBhcmUgaGlnaGx5IGFwcHJlY2lhdGVkLiANCg0KV2lsbA0KDQpSZWdhcmRzLA0KU2h1Y2hlbmcg TElVIChXaWxsKQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2Vu dDogTW9uZGF5LCBPY3RvYmVyIDIyLCAyMDEyIDEwOjQ0IFBNDQpUbzogV2lsbCBMaXUgKFNodWNo ZW5nKQ0KQ2M6IFRpbmEgVFNPVTsgdnpoYW5nMjAwOEB5YWhvby5jb20NClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemhhbmctaXBzZWNtZS1tdWx0aS1wYXRoLWlw c2VjLTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aGFuZy1pcHNlY21l LW11bHRpLXBhdGgtaXBzZWMtMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFdpbGwgTGl1IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVu YW1lOgkgZHJhZnQtemhhbmctaXBzZWNtZS1tdWx0aS1wYXRoLWlwc2VjDQpSZXZpc2lvbjoJIDAy DQpUaXRsZToJCSBNdWx0aXBsZSBQYXRoIElQIFNlY3VyaXR5DQpDcmVhdGlvbiBkYXRlOgkgMjAx Mi0xMC0yMg0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6 IDgNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtemhhbmctaXBzZWNtZS1tdWx0aS1wYXRoLWlwc2VjLTAyLnR4dA0KU3RhdHVzOiAgICAg ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLWlwc2VjbWUt bXVsdGktcGF0aC1pcHNlYw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC16aGFuZy1pcHNlY21lLW11bHRpLXBhdGgtaXBzZWMtMDINCkRpZmY6ICAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtemhhbmctaXBzZWNt ZS1tdWx0aS1wYXRoLWlwc2VjLTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBwcmVz ZW50cyBvbmUgYXBwcm9hY2ggdG8gZW5oYW5jZSBkYXRhIHByb3RlY3Rpb24gd2hlbg0KICAgdHJh bnNtaXR0aW5nIElQc2VjIGRhdGFncmFtcyBhY3Jvc3MgdGhlIGluc2VjdXJlIG5ldHdvcmtzLiAg VGhlDQogICBtZXRob2QgYWZmb3JkcyB0aGUgc3Ryb25nZXIgcHJvdGVjdGlvbiB0byB0aGUgdHJh ZmZpYyBieSBzcGxpdHRpbmcgaXQNCiAgIGFtb25nIGEgc2V0IG9mIHN1Yi10dW5uZWxzLiAgQWxs IHRoZSBTZWN1cml0eSBBc3NvY2lhdGlvbnMgKFNBcykgYXJlDQogICBzZXQgdXAgaW5kZXBlbmRl bnRseSBmb3IgYWxsIHN1Yi10dW5uZWxzLiAgQm90aCB0aGUgc2VuZGluZyBhbmQNCiAgIHJlY2Vp dmluZyBlbnRpdHkgY29tYmluZSBhbGwgdGhlIHN1Yi10dW5uZWxzIHRvIG9uZSBjbHVzdGVyZWQg dHVubmVsLg0KICAgQXMgZGlmZmVyZW50IHN1Yi10dW5uZWwgdXNlcyBkaWZmZXJlbnQgY3J5cHRv IGtleSBtYXRlcmlhbHMgYW5kDQogICBwcm9jZXNzaW5nIHBhcmFtZXRlcnMsIGl0IG1heSBhY2hp ZXZlIHRoZSBzdHJvbmdlciBwcm90ZWN0aW9uIG9mIHRoZQ0KICAgdHJhZmZpYyBhY3Jvc3MgdGhl IGluc2VjdXJlIG5ldHdvcmtzLiAgSW4gYWRkaXRpb24sIGl0IGNvdWxkIHBvc3NpYmx5DQogICBi cmluZyBtb3JlIGJlbmVmaXRzIGluIHRlcm1zIG9mIHRoZSBuZXR3b3JrIGNvbnRyb2wuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From liushucheng@huawei.com Mon Oct 22 23:40:29 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F4B21F897C for ; Mon, 22 Oct 2012 23:40:29 -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 WYF57N7a-x0i for ; Mon, 22 Oct 2012 23:40:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFEF21F8504 for ; Mon, 22 Oct 2012 23:40:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKV92695; Tue, 23 Oct 2012 06:40:26 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 07:40:19 +0100 Received: from SZXEML438-HUB.china.huawei.com (10.72.61.73) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 14:40:25 +0800 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml438-hub.china.huawei.com ([10.72.61.73]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 14:40:20 +0800 From: "Will Liu (Shucheng)" To: Paul Hoffman Thread-Topic: [IPsec] Call for agenda items Thread-Index: AQHNrHUiecXvupkEqUaFX8RMV2IQZ5fGeUXA Date: Tue, 23 Oct 2012 06:40:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.79.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPsecme WG Subject: Re: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 06:40:29 -0000 Hi Chair, We'd like to ask for a time slot to present our draft draft-zhang-ipsecme-m= ulti-path-ipsec-02. Thanks. Regards, Will > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Paul Hoffman > Sent: Wednesday, October 17, 2012 10:39 PM > To: IPsecme WG > Subject: [IPsec] Call for agenda items >=20 > Greetings again. We have a 2-hour time slot in Atlanta, which is way more > than we asked for. We don't need to be talking about > draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and i= s > being sent to the AD for review. This is a call for agenda items. Strong > preference is given to those which are in the WG charter. >=20 > draft-ietf-ipsecme-ike-tcp-00 is already on the agenda, and hopefully the= re > will be more discussion of it before the meeting >=20 > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From mcgrew@cisco.com Tue Oct 23 05:37:27 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A29721F86FF for ; Tue, 23 Oct 2012 05:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 L6hhtOjccHZm for ; Tue, 23 Oct 2012 05:37:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6DABC21F86F4 for ; Tue, 23 Oct 2012 05:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1161; q=dns/txt; s=iport; t=1350995846; x=1352205446; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=3aW1xne0UGMbnE9gBg3sEiAfglo48M1TT+ZFMg17YNM=; b=jL61JORJd0lRnI2H4arzJHxWMkfWmuy9emME7kypPo9XRr8F7LfAVFnR UTLgr9twL13YIQ3JDKiQ6PGsWMnG3e6keyfhj8FMlzxuTxCFunmgEj5i0 gjFfZgNVnGZR3FmwS5cBsLPY9ldfU+gb8G9B3kb24ZOd79QpX0WX/MhCB w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD2PhlCtJXG8/2dsb2JhbABEwWWBCIIgAQQSAQodPxIBCCIUQiUCBA4FCBqHYpxJj1yQQItfhX5gA6Q/gWuCb4IY X-IronPort-AV: E=Sophos;i="4.80,634,1344211200"; d="scan'208";a="134445166" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 23 Oct 2012 12:37:10 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9NCb9Gh012081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 12:37:09 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 07:37:09 -0500 From: "David McGrew (mcgrew)" To: Paul Hoffman Thread-Topic: updating ESP and AH requirements (was: [IPsec] Call for agenda items) Thread-Index: AQHNsLCzX8iZ5G5xwU6qUkkx6aDs75fGXhKAgACHiAA= Date: Tue, 23 Oct 2012 12:37:08 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B0F502CA2@xmb-rcd-x04.cisco.com> In-Reply-To: <08DDF08B-331F-43E7-9957-8624CBF3EE9F@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.229] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--37.957800-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-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , "wajdi.k.feghali@intel.com" Subject: Re: [IPsec] updating ESP and AH requirements (was: Call for agenda items) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 12:37:27 -0000 On 10/22/12 8:32 PM, "Paul Hoffman" wrote: >On Oct 22, 2012, at 4:55 PM, David McGrew (mcgrew) >wrote: > >> One thing that deserves to be on the agenda is a discussion of the need >>to >> update the ESP and AH crypto requirements, which have not been updated >> since 2007, and to provide guidance on how to use ESP and AH to achieve >> security goals. I have a draft proposing what that could look like, >> draft-mcgrew-ipsec-me-esp-ah-reqts-00. This is off-charter, but I >> believe that it is something that many people would agree is worth >>doing. > >You may be overstating that "many people" agree that it is worth doing, >but it is certainly worth discussing. > >> Of course, comments on the detailed requirements are welcome as well. > >Your listing of TripleDES as "SHOULD NOT" without any cryptographic >justification might raise some eyebrows. The issue is that 3DES has a 64-bit block instead of a 128-bit block; please see draft-irtf-cfrg-cipher-catalog-01 Section 2.2.3. (In retrospect, there should have been a citation in the draft.) David > >--Paul Hoffman From paul.hoffman@vpnc.org Tue Oct 23 17:01: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 5F46D1F0CB8 for ; Tue, 23 Oct 2012 17:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 8H4+56vP9yCW for ; Tue, 23 Oct 2012 17:01:08 -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 E161D1F0CB1 for ; Tue, 23 Oct 2012 17:01:07 -0700 (PDT) Received: from [10.20.30.101] (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 q9O016Nl073168 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 23 Oct 2012 17:01:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 23 Oct 2012 17:01:06 -0700 To: IPsecme WG Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPsec] Proposed agenda for Atlanta 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, 24 Oct 2012 00:01:08 -0000 Please see . = Suggest changes on the list here. --Paul Hoffman= From kagarigi@cisco.com Tue Oct 23 21:23:18 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DF121F89FD for ; Tue, 23 Oct 2012 21:23:18 -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 JZXdsSue9pZD for ; Tue, 23 Oct 2012 21:23:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D306D21F8931 for ; Tue, 23 Oct 2012 21:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5718; q=dns/txt; s=iport; t=1351052597; x=1352262197; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=4O0jYMFYY7Vq5oveZNFGUEma+4sqADveX431VIS6DGo=; b=kOgYFSRcrhmpdqfUmrw6O4ThGP0R2LpHo0ALl0sVhqcfwKJkasqdkwSK 0fokPhpZPod7RbgHb72WejVJnkK+lGF4s0TbesLZoQ83loHmB2GpI2UK/ az9ldofCGr5SjuHsAHQkddW4YzCBBt71Qxqw8JhDNR4NLn1WLUWbLOa8y g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGVsh1CtJXHA/2dsb2JhbABEwgSBCIIeAQEBBAEBAQ8BJzQXBgEZBAEBAQoUCS4LFAkJAQQTCBqHYguZTIErn3wEi2CFfmADkkCSAIFrgm+CGA X-IronPort-AV: E=Sophos;i="4.80,638,1344211200"; d="scan'208";a="134740298" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 24 Oct 2012 04:23:16 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9O4NFlv023440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Oct 2012 04:23:16 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.131]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 23:23:15 -0500 From: "Kalyani Garigipati (kagarigi)" To: "ipsec@ietf.org" Thread-Topic: ikev2 algorithms, Initiator choice preferred over responder ? Thread-Index: Ac2xn0Z8dOi7ODSYR5WOwXxfPXo3mQ== Date: Wed, 24 Oct 2012 04:23:14 +0000 Message-ID: <52F04C02CB538E4DAAA0B493EBCA4A751349E1C0@xmb-rcd-x11.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.75.240] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--56.144900-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 Subject: [IPsec] ikev2 algorithms, Initiator choice preferred over responder ? 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, 24 Oct 2012 04:23:18 -0000 Hi , If the initiator proposes three algorithms say alg1, alg2. Alg3 for encrypt= ion in SA1. And responders choice is in the order as alg3,alg2,alg1, then finally in S= A_INIT response what should be sent as the algorithm. >From the RFC I felt that it is the initiator choice that should be given pr= eference and so responder MUST send alg1 in response. Or is it that responder MUST be given preference and it MUST send alg3 in r= esponse ? I could not locate any paras in RFC which gives clear guidelines on this. Please let me know if anything like this is already mentioned otherwise I t= hink it should be added in clarifications. Regards, Kalyani -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of S= ean Turner Sent: Monday, October 22, 2012 5:56 PM To: Dan Harkins Cc: ipsec@ietf.org Subject: Re: [IPsec] brainpool summary, suggested way ahead, and comments o= n draft Dan, I've exchange some emails with with Johannes Merkle about adding cipher sui= tes to TLS. What he's agreed to do is to include only three points (Brainp= oolP256r1, BrainpoolP384r1, and BrainpoolP512r1) in the draft. spt On 10/19/12 3:20 AM, Dan Harkins wrote: > > Sean, > > It was a two-part request. I'd like the IESG to follow the same=20 > process they followed for what became RFC 5114. > > Is there a way to get an RFC published to update this registry that=20 > does not need to go through the IESG? If not then the 2nd part is the=20 > critical one; if so then we can just end this fiasco now. > > regards, > > Dan. > > On Thu, October 18, 2012 7:58 am, Sean Turner wrote: >> Dan, >> >> There's not need to ask the IESG about the process to update the=20 >> registry in question it's clear: RFC required. You can get an RFC=20 >> through a WG, through an AD, or through the ISE. >> >> spt >> >> On 10/15/12 10:54 PM, Dan Harkins wrote: >>> >>> Hi Sean, >>> >>> On Mon, October 15, 2012 5:00 pm, Sean Turner wrote: >>>> >>>> On 10/12/12 2:32 AM, Dan Harkins wrote: >>>>> >>>>> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: >>>>>> >>>>>> I'm going to run my proposal and Michael's by the IESG on an=20 >>>>>> informal telechat to see which one's got the best chance of=20 >>>>>> getting through the process to resolve the IEEE's request. >>>>> >>>>> Can you ask the IESG to just do what it has done in the past?=20 >>>>> That is, just update the registry to include code points for new=20 >>>>> curves without any bizarre notes or pointers? No fuss, no mess,=20 >>>>> just a few new rows in a table. >>>>> >>>>> The worst that could happen if the IESG agrees to do that is=20 >>>>> that someone somewhere might use a brainpool curve with IKEv1. The=20 >>>>> odds are slim, but they're not zero. And if that happens then so=20 >>>>> what? Really. So what? >>>> >>>> The RFC 5114 example wasn't published to address another SDO=20 >>>> request for a code point so I don't think it's the same situation. >>> >>> That's certainly a distinction but I don't see how that matters.=20 >>> You could also note that RFC 5114 added MODP groups as well as ECP=20 >>> groups. Also a distinction that really doesn't matter. >>> >>> Again, the SDO request is a _by-product_ of the opposition to=20 >>> just letting Johannes' draft update the registry. It is this same=20 >>> opposition that is creating these problems about notes and pointers=20 >>> and the concern over whether they will have the desired effect and=20 >>> what we should do to ensure they do. If this opposition had not=20 >>> materialized there never would've been another SDO request. >>> >>> It is the same situation, indulge me here a bit: >>> >>> What we had was another organization (NIST) came up with some=20 >>> new DH groups and there was a proposal to add them to both IKEv1 and=20 >>> IKEv2 registries. And now, quite similarly, there's another=20 >>> organization (the ECC >>> Brainpool) that came up with some new DH groups and there was a=20 >>> proposal to add them to both IKEv1 and IKEv2 registries. >>> >>> When the proposal was made to add the NIST groups to the IKEv1=20 >>> registry there was no hullabaloo over updating a deprecated=20 >>> protocol's registry and there was no concern that someone somewhere=20 >>> might use the NIST groups with IKEv1. >>> >>> But when Johannes made his proposal to add the ECC Brainpool=20 >>> curves to the IKEv1 registry there was all of a sudden a hullabaloo=20 >>> and much concern that someone somewhere might use the ECC Brainpool=20 >>> groups with IKEv1. >>> >>> So my request to you is to ask that the IESG consider what the=20 >>> process defined for updating this registry is (it's RFC required)=20 >>> and to note that there is precedence to update the registry of this=20 >>> deprecated protocol. >>> So please ask the IESG to just approve a draft (either Johannes' or >>> mine) >>> for publication as an RFC to update this registry in the same manner=20 >>> that RFC 5114 updated it (i.e. no notes, no pointers, no nonsense). >>> >>> Then there'd be no need for the IESG to have a discussion about=20 >>> the (de)merits of notes and pointers in registries and how best to=20 >>> ensure that no one nowhere ever even thinks about using an ECC=20 >>> Brainpool curve in >>> IKEv1 and that certainly sounds like a better use of everyone's time. >>> >>> regards, >>> >>> Dan. >>> >>> >>> >> > > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From mcr@sandelman.ca Wed Oct 24 16:50:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD39A1F0C88 for ; Wed, 24 Oct 2012 16:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 vj7PpD9KKa2O for ; Wed, 24 Oct 2012 16:50:04 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 10EF41F0C7F for ; Wed, 24 Oct 2012 16:50:04 -0700 (PDT) Received: from sandelman.ca (unknown [75.98.19.132]) by relay.sandelman.ca (Postfix) with ESMTPS id B128281AA; Wed, 24 Oct 2012 19:42:28 -0400 (EDT) Received: from sandelman.ca (quigon.sandelman.ca [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 506C7CA0C6; Wed, 24 Oct 2012 19:50:06 -0400 (EDT) From: Michael Richardson To: "Kalyani Garigipati (kagarigi)" X-Mailer: MH-E 8.3; nmh 1.3; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 24 Oct 2012 19:50:06 -0400 Message-ID: <32300.1351122606@sandelman.ca> Sender: mcr@sandelman.ca Cc: "ipsec@ietf.org" Subject: Re: [IPsec] ikev2 algorithms, Initiator choice preferred over responder ? 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, 24 Oct 2012 23:50:04 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Kalyani Garigipati (kagarigi) wrote: KG> If the initiator proposes three algorithms say alg1, alg2. Alg3 KG> for encryption in SA1. And responders choice is in the order as KG> alg3,alg2,alg1, then finally in SA_INIT response what should be KG> sent as the algorithm. Why would the responder reply with three choices? The spec doesn't say tha= t. It's not a negotiation. If the responder has a preference, it should simply state that one preference in the reply. KG> From the RFC I felt that it is the initiator choice that should KG> be given preference and so responder MUST send alg1 in response. KG> Or is it that responder MUST be given preference and it MUST KG> send alg3 in response ? The responder is free to answer whatever it thinks it should based upon local policy. {in the future, please create a new email rather than replying (and including) another thread in your email. This matters to the list archives. I've removed the in reply-to, references, etc. headers from this email, and I'm including your email below for context} From: "Kalyani Garigipati (kagarigi)" To: "ipsec@ietf.org" Date: Wed, 24 Oct 2012 04:23:14 +0000 x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--56.144900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Subject: [IPsec] ikev2 algorithms, Initiator choice preferred over responder ? Sender: ipsec-bounces@ietf.org Hi , If the initiator proposes three algorithms say alg1, alg2. Alg3 for encrypt= ion in SA1. And responders choice is in the order as alg3,alg2,alg1, then finally in S= A_INIT response what should be sent as the algorithm. From=20the RFC I felt that it is the initiator choice that should be given = preference and so responder MUST send alg1 in response. Or is it that responder MUST be given preference and it MUST send alg3 in r= esponse ? I could not locate any paras in RFC which gives clear guidelines on this. Please let me know if anything like this is already mentioned otherwise I t= hink it should be added in clarifications. Regards, Kalyani =2D-=20 Michael Richardson =2Don the road- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAABAgAGBQJQiH6tAAoJEKD0KQ7Gj3P2L44H/0jN7ZbJhN15XcjsjL2U1t33 DvGg418m0G9hDgyIeY/KEGbRGKYOjeq+bSmwLtw/9abB8iO6m8xnKLVdqvC46pBG vx606u083500zSqzyM5wpGtWMVE3S1bWKfZ7HU7Il0g2IufUYvHEVBC3/dJp5YvF ChbZlWTWg56sotYwru+eSDX0CPF7RCsAaG/FFPp10QrSXmYeEZ4f9RHsQbiQaoGA ilPTg37yvkla5Sz1lUtHI8HpFQIz29FdrfIOEIglYpFDw/JF5i0leDWFgC3VxFnR VD77T5GEFC/43hBRE+gSu/3YcU5v4JNMVo8veNVkl7EjYby0/EcFPmlHTxh4h5E= =Glpt -----END PGP SIGNATURE----- --=-=-=-- From ynir@checkpoint.com Wed Oct 24 23:18:14 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3283321E803F for ; Wed, 24 Oct 2012 23:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.585 X-Spam-Level: X-Spam-Status: No, score=-10.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 0cLa4TlkTw2S for ; Wed, 24 Oct 2012 23:18:13 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0BC21E803A for ; Wed, 24 Oct 2012 23:18:13 -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 q9P6IAhY022723; Thu, 25 Oct 2012 08:18:10 +0200 X-CheckPoint: {5088D784-2-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 25 Oct 2012 08:18:09 +0200 From: Yoav Nir To: "Kalyani Garigipati (kagarigi)" Date: Thu, 25 Oct 2012 08:18:09 +0200 Thread-Topic: [IPsec] ikev2 algorithms, Initiator choice preferred over responder ? Thread-Index: Ac2yeIFBz8Q09FFZTTiNPj48puVbcg== Message-ID: References: <52F04C02CB538E4DAAA0B493EBCA4A751349E1C0@xmb-rcd-x11.cisco.com> In-Reply-To: <52F04C02CB538E4DAAA0B493EBCA4A751349E1C0@xmb-rcd-x11.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] ikev2 algorithms, Initiator choice preferred over responder ? 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, 25 Oct 2012 06:18:14 -0000 Hi Kalyani The spec is silent on how the responder chooses the algorithm from among th= e choices offered by the initiator. It can choose by giving priority to its= own preferences, or by choosing the first proposal that is allowed by its = policy. Since it does not affect interoperability, the RFC does not specify= this. Yoav On Oct 24, 2012, at 6:23 AM, Kalyani Garigipati (kagarigi) wrote: >=20 > Hi , >=20 > If the initiator proposes three algorithms say alg1, alg2. Alg3 for encry= ption in SA1. > And responders choice is in the order as alg3,alg2,alg1, then finally in= SA_INIT response what should be sent as the algorithm. >=20 > From the RFC I felt that it is the initiator choice that should be given = preference and so responder MUST send alg1 in response. > Or is it that responder MUST be given preference and it MUST send alg3 in= response ? >=20 > I could not locate any paras in RFC which gives clear guidelines on this. > Please let me know if anything like this is already mentioned otherwise I= think it should be added in clarifications. >=20 > Regards, > Kalyani From mglt.ietf@gmail.com Thu Oct 25 01:06:14 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A03D21F89B6 for ; Thu, 25 Oct 2012 01:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 Kldgi5H3UN57 for ; Thu, 25 Oct 2012 01:06:14 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0F97421F89B2 for ; Thu, 25 Oct 2012 01:06:14 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 07FA0107400A for ; Thu, 25 Oct 2012 10:09:28 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 03B6C1074001 for ; Thu, 25 Oct 2012 10:09:28 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Oct 2012 10:06:12 +0200 Received: from [10.193.169.114] ([10.193.169.114]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Oct 2012 10:06:12 +0200 Message-ID: <5088F311.2000008@gmail.com> Date: Thu, 25 Oct 2012 10:06:41 +0200 From: daniel migault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: ipsec@ietf.org References: <4877f6a502ed7435b2d0d357431d6ba4.squirrel@www.trepanning.net> <3F23F26B-771F-456D-A98F-AD135CDDE632@vpnc.org> <20609.13069.154699.199014@fireball.kivinen.iki.fi> In-Reply-To: <20609.13069.154699.199014@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Oct 2012 08:06:12.0664 (UTC) FILETIME=[99584380:01CDB287] Subject: Re: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mglt.ietf@gmail.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 08:06:14 -0000 On 10/19/2012 01:01 PM, Tero Kivinen wrote: > Paul Hoffman writes: >> Tero: even though you are taking draft-kivinen-ipsecme-ikev2-minimal >> to the LWIG WG, could you do a similar presentation on the problems >> that your document solves for the IPsecME WG? Yaron and I suspect >> that there is overlap, and having good lists of the similarities and >> differences behind the documents would help the two WGs decide what >> should be in them. > Sure. I just noticed the ipsecme and lwig are both on monday afternoon 17:40 - 19:40. Wouldn't it better these session do not occur at the same time? BR Daniel From kivinen@iki.fi Thu Oct 25 04:05: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 00F3B21F893C for ; Thu, 25 Oct 2012 04:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 h+EgOB7UZJPY for ; Thu, 25 Oct 2012 04:05:33 -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 3004C21F8920 for ; Thu, 25 Oct 2012 04:05:33 -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 q9PB5R9p003189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Oct 2012 14:05:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q9PB5Q6H027949; Thu, 25 Oct 2012 14:05:26 +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: <20617.7413.979388.738655@fireball.kivinen.iki.fi> Date: Thu, 25 Oct 2012 14:05:25 +0300 From: Tero Kivinen To: mglt.ietf@gmail.com In-Reply-To: <5088F311.2000008@gmail.com> References: <4877f6a502ed7435b2d0d357431d6ba4.squirrel@www.trepanning.net> <3F23F26B-771F-456D-A98F-AD135CDDE632@vpnc.org> <20609.13069.154699.199014@fireball.kivinen.iki.fi> <5088F311.2000008@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 11:05:34 -0000 daniel migault writes: > On 10/19/2012 01:01 PM, Tero Kivinen wrote: > > Paul Hoffman writes: > >> Tero: even though you are taking draft-kivinen-ipsecme-ikev2-minimal > >> to the LWIG WG, could you do a similar presentation on the problems > >> that your document solves for the IPsecME WG? Yaron and I suspect > >> that there is overlap, and having good lists of the similarities and > >> differences behind the documents would help the two WGs decide what > >> should be in them. > > Sure. > I just noticed the ipsecme and lwig are both on monday afternoon 17:40 - > 19:40. Wouldn't it better these session do not occur at the same time? Especially as I might need to be in LWIG, as they are considering the draft-kivinen-ipsecme-ikev2-minimal to be accepted as WG draft. I think LWIG was originally on friday but got moved because it was overlapping core or something. -- kivinen@iki.fi From david.black@emc.com Fri Oct 26 13:32:50 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA88721F859E for ; Fri, 26 Oct 2012 13:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 i8J1Q+haYSwD for ; Fri, 26 Oct 2012 13:32:50 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE0B21F84DF for ; Fri, 26 Oct 2012 13:32:49 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9QKWldp011639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Oct 2012 16:32:48 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Fri, 26 Oct 2012 16:32:36 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.222.70.202]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q9QKWZb8002322; Fri, 26 Oct 2012 16:32:35 -0400 Received: from mx15a.corp.emc.com ([169.254.1.83]) by mxhub05.corp.emc.com ([128.222.70.202]) with mapi; Fri, 26 Oct 2012 16:32:35 -0400 From: "Black, David" To: "David McGrew (mcgrew)" , Paul Hoffman Date: Fri, 26 Oct 2012 16:32:34 -0400 Thread-Topic: [IPsec] updating ESP and AH requirements (was: Call for agenda items) Thread-Index: AQHNsLCzX8iZ5G5xwU6qUkkx6aDs75fGXhKAgACHiACABRybIA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE7120E04B46F@MX15A.corp.emc.com> References: <08DDF08B-331F-43E7-9957-8624CBF3EE9F@vpnc.org> <747787E65E3FBD4E93F0EB2F14DB556B0F502CA2@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B0F502CA2@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: IPsecme WG , "wajdi.k.feghali@intel.com" Subject: Re: [IPsec] updating ESP and AH requirements (was: Call for agenda items) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 20:32:51 -0000 Paul Hoffman wrote: > >You may be overstating that "many people" agree that it is worth doing, > >but it is certainly worth discussing. I'm definitely interested in that discussion, as I'm in the midst of an update to the IPsec requirements for iSCSI. David McGrew wrote: > The issue is that 3DES has a 64-bit block instead of a 128-bit block; > please see draft-irtf-cfrg-cipher-catalog-01 Section 2.2.3. (In > retrospect, there should have been a citation in the draft.) That suggests that an explanation of the birthday bound concern along with a discussion of transmission rate and rekeying concerns would be appropriate for the ESP and AH requirements draft, as opposed to a blanket "SHOULD NOT" statement for 3DES. A 1 Gbit/sec link running encrypted at line rate can get to the 4 Gigabyte birthday bound stated in the cfrg draft fairly quickly, but a much slower throughput rate may take much longer before rekeying becomes necessary, if ever (e.g., a remote access session's entire traffic may be measured in 10s of Megabytes or less). Aside - there may be a math error in the draft. For a block size (w) of 64 (i.e., 2^6): - w * 2^(w/2) bits =3D 2^6 * 2^32 bits =3D 2^38 bits - 2^38 bits is 2^35 bytes (byte contains 8=3D2^3 bits) - 2^35 bytes is 2^5 gigabytes (gigabyte contains 2^30 bits). That would be 32 gigabytes, but this aside doesn't change the above discussion, as a 1 Gbit/sec rate will get there in a few minutes, and a 10 Gbit/sec rate will get there in under a minute. Moreover the draft warns (with good reason) that getting close to the birthday bound is not a good idea. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > David McGrew (mcgrew) > Sent: Tuesday, October 23, 2012 8:37 AM > To: Paul Hoffman > Cc: IPsecme WG; wajdi.k.feghali@intel.com > Subject: Re: [IPsec] updating ESP and AH requirements (was: Call for agen= da > items) >=20 >=20 >=20 > On 10/22/12 8:32 PM, "Paul Hoffman" wrote: >=20 > >On Oct 22, 2012, at 4:55 PM, David McGrew (mcgrew) > >wrote: > > > >> One thing that deserves to be on the agenda is a discussion of the nee= d > >>to > >> update the ESP and AH crypto requirements, which have not been updated > >> since 2007, and to provide guidance on how to use ESP and AH to achiev= e > >> security goals. I have a draft proposing what that could look like, > >> draft-mcgrew-ipsec-me-esp-ah-reqts-00. This is off-charter, but I > >> believe that it is something that many people would agree is worth > >>doing. > > > >You may be overstating that "many people" agree that it is worth doing, > >but it is certainly worth discussing. > > > >> Of course, comments on the detailed requirements are welcome as well. > > > >Your listing of TripleDES as "SHOULD NOT" without any cryptographic > >justification might raise some eyebrows. >=20 > The issue is that 3DES has a 64-bit block instead of a 128-bit block; > please see draft-irtf-cfrg-cipher-catalog-01 Section 2.2.3. (In > retrospect, there should have been a citation in the draft.) >=20 > David >=20 > > > >--Paul Hoffman >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Fri Oct 26 14:15: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 8BC8B21F860B for ; Fri, 26 Oct 2012 14:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.588 X-Spam-Level: X-Spam-Status: No, score=-10.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 uU7ulROENm+h for ; Fri, 26 Oct 2012 14:15:48 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9B70721F853C for ; Fri, 26 Oct 2012 14:15:47 -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 q9QLFfQY032429; Fri, 26 Oct 2012 23:15:41 +0200 X-CheckPoint: {508AFB4C-8-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 26 Oct 2012 23:15:40 +0200 Received: from il-ex01.ad.checkpoint.com ([194.29.34.26]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 26 Oct 2012 23:15:40 +0200 From: Yoav Nir To: "Black, David" Date: Fri, 26 Oct 2012 23:15:40 +0200 Thread-Topic: [IPsec] updating ESP and AH requirements (was: Call for agenda items) Thread-Index: Ac2zvwzP8xFMDXAlTlKFB///4gUcEw== Message-ID: References: <08DDF08B-331F-43E7-9957-8624CBF3EE9F@vpnc.org> <747787E65E3FBD4E93F0EB2F14DB556B0F502CA2@xmb-rcd-x04.cisco.com> <8D3D17ACE214DC429325B2B98F3AE7120E04B46F@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120E04B46F@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: IPsecme WG , "David McGrew \(mcgrew\)" Subject: Re: [IPsec] updating ESP and AH requirements (was: Call for agenda items) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 21:15:48 -0000 On Oct 26, 2012, at 10:32 PM, Black, David wrote: > Paul Hoffman wrote: >>> You may be overstating that "many people" agree that it is worth doing, >>> but it is certainly worth discussing. >=20 > I'm definitely interested in that discussion, as I'm in the midst of > an update to the IPsec requirements for iSCSI. Me too (interested in that discussion, not updating an iSCSI document) > David McGrew wrote: >> The issue is that 3DES has a 64-bit block instead of a 128-bit block; >> please see draft-irtf-cfrg-cipher-catalog-01 Section 2.2.3. (In >> retrospect, there should have been a citation in the draft.) >=20 > That suggests that an explanation of the birthday bound concern > along with a discussion of transmission rate and rekeying concerns > would be appropriate for the ESP and AH requirements draft, as > opposed to a blanket "SHOULD NOT" statement for 3DES. >=20 > A 1 Gbit/sec link running encrypted at line rate can get to the 4 > Gigabyte birthday bound stated in the cfrg draft fairly quickly, but > a much slower throughput rate may take much longer before rekeying > becomes necessary, if ever (e.g., a remote access session's entire > traffic may be measured in 10s of Megabytes or less). >=20 > Aside - there may be a math error in the draft. > For a block size (w) of 64 (i.e., 2^6): >=20 > - w * 2^(w/2) bits =3D 2^6 * 2^32 bits =3D 2^38 bits > - 2^38 bits is 2^35 bytes (byte contains 8=3D2^3 bits) > - 2^35 bytes is 2^5 gigabytes (gigabyte contains 2^30 bits). >=20 > That would be 32 gigabytes, but this aside doesn't change the > above discussion, as a 1 Gbit/sec rate will get there in a few > minutes, and a 10 Gbit/sec rate will get there in under a minute. > Moreover the draft warns (with good reason) that getting close > to the birthday bound is not a good idea. The minutes figure is enough to not warrant a SHOULD NOT. Any machine that'= s capable of sustained 1 Gb/s IPsec should also be capable of rekeying chil= d SAs every minute. In fact, our QA people regularly run a load like that w= ith 1-minute lifetimes for a week just to check if anything bad happens. So it might be appropriate to say how often you need to rekey with the vari= ous algorithms, and it may be correct to say that for extreme cases (a sing= le SA that carries 10 Gb/s sustained rate) 3DES is not appropriate, but thi= s is a far cry from a blanket SHOULD NOT. I have another issue with this recommendation. It leaves only AES variants = as MUST and SHOULD. I would like to have some other algorithm widely implem= ented, so that if we get some really bad (or good - depends on your perspec= tive) cryptographic result against AES, there is something interoperable to= fall back on. As long as we don't have a new algorithm, I'd rather see 3DE= S remain a SHOULD. Yoav= From sfluhrer@cisco.com Fri Oct 26 14:29:04 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EE821F8634 for ; Fri, 26 Oct 2012 14:29:04 -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 XyVxVyvKnPY0 for ; Fri, 26 Oct 2012 14:29:03 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1011621F862D for ; Fri, 26 Oct 2012 14:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2393; q=dns/txt; s=iport; t=1351286943; x=1352496543; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=I6Q6ZQTXRryAUjD8UtBnnCsBEVLV/SX11B822tfdAjU=; b=bIvV8c96nASkRVcruX4hytaXsuGDsu1784xwCgBQ7byOkJ1dKXF19WDi Ff+xZTrD6E2m1bxn9UYigZeqg/cHfqrucyaeuSzNovnPaz+Fh/0GskTwU 7rfe2xJkBDwgGpUAAFcyPhu8kfj9MvxNH4Tc1oKDWclVUj0fN205Q4oHj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIb/ilCtJXG//2dsb2JhbABEwlaBCIIeAQEBAwESAQodPwULAgEIGAoUEDIlAgQBDQ0ah14GnEmgDZF+YQOkRoFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,656,1344211200"; d="scan'208";a="135836794" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 26 Oct 2012 21:29:02 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9QLT2Qn008253 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Oct 2012 21:29:02 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.200]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Fri, 26 Oct 2012 16:29:01 -0500 From: "Scott Fluhrer (sfluhrer)" To: "Black, David" , "David McGrew (mcgrew)" , Paul Hoffman Thread-Topic: [IPsec] updating ESP and AH requirements (was: Call for agenda items) Thread-Index: AQHNsRstogf4PiUoxUq/GjiR+09rOZfMY6oA//+1ocA= Date: Fri, 26 Oct 2012 21:29:01 +0000 Message-ID: References: <08DDF08B-331F-43E7-9957-8624CBF3EE9F@vpnc.org> <747787E65E3FBD4E93F0EB2F14DB556B0F502CA2@xmb-rcd-x04.cisco.com> <8D3D17ACE214DC429325B2B98F3AE7120E04B46F@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7120E04B46F@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.82] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19310.001 x-tm-as-result: No--55.562000-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 , "wajdi.k.feghali@intel.com" Subject: Re: [IPsec] updating ESP and AH requirements (was: Call for agenda items) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 21:29:04 -0000 David Black wrote: > David McGrew wrote: > > The issue is that 3DES has a 64-bit block instead of a 128-bit block; > > please see draft-irtf-cfrg-cipher-catalog-01 Section 2.2.3. (In > > retrospect, there should have been a citation in the draft.) >=20 > That suggests that an explanation of the birthday bound concern > along with a discussion of transmission rate and rekeying concerns > would be appropriate for the ESP and AH requirements draft, as > opposed to a blanket "SHOULD NOT" statement for 3DES. Would a "MAY-" be more appropriate? > A 1 Gbit/sec link running encrypted at line rate can get to the 4 > Gigabyte birthday bound stated in the cfrg draft fairly quickly, The problem is that the "birthday bound" is not a hard boundary, where you'= re perfectly safe if you stay below it, and becomes a concern only if you c= ross it. Instead, it's the pointer where the probability where you leak so= me data (specifically, the value of the exclusive-or of two 8 bytes segment= s of plaintext) is fairly good. However, this leakage can occur (with sign= ificantly lower probability) considerably before that. > but > a much slower throughput rate may take much longer before rekeying > becomes necessary, if ever (e.g., a remote access session's entire > traffic may be measured in 10s of Megabytes or less). If we consider a 50Megabyte remote access session encrypted with 3DES, ther= e's approximately a 1 in a million probability that there will be some leak= age (that is, someone going through the transcript will be able to deduce o= f value of the exclusive-or of two 8 byte segments). How bad would it be i= f someone could deduce that comparatively small amount of information? Is = that probability low enough to be acceptable? Well, I don't know if we (the working group) can answer either question; th= ey're far too dependent on what is being protected, and the security goals = of the system. At the best, we could try to document the issues. On the other hand, what are the arguments for keeping 3DES? Ten years ago,= that was the one cipher that everyone implemented, and so it was necessary= for interoperability. However, nowadays, AES-128 appears to fill that rol= e (and also doesn't have the above potential security concern); what reason= would someone now have to implement 3DES rather than AES? From paul.hoffman@vpnc.org Fri Oct 26 14:46:52 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C690E21F862B for ; Fri, 26 Oct 2012 14:46:52 -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 R8uKLEGUv-Ld for ; Fri, 26 Oct 2012 14:46:52 -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 314A921F85D5 for ; Fri, 26 Oct 2012 14:46:52 -0700 (PDT) Received: from [165.227.249.210] (sn81.proper.com [75.101.18.81]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q9QLkjt0024781 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Oct 2012 14:46:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Paul Hoffman In-Reply-To: Date: Fri, 26 Oct 2012 14:46:46 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08DDF08B-331F-43E7-9957-8624CBF3EE9F@vpnc.org> <747787E65E3FBD4E93F0EB2F14DB556B0F502CA2@xmb-rcd-x04.cisco.com> <8D3D17ACE214DC429325B2B98F3AE7120E04B46F@MX15A.corp.emc.com> To: "Scott Fluhrer (sfluhrer)" X-Mailer: Apple Mail (2.1499) Cc: IPsecme WG , "Black, David" , "David McGrew \(mcgrew\)" , "wajdi.k.feghali@intel.com" Subject: Re: [IPsec] updating ESP and AH requirements (was: Call for agenda items) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 21:46:52 -0000 On Oct 26, 2012, at 2:29 PM, "Scott Fluhrer (sfluhrer)" = wrote: > David Black wrote: >=20 >> David McGrew wrote: >>> The issue is that 3DES has a 64-bit block instead of a 128-bit = block; >>> please see draft-irtf-cfrg-cipher-catalog-01 Section 2.2.3. (In >>> retrospect, there should have been a citation in the draft.) >>=20 >> That suggests that an explanation of the birthday bound concern >> along with a discussion of transmission rate and rekeying concerns >> would be appropriate for the ESP and AH requirements draft, as >> opposed to a blanket "SHOULD NOT" statement for 3DES. >=20 > Would a "MAY-" be more appropriate? In my mind, yes. >> A 1 Gbit/sec link running encrypted at line rate can get to the 4 >> Gigabyte birthday bound stated in the cfrg draft fairly quickly, >=20 > The problem is that the "birthday bound" is not a hard boundary, where = you're perfectly safe if you stay below it, and becomes a concern only = if you cross it. Instead, it's the pointer where the probability where = you leak some data (specifically, the value of the exclusive-or of two 8 = bytes segments of plaintext) is fairly good. However, this leakage can = occur (with significantly lower probability) considerably before that. >=20 >> but >> a much slower throughput rate may take much longer before rekeying >> becomes necessary, if ever (e.g., a remote access session's entire >> traffic may be measured in 10s of Megabytes or less). >=20 > If we consider a 50Megabyte remote access session encrypted with 3DES, = there's approximately a 1 in a million probability that there will be = some leakage (that is, someone going through the transcript will be able = to deduce of value of the exclusive-or of two 8 byte segments). How bad = would it be if someone could deduce that comparatively small amount of = information? Is that probability low enough to be acceptable? >=20 > Well, I don't know if we (the working group) can answer either = question; they're far too dependent on what is being protected, and the = security goals of the system. At the best, we could try to document the = issues. Indeed. > On the other hand, what are the arguments for keeping 3DES? Ten years = ago, that was the one cipher that everyone implemented, and so it was = necessary for interoperability. However, nowadays, AES-128 appears to = fill that role (and also doesn't have the above potential security = concern); what reason would someone now have to implement 3DES rather = than AES? It is not a question of implementing new: *all* new systems coming into = the VPNC lab have AES-CBC, and have for a few years. However, if those = implementations want to interoperate with older implementations, they = need to also have 3DES. Thus, a "MAY" for 3DES with a clear explanation = why it is inappropriate in high-volume implementations would be = valuable. --Paul Hoffman= From yaronf.ietf@gmail.com Fri Oct 26 14:56:59 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB3621F866D for ; Fri, 26 Oct 2012 14:56:59 -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 LXZDh2kOoOdX for ; Fri, 26 Oct 2012 14:56:59 -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 3F2D421F864A for ; Fri, 26 Oct 2012 14:56:59 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1458660eek.31 for ; Fri, 26 Oct 2012 14:56:58 -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=RJ8YdboDojSpwMHsoUDYEkLW9IeHUif6zJAYSFC9YxU=; b=x0DkYE5M+I/BtRc5/dmWXJg0O4HLehJEQaoBaiuPrKX7ODcWYek8oBgJy1Dh4lw4is BhL8SSJiVFDJwrhco9GKBI3OFyDthkdQN1eL8dnAVDgrL3kfQMvxX0LeGBNhbBf1Y/5J HKc2KBHK4keO/wmjMZR5nIwxQOXTB+de6scL1FNEPCErzmC0OQm929J9fbomvOXmazME IK8wjIqMups1fLPr1UnigFzHiQ4RfovzMVgxp0/gAnHNISNJMZDN0T7eAjplKzZwRj6V UdPJf+837yM9tkE39DR7ebKW4/nB7lKdw7UgHJyIAy6uDpxJjnCuxOJYpICCFbX/7Wzi ifeg== Received: by 10.14.182.5 with SMTP id n5mr36328140eem.5.1351288618462; Fri, 26 Oct 2012 14:56:58 -0700 (PDT) Received: from [10.0.0.2] (bzq-109-64-178-114.red.bezeqint.net. [109.64.178.114]) by mx.google.com with ESMTPS id 42sm5281775eee.0.2012.10.26.14.56.55 (version=SSLv3 cipher=OTHER); Fri, 26 Oct 2012 14:56:57 -0700 (PDT) Message-ID: <508B071C.1000609@gmail.com> Date: Fri, 26 Oct 2012 23:56:44 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Paul Hoffman References: <08DDF08B-331F-43E7-9957-8624CBF3EE9F@vpnc.org> <747787E65E3FBD4E93F0EB2F14DB556B0F502CA2@xmb-rcd-x04.cisco.com> <8D3D17ACE214DC429325B2B98F3AE7120E04B46F@MX15A.corp.emc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , "Black, David" , "David McGrew \(mcgrew\)" , "wajdi.k.feghali@intel.com" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] updating ESP and AH 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, 26 Oct 2012 21:57:00 -0000 The need to interoperate with older implementations, as well as Yoav's justification of having a widely implemented algorithm as a backup for AES, both seem to argue for keeping 3DES as a MAY or MAY-. I suggest to include a concrete recommendation on rekeying. We could argue the numbers forever, but I think a 1/1,000,000 probability for a single collision is good enough. So we could RECOMMEND a rekey once every 50 MB sent. Thanks, Yaron -- It is not a question of implementing new: *all* new systems coming into the VPNC lab have AES-CBC, and have for a few years. However, if those implementations want to interoperate with older implementations, they need to also have 3DES. Thus, a "MAY" for 3DES with a clear explanation why it is inappropriate in high-volume implementations would be valuable. --Paul Hoffman From paul@cypherpunks.ca Sun Oct 28 17:52: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 1CD8A21F8581 for ; Sun, 28 Oct 2012 17:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[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 a-FRDWfu4nGe for ; Sun, 28 Oct 2012 17:52:11 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCAE21F855F for ; Sun, 28 Oct 2012 17:52:11 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 8FF4882A1D; Sun, 28 Oct 2012 20:51:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8495482A19; Sun, 28 Oct 2012 20:51:24 -0400 (EDT) Date: Sun, 28 Oct 2012 20:51:24 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yoav Nir In-Reply-To: <366E001B-D6D8-4CDF-8E91-CA1F25566104@checkpoint.com> Message-ID: References: <366E001B-D6D8-4CDF-8E91-CA1F25566104@checkpoint.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 , Paul Hoffman Subject: Re: [IPsec] Nudge on discussion of WG work item: IKE over TCP 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, 29 Oct 2012 00:52:12 -0000 On Tue, 16 Oct 2012, Yoav Nir wrote: >> this is not done primarily to avoid administrative filters, I see no >> reason why to go out of our way to make it easy to filter IKE/IPsec. >> If IKE could signal a TCP port along with the IKE_TCP_SUPPORTED payload >> this would allow people so more freedom with running on different ports, >> or even kickstarting IKE over another protocol (instant message, >> whatever). I think the two octets are well spent for this. > > True. But do you think it's a common case, where the responder is behind a filter that drops TCP port 500, but that responder knows of a different port that is open? I suppose the responder could be behind some NAT device with the ability to map a forwarded port on the NAT device. I guess this makes sense. But then you have the initiator opening a connection to a random port. That has a far greater chance of getting filtered on the initiator side (firewalls tend to drop what they don't recognize). > > At least in our firewall, FTP got special treatment - the control connection is monitored to recognize and allow the ports that are used by the data connections, but I don't think we can expect the firewall makers repeat this effort for IKE with random ports. I'm not saying that I want firewall makers to do that. I am saying they protocol should allow me to implement it. I might want to have a machine that listens for IKE on all udp and tcp ports. I'm simply asking for an optional method to convey ports. An option most people can leave at just "500" if they only want to do IKE on tcp port 500. >> Should the initiator also send IKE_TCP_SUPPORTED to the responder? The >> initiator/responder roles could switch around at rekey, and it would >> be useful to the initial responder (now initiator) whether or not it >> can or should just start with TCP. Although it could deduce this from >> having received a connection on TCP in the previous exchange. I'm not >> sure on this one. > > I guess, but rekey doesn't require TCP, as it doesn't have the IKE_AUTH exchange. It may be useful so that next time the original responder can begin the Initial exchange with TCP. So can we make this an "initiator MAY also send IKE_TCP_SUPPORTED" ? Paul From paul.hoffman@vpnc.org Mon Oct 29 09:41:13 2012 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9639321F86DB for ; Mon, 29 Oct 2012 09:41:13 -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 LDMBmfihpXWb for ; Mon, 29 Oct 2012 09:41:13 -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 EDA2B21F8661 for ; Mon, 29 Oct 2012 09:41:12 -0700 (PDT) Received: from [10.20.30.101] (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 q9TGfBGF055073 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 29 Oct 2012 09:41:11 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 29 Oct 2012 09:41:11 -0700 References: <20121029163726.18087.12829.idtracker@ietfa.amsl.com> To: IPsecme WG Message-Id: <4BCD4E29-D9B3-4611-B526-06420B0887AE@vpnc.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [IPsec] Fwd: Last Call: (An IKEv2 Extension for Supporting ERP) to Experimental RFC 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, 29 Oct 2012 16:41:13 -0000 Note that IETF Last Call comments on this draft go to ietf@ietf.org (or = iesg@ietf.org), *not* to this mailing list. --Paul Hoffman Begin forwarded message: > From: The IESG > Subject: Last Call: (An IKEv2 Extension = for Supporting ERP) to Experimental RFC > Date: October 29, 2012 9:37:26 AM PDT > To: IETF-Announce > Reply-To: ietf@ietf.org >=20 >=20 > The IESG has received a request from an individual submitter to = consider > the following document: > - 'An IKEv2 Extension for Supporting ERP' > as Experimental RFC >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-11-26. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This document updates the IKEv2 protocol, described in RFC 5996. > This extension allows an IKE Security Association (SA) to be created > and authenticated using the EAP Re-authentication Protocol extension > as described in RFC 6696. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/ballot/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20