From dpquigl@tycho.nsa.gov Mon Aug 2 05:28:10 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11F23A69EB for ; Mon, 2 Aug 2010 05:28:10 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76qS+L13K1JV for ; Mon, 2 Aug 2010 05:28:09 -0700 (PDT) Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by core3.amsl.com (Postfix) with ESMTP id 7C4F43A687D for ; Mon, 2 Aug 2010 05:28:08 -0700 (PDT) Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o72CSVXs013221; Mon, 2 Aug 2010 12:28:32 GMT Received: from [144.51.25.2] (moss-terrapins [144.51.25.2]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o72CSZuS020161; Mon, 2 Aug 2010 08:28:35 -0400 From: "David P. Quigley" To: Paul Moore In-Reply-To: <1280522982.4029.24.camel@flek.lan> References: <4C4FDC80.5020603@oracle.com> <1280522982.4029.24.camel@flek.lan> Content-Type: text/plain Organization: National Security Agency Date: Mon, 02 Aug 2010 08:18:08 -0400 Message-Id: <1280751488.2673.77.camel@moss-terrapins.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, jarrett.lu@oracle.com Subject: Re: [IPsec] a new IKEv2 labeled security draft is published X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 12:28:10 -0000 On Fri, 2010-07-30 at 16:49 -0400, Paul Moore wrote: > On Wed, 2010-07-28 at 00:30 -0700, jarrett.lu@oracle.com wrote: > > A new 00 version of IKEv2 extension for security label has just been > > published: > > > > http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-label-00 > > > > Authors welcome comments from IPsec community. > > Having just read the draft I think it is a bit difficult to perform any > in-depth review without the LFS document (which is described as a work > in progress); there just isn't any real substance in this draft in my > opinion. > What sort of substance are you looking for? The whole point of the LFS document was that we could abstract the actual semantics and format of labeling away and focus on the actual protocol instead. The Labeled IPSec document should be able to be looked at without having to do so in the context of a specific label type. Dave From paul.moore@hp.com Mon Aug 2 06:35:48 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AB433A686A for ; Mon, 2 Aug 2010 06:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmS-7FmT6-LU for ; Mon, 2 Aug 2010 06:35:47 -0700 (PDT) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by core3.amsl.com (Postfix) with ESMTP id 1EBD03A6AE4 for ; Mon, 2 Aug 2010 06:35:43 -0700 (PDT) Received: from g5t0029.atlanta.hp.com (g5t0029.atlanta.hp.com [16.228.8.141]) by g6t0186.atlanta.hp.com (Postfix) with ESMTP id 2CB352C085; Mon, 2 Aug 2010 13:36:10 +0000 (UTC) Received: from ldl (ldl.fc.hp.com [15.11.146.30]) by g5t0029.atlanta.hp.com (Postfix) with ESMTP id E2BA320174; Mon, 2 Aug 2010 13:36:09 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id AA865CF0016; Mon, 2 Aug 2010 07:36:09 -0600 (MDT) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gU68Arl+AE0P; Mon, 2 Aug 2010 07:36:09 -0600 (MDT) Received: from [192.168.0.130] (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id 03095CF000A; Mon, 2 Aug 2010 07:36:08 -0600 (MDT) From: Paul Moore To: "David P. Quigley" In-Reply-To: <1280751488.2673.77.camel@moss-terrapins.epoch.ncsc.mil> References: <4C4FDC80.5020603@oracle.com> <1280522982.4029.24.camel@flek.lan> <1280751488.2673.77.camel@moss-terrapins.epoch.ncsc.mil> Content-Type: text/plain; charset="us-ascii" Organization: Hewlett-Packard Date: Mon, 02 Aug 2010 09:36:08 -0400 Message-ID: <1280756168.3998.8.camel@flek.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, jarrett.lu@oracle.com Subject: Re: [IPsec] a new IKEv2 labeled security draft is published X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 13:35:48 -0000 On Mon, 2010-08-02 at 08:18 -0400, David P. Quigley wrote: > On Fri, 2010-07-30 at 16:49 -0400, Paul Moore wrote: > > On Wed, 2010-07-28 at 00:30 -0700, jarrett.lu@oracle.com wrote: > > > A new 00 version of IKEv2 extension for security label has just been > > > published: > > > > > > http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-label-00 > > > > > > Authors welcome comments from IPsec community. > > > > Having just read the draft I think it is a bit difficult to perform any > > in-depth review without the LFS document (which is described as a work > > in progress); there just isn't any real substance in this draft in my > > opinion. > > What sort of substance are you looking for? The whole point of the LFS > document was that we could abstract the actual semantics and format of > labeling away and focus on the actual protocol instead. The Labeled > IPSec document should be able to be looked at without having to do so in > the context of a specific label type. Basically I'm looking for the kind of substance that one could use to implement the protocol; reading this draft I just don't have that information. Perhaps the best example is in section 4.1, "Attribute Negotiation"; there is only some very vague text about failing negotiations if the label format is unrecognized, no concrete details about how to deal with recognized label formats with invalid and/or unauthorized labels. I could go on, but hopefully this is enough to demonstrate my point. -- paul moore linux @ hp From dpquigl@tycho.nsa.gov Mon Aug 2 06:47:30 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958483A6AD9 for ; Mon, 2 Aug 2010 06:47:30 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzI7oxjiGTJT for ; Mon, 2 Aug 2010 06:47:29 -0700 (PDT) Received: from msux-gh1-uea02.nsa.gov (msux-gh1-uea02.nsa.gov [63.239.65.40]) by core3.amsl.com (Postfix) with ESMTP id 4EDE83A6AC7 for ; Mon, 2 Aug 2010 06:47:29 -0700 (PDT) Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea02.nsa.gov (8.12.10/8.12.10) with ESMTP id o72Dm3Q1023861; Mon, 2 Aug 2010 13:48:03 GMT Received: from [144.51.25.2] (moss-terrapins [144.51.25.2]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o72DlrbD027315; Mon, 2 Aug 2010 09:47:53 -0400 From: "David P. Quigley" To: Paul Moore In-Reply-To: <1280756168.3998.8.camel@flek.lan> References: <4C4FDC80.5020603@oracle.com> <1280522982.4029.24.camel@flek.lan> <1280751488.2673.77.camel@moss-terrapins.epoch.ncsc.mil> <1280756168.3998.8.camel@flek.lan> Content-Type: text/plain Organization: National Security Agency Date: Mon, 02 Aug 2010 09:37:28 -0400 Message-Id: <1280756248.2673.92.camel@moss-terrapins.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, jarrett.lu@oracle.com Subject: Re: [IPsec] a new IKEv2 labeled security draft is published X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 13:47:30 -0000 On Mon, 2010-08-02 at 09:36 -0400, Paul Moore wrote: > On Mon, 2010-08-02 at 08:18 -0400, David P. Quigley wrote: > > On Fri, 2010-07-30 at 16:49 -0400, Paul Moore wrote: > > > On Wed, 2010-07-28 at 00:30 -0700, jarrett.lu@oracle.com wrote: > > > > A new 00 version of IKEv2 extension for security label has just been > > > > published: > > > > > > > > http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-label-00 > > > > > > > > Authors welcome comments from IPsec community. > > > > > > Having just read the draft I think it is a bit difficult to perform any > > > in-depth review without the LFS document (which is described as a work > > > in progress); there just isn't any real substance in this draft in my > > > opinion. > > > > What sort of substance are you looking for? The whole point of the LFS > > document was that we could abstract the actual semantics and format of > > labeling away and focus on the actual protocol instead. The Labeled > > IPSec document should be able to be looked at without having to do so in > > the context of a specific label type. > > Basically I'm looking for the kind of substance that one could use to > implement the protocol; reading this draft I just don't have that > information. Perhaps the best example is in section 4.1, "Attribute > Negotiation"; there is only some very vague text about failing > negotiations if the label format is unrecognized, no concrete details > about how to deal with recognized label formats with invalid and/or > unauthorized labels. I could go on, but hopefully this is enough to > demonstrate my point. The point of bringing this to the list for discussion is for issue like this to come to the surface so I would ask that you give an extensive list of comments. Handling unauthorized labels has nothing to do with the LFS work so it is definitely something worth bringing to light. Now the question is that kind of information would be something traditionally given in the Security Architecture document. When I was talking with Paul Hoffman about the Labeled IPSec document he said that we should remove information that is traditionally associated with the SA document as his assertion was if you're using security labels you already know how to use them. He was of the belief that this document should just be the protocol information and security labels and their usage are not important for this document. Dave From paul.moore@hp.com Mon Aug 2 07:12:00 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60AE63A6B1F for ; Mon, 2 Aug 2010 07:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bgeVMdu-IJN for ; Mon, 2 Aug 2010 07:11:58 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id AA11E3A6855 for ; Mon, 2 Aug 2010 07:11:58 -0700 (PDT) Received: from g4t0018.houston.hp.com (g4t0018.houston.hp.com [16.234.32.27]) by g4t0017.houston.hp.com (Postfix) with ESMTP id 16FC73818E; Mon, 2 Aug 2010 14:12:26 +0000 (UTC) Received: from ldl (ldl.fc.hp.com [15.11.146.30]) by g4t0018.houston.hp.com (Postfix) with ESMTP id C4BF3100D2; Mon, 2 Aug 2010 14:12:25 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id 9C2AFCF0016; Mon, 2 Aug 2010 08:12:25 -0600 (MDT) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IY6wwLF7pgSV; Mon, 2 Aug 2010 08:12:25 -0600 (MDT) Received: from [192.168.0.130] (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id DC839CF000A; Mon, 2 Aug 2010 08:12:24 -0600 (MDT) From: Paul Moore To: "David P. Quigley" In-Reply-To: <1280756248.2673.92.camel@moss-terrapins.epoch.ncsc.mil> References: <4C4FDC80.5020603@oracle.com> <1280522982.4029.24.camel@flek.lan> <1280751488.2673.77.camel@moss-terrapins.epoch.ncsc.mil> <1280756168.3998.8.camel@flek.lan> <1280756248.2673.92.camel@moss-terrapins.epoch.ncsc.mil> Content-Type: text/plain; charset="us-ascii" Organization: Hewlett-Packard Date: Mon, 02 Aug 2010 10:12:24 -0400 Message-ID: <1280758344.3998.23.camel@flek.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, jarrett.lu@oracle.com Subject: Re: [IPsec] a new IKEv2 labeled security draft is published X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 14:12:00 -0000 On Mon, 2010-08-02 at 09:37 -0400, David P. Quigley wrote: > On Mon, 2010-08-02 at 09:36 -0400, Paul Moore wrote: > > On Mon, 2010-08-02 at 08:18 -0400, David P. Quigley wrote: > > > On Fri, 2010-07-30 at 16:49 -0400, Paul Moore wrote: > > > > On Wed, 2010-07-28 at 00:30 -0700, jarrett.lu@oracle.com wrote: > > > > > A new 00 version of IKEv2 extension for security label has just been > > > > > published: > > > > > > > > > > http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-label-00 > > > > > > > > > > Authors welcome comments from IPsec community. > > > > > > > > Having just read the draft I think it is a bit difficult to perform any > > > > in-depth review without the LFS document (which is described as a work > > > > in progress); there just isn't any real substance in this draft in my > > > > opinion. > > > > > > What sort of substance are you looking for? The whole point of the LFS > > > document was that we could abstract the actual semantics and format of > > > labeling away and focus on the actual protocol instead. The Labeled > > > IPSec document should be able to be looked at without having to do so in > > > the context of a specific label type. > > > > Basically I'm looking for the kind of substance that one could use to > > implement the protocol; reading this draft I just don't have that > > information. Perhaps the best example is in section 4.1, "Attribute > > Negotiation"; there is only some very vague text about failing > > negotiations if the label format is unrecognized, no concrete details > > about how to deal with recognized label formats with invalid and/or > > unauthorized labels. I could go on, but hopefully this is enough to > > demonstrate my point. > > The point of bringing this to the list for discussion is for issue like > this to come to the surface so I would ask that you give an extensive > list of comments. Handling unauthorized labels has nothing to do with > the LFS work so it is definitely something worth bringing to light. I only mentioned your LFS draft because it was referenced a few times in the IKEv2 security label draft and without a copy of the LFS draft it was difficult to determine if it had any additional detail that might help in reviewing the IKE draft. I would encourage you to publish the LFS draft as soon as possible so that we can take a look at both specifications together since the IKE draft does have some reliance on the LFS draft. > Now the question is that kind of information would be something > traditionally given in the Security Architecture document. When I was > talking with Paul Hoffman about the Labeled IPSec document he said that > we should remove information that is traditionally associated with the > SA document as his assertion was if you're using security labels you > already know how to use them. He was of the belief that this document > should just be the protocol information and security labels and their > usage are not important for this document. While leaving large chunks of the protocol out of the specification definitely makes it easier to draft (and review for that matter), it makes me very nervous when people start implementing the specification later down the line as the assumptions you make when developing implementation "A" might not work well with the assumptions I make with developing implementation "B". For something as critical as a security label protocol, this could have very serious repercussions for users. Granted, it is probably foolish (and perhaps not very desirable either) to ask for a specification that completely removes all ambiguity, but I think the IKE security label draft as currently written is far too vague to be useful. Look at the CALIPSO RFC or even the other IPsec/IKE RFCs to see the level of specification detail that, in my opinion, should be present in an IETF RFC. -- paul moore linux @ hp From dpquigl@tycho.nsa.gov Mon Aug 2 07:42:29 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9961F3A6A8E for ; Mon, 2 Aug 2010 07:42: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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j968m7YYcetH for ; Mon, 2 Aug 2010 07:42:28 -0700 (PDT) Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by core3.amsl.com (Postfix) with ESMTP id 1515C3A69D0 for ; Mon, 2 Aug 2010 07:42:28 -0700 (PDT) Received: from tarius.tycho.ncsc.mil (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id o72EgnXs001376; Mon, 2 Aug 2010 14:42:49 GMT Received: from [144.51.25.2] (moss-terrapins [144.51.25.2]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id o72EgsGN032674; Mon, 2 Aug 2010 10:42:54 -0400 From: "David P. Quigley" To: Paul Moore In-Reply-To: <1280758344.3998.23.camel@flek.lan> References: <4C4FDC80.5020603@oracle.com> <1280522982.4029.24.camel@flek.lan> <1280751488.2673.77.camel@moss-terrapins.epoch.ncsc.mil> <1280756168.3998.8.camel@flek.lan> <1280756248.2673.92.camel@moss-terrapins.epoch.ncsc.mil> <1280758344.3998.23.camel@flek.lan> Content-Type: text/plain Organization: National Security Agency Date: Mon, 02 Aug 2010 10:32:29 -0400 Message-Id: <1280759549.2673.102.camel@moss-terrapins.epoch.ncsc.mil> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, jarrett.lu@oracle.com Subject: Re: [IPsec] a new IKEv2 labeled security draft is published X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 14:42:29 -0000 On Mon, 2010-08-02 at 10:12 -0400, Paul Moore wrote: > On Mon, 2010-08-02 at 09:37 -0400, David P. Quigley wrote: > > On Mon, 2010-08-02 at 09:36 -0400, Paul Moore wrote: > > > On Mon, 2010-08-02 at 08:18 -0400, David P. Quigley wrote: > > > > On Fri, 2010-07-30 at 16:49 -0400, Paul Moore wrote: > > > > > On Wed, 2010-07-28 at 00:30 -0700, jarrett.lu@oracle.com wrote: > > > > > > A new 00 version of IKEv2 extension for security label has just been > > > > > > published: > > > > > > > > > > > > http://tools.ietf.org/html/draft-jml-ipsec-ikev2-security-label-00 > > > > > > > > > > > > Authors welcome comments from IPsec community. > > > > > > > > > > Having just read the draft I think it is a bit difficult to perform any > > > > > in-depth review without the LFS document (which is described as a work > > > > > in progress); there just isn't any real substance in this draft in my > > > > > opinion. > > > > > > > > What sort of substance are you looking for? The whole point of the LFS > > > > document was that we could abstract the actual semantics and format of > > > > labeling away and focus on the actual protocol instead. The Labeled > > > > IPSec document should be able to be looked at without having to do so in > > > > the context of a specific label type. > > > > > > Basically I'm looking for the kind of substance that one could use to > > > implement the protocol; reading this draft I just don't have that > > > information. Perhaps the best example is in section 4.1, "Attribute > > > Negotiation"; there is only some very vague text about failing > > > negotiations if the label format is unrecognized, no concrete details > > > about how to deal with recognized label formats with invalid and/or > > > unauthorized labels. I could go on, but hopefully this is enough to > > > demonstrate my point. > > > > The point of bringing this to the list for discussion is for issue like > > this to come to the surface so I would ask that you give an extensive > > list of comments. Handling unauthorized labels has nothing to do with > > the LFS work so it is definitely something worth bringing to light. > > I only mentioned your LFS draft because it was referenced a few times in > the IKEv2 security label draft and without a copy of the LFS draft it > was difficult to determine if it had any additional detail that might > help in reviewing the IKE draft. > > I would encourage you to publish the LFS draft as soon as possible so > that we can take a look at both specifications together since the IKE > draft does have some reliance on the LFS draft. > That's a good idea. I just published the document. You can find it at the link below[1]. I also posted an email about it to the SAAG so hopefully there will be some review from there as well. [1]http://www.ietf.org/id/draft-quigley-label-format-registry-00.txt > > Now the question is that kind of information would be something > > traditionally given in the Security Architecture document. When I was > > talking with Paul Hoffman about the Labeled IPSec document he said that > > we should remove information that is traditionally associated with the > > SA document as his assertion was if you're using security labels you > > already know how to use them. He was of the belief that this document > > should just be the protocol information and security labels and their > > usage are not important for this document. > > While leaving large chunks of the protocol out of the specification > definitely makes it easier to draft (and review for that matter), it > makes me very nervous when people start implementing the specification > later down the line as the assumptions you make when developing > implementation "A" might not work well with the assumptions I make with > developing implementation "B". For something as critical as a security > label protocol, this could have very serious repercussions for users. > > Granted, it is probably foolish (and perhaps not very desirable either) > to ask for a specification that completely removes all ambiguity, but I > think the IKE security label draft as currently written is far too vague > to be useful. Look at the CALIPSO RFC or even the other IPsec/IKE RFCs > to see the level of specification detail that, in my opinion, should be > present in an IETF RFC. > We are accepting text for the document so if there is something you believe that should be in it such as handling unauthorized labels feel free to write up some text and send it our way. Dave From paul.moore@hp.com Mon Aug 2 08:23:52 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390EA3A6944 for ; Mon, 2 Aug 2010 08:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DU--9NVz94ve for ; Mon, 2 Aug 2010 08:23:51 -0700 (PDT) Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) by core3.amsl.com (Postfix) with ESMTP id 28E9D3A690A for ; Mon, 2 Aug 2010 08:23:51 -0700 (PDT) Received: from g1t0039.austin.hp.com (g1t0039.austin.hp.com [16.236.32.45]) by g1t0028.austin.hp.com (Postfix) with ESMTP id A78661C108; Mon, 2 Aug 2010 15:24:18 +0000 (UTC) Received: from ldl (ldl.fc.hp.com [15.11.146.30]) by g1t0039.austin.hp.com (Postfix) with ESMTP id 5A6603423F; Mon, 2 Aug 2010 15:24:18 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id 2C782CF0016; Mon, 2 Aug 2010 09:24:18 -0600 (MDT) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRA4KftbHMCL; Mon, 2 Aug 2010 09:24:18 -0600 (MDT) Received: from [192.168.0.130] (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id 7B94CCF000A; Mon, 2 Aug 2010 09:24:17 -0600 (MDT) From: Paul Moore To: "David P. Quigley" In-Reply-To: <1280759549.2673.102.camel@moss-terrapins.epoch.ncsc.mil> References: <4C4FDC80.5020603@oracle.com> <1280522982.4029.24.camel@flek.lan> <1280751488.2673.77.camel@moss-terrapins.epoch.ncsc.mil> <1280756168.3998.8.camel@flek.lan> <1280756248.2673.92.camel@moss-terrapins.epoch.ncsc.mil> <1280758344.3998.23.camel@flek.lan> <1280759549.2673.102.camel@moss-terrapins.epoch.ncsc.mil> Content-Type: text/plain; charset="us-ascii" Organization: Hewlett-Packard Date: Mon, 02 Aug 2010 11:24:16 -0400 Message-ID: <1280762656.3998.29.camel@flek.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, jarrett.lu@oracle.com Subject: Re: [IPsec] a new IKEv2 labeled security draft is published X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 15:23:52 -0000 On Mon, 2010-08-02 at 10:32 -0400, David P. Quigley wrote: > On Mon, 2010-08-02 at 10:12 -0400, Paul Moore wrote: > > I would encourage you to publish the LFS draft as soon as possible so > > that we can take a look at both specifications together since the IKE > > draft does have some reliance on the LFS draft. > > That's a good idea. I just published the document. You can find it at > the link below[1]. I also posted an email about it to the SAAG so > hopefully there will be some review from there as well. > > [1]http://www.ietf.org/id/draft-quigley-label-format-registry-00.txt Thank you. > > While leaving large chunks of the protocol out of the specification > > definitely makes it easier to draft (and review for that matter), it > > makes me very nervous when people start implementing the specification > > later down the line as the assumptions you make when developing > > implementation "A" might not work well with the assumptions I make with > > developing implementation "B". For something as critical as a security > > label protocol, this could have very serious repercussions for users. > > > > Granted, it is probably foolish (and perhaps not very desirable either) > > to ask for a specification that completely removes all ambiguity, but I > > think the IKE security label draft as currently written is far too vague > > to be useful. Look at the CALIPSO RFC or even the other IPsec/IKE RFCs > > to see the level of specification detail that, in my opinion, should be > > present in an IETF RFC. > > We are accepting text for the document so if there is something you > believe that should be in it such as handling unauthorized labels feel > free to write up some text and send it our way. Perhaps it would be better for you to document how you would assume the implementation to work with a level of detail similar to the other IKE and CALIPSO RFCs and then we can have another attempt at review? I'm saying this not to be difficult, but rather because I feel that providing the amount of additional text that I feel is needed would be roughly the same as writing a draft in the first place. To be honest, I look at this draft as an abstract for labeled IKE specification, not a draft specification itself. -- paul moore linux @ hp From jarrett.lu@oracle.com Mon Aug 2 09:08:59 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15C713A697B for ; Mon, 2 Aug 2010 09:08:59 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nv4-s7a-rpv for ; Mon, 2 Aug 2010 09:08:58 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id F09703A67E6 for ; Mon, 2 Aug 2010 09:08:57 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o72G9NhJ029464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 2 Aug 2010 16:09:24 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o72DNipA012555; Mon, 2 Aug 2010 16:09:18 GMT Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 477066641280765351; Mon, 02 Aug 2010 09:09:11 -0700 Received: from [192.168.2.101] (/71.202.69.40) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 02 Aug 2010 09:09:10 -0700 Message-ID: <4C56EDBD.6010401@oracle.com> Date: Mon, 02 Aug 2010 09:09:33 -0700 From: Jarrett Lu User-Agent: Thunderbird 2.0.0.21 (X11/20090323) MIME-Version: 1.0 To: Paul Moore References: <4C4FDC80.5020603@oracle.com> <1280522982.4029.24.camel@flek.lan> <1280751488.2673.77.camel@moss-terrapins.epoch.ncsc.mil> <1280756168.3998.8.camel@flek.lan> <1280756248.2673.92.camel@moss-terrapins.epoch.ncsc.mil> <1280758344.3998.23.camel@flek.lan> <1280759549.2673.102.camel@moss-terrapins.epoch.ncsc.mil> <1280762656.3998.29.camel@flek.lan> In-Reply-To: <1280762656.3998.29.camel@flek.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsmt355.oracle.com [141.146.40.155] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4C56EDB2.0170:SCFMA4539814,ss=1,fgs=0 Cc: ipsec@ietf.org, "David P. Quigley" Subject: Re: [IPsec] a new IKEv2 labeled security draft is published X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 16:08:59 -0000 Paul Moore wrote: > On Mon, 2010-08-02 at 10:32 -0400, David P. Quigley wrote: > >> On Mon, 2010-08-02 at 10:12 -0400, Paul Moore wrote: >> >>> I would encourage you to publish the LFS draft as soon as possible so >>> that we can take a look at both specifications together since the IKE >>> draft does have some reliance on the LFS draft. >>> >> That's a good idea. I just published the document. You can find it at >> the link below[1]. I also posted an email about it to the SAAG so >> hopefully there will be some review from there as well. >> >> [1]http://www.ietf.org/id/draft-quigley-label-format-registry-00.txt >> > > Thank you. > > >>> While leaving large chunks of the protocol out of the specification >>> definitely makes it easier to draft (and review for that matter), it >>> makes me very nervous when people start implementing the specification >>> later down the line as the assumptions you make when developing >>> implementation "A" might not work well with the assumptions I make with >>> developing implementation "B". For something as critical as a security >>> label protocol, this could have very serious repercussions for users. >>> >>> Granted, it is probably foolish (and perhaps not very desirable either) >>> to ask for a specification that completely removes all ambiguity, but I >>> think the IKE security label draft as currently written is far too vague >>> to be useful. Look at the CALIPSO RFC or even the other IPsec/IKE RFCs >>> to see the level of specification detail that, in my opinion, should be >>> present in an IETF RFC. >>> >> We are accepting text for the document so if there is something you >> believe that should be in it such as handling unauthorized labels feel >> free to write up some text and send it our way. >> > > Perhaps it would be better for you to document how you would assume the > implementation to work with a level of detail similar to the other IKE > and CALIPSO RFCs and then we can have another attempt at review? I'm > saying this not to be difficult, but rather because I feel that > providing the amount of additional text that I feel is needed would be > roughly the same as writing a draft in the first place. To be honest, I > look at this draft as an abstract for labeled IKE specification, not a > draft specification itself. > I suppose we can add more details / text on label validations and error handling to avoid implementation ambiguities as much as possible. Our intent is to add the label negotiation as a simple extension to IKEv2. It really should be a short document. Thanks. Jarrett From paul.moore@hp.com Mon Aug 2 10:35:45 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0183A698A for ; Mon, 2 Aug 2010 10:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EldNWGyQNvD4 for ; Mon, 2 Aug 2010 10:35:44 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by core3.amsl.com (Postfix) with ESMTP id 6508E3A689D for ; Mon, 2 Aug 2010 10:35:44 -0700 (PDT) Received: from g5t0030.atlanta.hp.com (g5t0030.atlanta.hp.com [16.228.8.142]) by g5t0006.atlanta.hp.com (Postfix) with ESMTP id 77F5FC071; Mon, 2 Aug 2010 17:36:10 +0000 (UTC) Received: from ldl (ldl.fc.hp.com [15.11.146.30]) by g5t0030.atlanta.hp.com (Postfix) with ESMTP id 4F77314056; Mon, 2 Aug 2010 17:36:10 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl (Postfix) with ESMTP id 1A05DCF002E; Mon, 2 Aug 2010 11:36:10 -0600 (MDT) Received: from ldl ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k42d7MI86ZM; Mon, 2 Aug 2010 11:36:10 -0600 (MDT) Received: from [192.168.0.130] (squirrel.fc.hp.com [15.11.146.57]) by ldl (Postfix) with ESMTP id 61AB0CF000A; Mon, 2 Aug 2010 11:36:09 -0600 (MDT) From: Paul Moore To: Jarrett Lu In-Reply-To: <4C56EDBD.6010401@oracle.com> References: <4C4FDC80.5020603@oracle.com> <1280522982.4029.24.camel@flek.lan> <1280751488.2673.77.camel@moss-terrapins.epoch.ncsc.mil> <1280756168.3998.8.camel@flek.lan> <1280756248.2673.92.camel@moss-terrapins.epoch.ncsc.mil> <1280758344.3998.23.camel@flek.lan> <1280759549.2673.102.camel@moss-terrapins.epoch.ncsc.mil> <1280762656.3998.29.camel@flek.lan> <4C56EDBD.6010401@oracle.com> Content-Type: text/plain; charset="us-ascii" Organization: Hewlett-Packard Date: Mon, 02 Aug 2010 13:36:08 -0400 Message-ID: <1280770568.3998.30.camel@flek.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, "David P. Quigley" Subject: Re: [IPsec] a new IKEv2 labeled security draft is published X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 17:35:45 -0000 On Mon, 2010-08-02 at 09:09 -0700, Jarrett Lu wrote: > Paul Moore wrote: > > On Mon, 2010-08-02 at 10:32 -0400, David P. Quigley wrote: > > > >> On Mon, 2010-08-02 at 10:12 -0400, Paul Moore wrote: > >>> While leaving large chunks of the protocol out of the specification > >>> definitely makes it easier to draft (and review for that matter), it > >>> makes me very nervous when people start implementing the specification > >>> later down the line as the assumptions you make when developing > >>> implementation "A" might not work well with the assumptions I make with > >>> developing implementation "B". For something as critical as a security > >>> label protocol, this could have very serious repercussions for users. > >>> > >>> Granted, it is probably foolish (and perhaps not very desirable either) > >>> to ask for a specification that completely removes all ambiguity, but I > >>> think the IKE security label draft as currently written is far too vague > >>> to be useful. Look at the CALIPSO RFC or even the other IPsec/IKE RFCs > >>> to see the level of specification detail that, in my opinion, should be > >>> present in an IETF RFC. > >>> > >> We are accepting text for the document so if there is something you > >> believe that should be in it such as handling unauthorized labels feel > >> free to write up some text and send it our way. > >> > > > > Perhaps it would be better for you to document how you would assume the > > implementation to work with a level of detail similar to the other IKE > > and CALIPSO RFCs and then we can have another attempt at review? I'm > > saying this not to be difficult, but rather because I feel that > > providing the amount of additional text that I feel is needed would be > > roughly the same as writing a draft in the first place. To be honest, I > > look at this draft as an abstract for labeled IKE specification, not a > > draft specification itself. > > > > I suppose we can add more details / text on label validations and error > handling to avoid implementation ambiguities as much as possible. Our > intent is to add the label negotiation as a simple extension to IKEv2. It > really should be a short document. Thanks, I think that should help. -- paul moore linux @ hp From welterk@us.ibm.com Wed Aug 4 10:37:51 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E43C3A6851 for ; Wed, 4 Aug 2010 10:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UrjXPyLa5EaF for ; Wed, 4 Aug 2010 10:37:48 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by core3.amsl.com (Postfix) with ESMTP id 0D42E3A6C02 for ; Wed, 4 Aug 2010 10:36:40 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o74HRHm1023795 for ; Wed, 4 Aug 2010 11:27:17 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o74Hb2iw168422 for ; Wed, 4 Aug 2010 11:37:04 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o74HaoG2008952 for ; Wed, 4 Aug 2010 11:36:50 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o74Hao0h008943 for ; Wed, 4 Aug 2010 11:36:50 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 2F7ED738:645776D5-88257775:005FDC65; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Wed, 4 Aug 2010 10:36:48 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 08/04/2010 11:36:49, Serialize complete at 08/04/2010 11:36:49 Content-Type: multipart/alternative; boundary="=_alternative 0060C03488257775_=" Subject: [IPsec] Question about port floating in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 17:37:51 -0000 This is a multipart message in MIME format. --=_alternative 0060C03488257775_= Content-Type: text/plain; charset="US-ASCII" Suppose the initiator sends the IKE_SA_INIT request including NAT_DETECTION_*_IP payloads with source port 500 and destination port 500 and there is a NAT between the initiator and the responder. The responder detects the NAT. What source and destination port should the responder use when sending the IKE_SA_INIT response? IKEv2bis section 2.23 says: For this reason, even though IKE packets MUST be sent from and to UDP port 500 or 4500, they MUST be accepted coming from any port and responses MUST be sent to the port from whence they came. ... Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec endpoint that discovers a NAT between it and its correspondent (as described below) MUST send all subsequent traffic from port 4500, which NATs should not treat specially (as they might with port 500). Since the responder detected the NAT, it MUST send all subsequent traffic (starting with the IKE_SA_INIT response) with source port 4500. Also, since the response MUST be sent to the port from whence the request came, the IKE_SA_INIT response destination port must be 500. Is this interpretation correct? Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) --=_alternative 0060C03488257775_= Content-Type: text/html; charset="US-ASCII"
Suppose the initiator sends the IKE_SA_INIT request including NAT_DETECTION_*_IP payloads with source port 500 and destination port 500 and there is a NAT between the initiator and the responder.  The responder detects the NAT.  What source and destination port should the responder use when sending the IKE_SA_INIT response?  IKEv2bis section 2.23 says:
   For this
  reason, even though IKE packets MUST be sent from and to UDP port 500
  or 4500, they MUST be accepted coming from any port and responses
  MUST be sent to the port from whence they came.  
   ...
   Port 4500 is reserved for UDP-encapsulated ESP and IKE.  An IPsec
  endpoint that discovers a NAT between it and its correspondent (as
  described below) MUST send all subsequent traffic from port 4500,
  which NATs should not treat specially (as they might with port 500).

Since the responder detected the NAT, it MUST send all subsequent traffic (starting with the IKE_SA_INIT response) with source port 4500.  Also, since the response MUST be sent to the port from whence the request came, the IKE_SA_INIT response destination port must be 500.  

Is this interpretation correct?  

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)
 --=_alternative 0060C03488257775_=-- From dan.mcdonald@oracle.com Wed Aug 4 10:51:42 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6AC3A69E5 for ; Wed, 4 Aug 2010 10:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7R0ir2cNYn3 for ; Wed, 4 Aug 2010 10:51:32 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1A1DE3A67E3 for ; Wed, 4 Aug 2010 10:51:19 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o74HpfFr012464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 Aug 2010 17:51:42 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o745oZcj009176; Wed, 4 Aug 2010 17:51:38 GMT Received: from abhmt009.oracle.com by acsmt355.oracle.com with ESMTP id 466130141280944245; Wed, 04 Aug 2010 10:50:45 -0700 Received: from everywhere.sfbay.sun.com (/71.174.113.16) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 04 Aug 2010 10:50:45 -0700 Date: Wed, 4 Aug 2010 13:50:40 -0400 From: Dan McDonald To: Keith Welter Message-ID: <20100804175040.GH4443@everywhere.sfbay.sun.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Oracle - Solaris Security (hon. Networking) User-Agent: Mutt/1.5.20 (2009-06-14) X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4C59A8AC.024F:SCFMA4539814,ss=1,fgs=0 Cc: ipsec@ietf.org Subject: Re: [IPsec] Question about port floating in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 17:51:42 -0000 > Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec > endpoint that discovers a NAT between it and its correspondent (as > described below) MUST send all subsequent traffic from port 4500, > which NATs should not treat specially (as they might with port 500). > > Since the responder detected the NAT, it MUST send all subsequent traffic > (starting with the IKE_SA_INIT response) with source port 4500. Also, > since the response MUST be sent to the port from whence the request came, > the IKE_SA_INIT response destination port must be 500. > > Is this interpretation correct? The IKE_SA_INIT response destination port must match what the request was. This might mean a port OTHER than 500, though. Consider the behind-the-NAT initiator who gets his/her ports rewritten by said NAT? I'll see something for from . I'll send the reply to . Dan From yaronf.ietf@gmail.com Wed Aug 4 13:39:59 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69A1C3A6A1C for ; Wed, 4 Aug 2010 13:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.374 X-Spam-Level: X-Spam-Status: No, score=-101.374 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YICouROTuJfT for ; Wed, 4 Aug 2010 13:39:58 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id CAF7E3A6A49 for ; Wed, 4 Aug 2010 13:39:57 -0700 (PDT) Received: by eyb7 with SMTP id 7so2414314eyb.31 for ; Wed, 04 Aug 2010 13:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=P5PM2qsjBnm5yLSWRmx37yWTctVT0xB9Ocvgk9YUKxI=; b=bw8GRudPcVu3Zt75oFW9TOUhrYdhRtoaMCU6c+MXxO9rwv3nX6aPuOBEGGUyPzzcWk jA9yYnOWQV/hBTblUq4p+h5o55tYdg8+D+fS5gC+OWkNmlKAwkVs6FsPlRoeJ4/aeaCc 0vxEifvQlruZy4ivUxD9DrlKQQyq3esYSWyuI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=pWKnFT8uf9x5CBacfRjpuftHf4JiuSnPQaG0lqLZMAfH9p26uhX2GNGlQBpiaSsSKA 45hZZ5dIGWTkk87XblfiRlfh7kxV3YEx2I0h2Oio+U2tqL+fMU+zx7w3IEsGpb43nEQF mWM4YDkReFvHrvybpxcNnyIf/00ieqY21Eb4A= Received: by 10.14.36.87 with SMTP id v63mr3906627eea.0.1280954426737; Wed, 04 Aug 2010 13:40:26 -0700 (PDT) Received: from [10.0.0.1] ([109.65.43.240]) by mx.google.com with ESMTPS id z55sm13420428eeh.9.2010.08.04.13.40.23 (version=SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 13:40:24 -0700 (PDT) Message-ID: <4C59D035.50108@gmail.com> Date: Wed, 04 Aug 2010 23:40:21 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: IPsecme WG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Failure detection proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 20:39:59 -0000 In the Maastricht meeting there was just a tiny bit of interest in the failure detection idea (reminder: the goal is to ensure that one peer discovers that the other IKE peer has restarted, within a short time duration, milliseconds instead of minutes). But we didn't see enough interest to justify having this as a WG item. So, one last time: if you think this is a worthwhile idea, regardless of the proposals on the table, please say so publicly. If you speak up, we will expect you to contribute to the selection of the preferred document. If this is of no interest, fine. But if it is an important problem to solve and we don't take it on, we could end up with competing non-WG proposals. Which would be far from ideal. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Wednesday, July 07, 2010 8:03 PM To: IPsecme WG Subject: [IPsec] NUDGE: Starting discussion of failure detection proposals [[ This topic generated a fair amount of discussion in the past; are folks still interested? ]] Greetings again. The WG has one item on our charter that we have barely discussed, namely failure detection. The charter item says that the work item is: >- A standards-track IKEv2 extension that allows an IKE peer to quickly and securely detect that its opposite peer, while currently reachable, has lost its IKEv2/IPsec state. Changes to how the peers recover from this situation are beyond the scope of this work item, as is improving the detection of an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting points. I gave a brief presentation on failure detection at the last IETF meeting in Anaheim. The slides are at , and the following is directly derived from them. The basic problem being covered by the new extension is: - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob crashes - Alice keeps sending ESP to Bob - When Bob finally comes back up, he replies to Alice's ESP with INVALID_SPI notifications - Alice starts sending IKE liveness checks until she is "sure" that the INVALID_SPI responses are not a DoS attack; this could be "several minutes" - Then Alice rekeys Some other problem cases include: - Bob has two gateways in some failover architecture. One gateway goes down, the other gateway detects this and wants to tell Alice to rekey - Bob has a bunch of gateways in some load-balancing or cluster architecture. One gateway is taken down on purpose, and the system wants to tell Alice to rekey - Protocol robustness: Bob's gateway loses the SA without going down Our primary goal is that, as soon as Bob starts sending INVALID_SPI responses to Alice's ESP traffic, Bob and Alice should be able to quickly determine that this is not an attack and therefore they probably want to rekey right away. Note that if Bob and Alice are also using session resumption, they can use that instead of rekeying; however, in the discussion here, we always use "rekey" to mean "rekey or, if appropriate, resume". The proposed extension does not include the actual rekeying, just the context for them to do it now. The WG has seen two proposed solutions, QCD and SIR. The following are brief summaries of the two proposals. In QCD (), Bob gives Alice a secret token in the AUTH exchange, and then puts the token in his INVALID_SPI response as a way to say "this SPI is gone". Bob must remember his tokens across reboots, or derive tokens from a master token that he memorizes across reboots, and Alice must remember the token (or a hash of it) for each SA. In SIR (), Alice sends a new Check_SPI query with a stateless cookie, essentially asking "do you really not know about this SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing is stored on either side, so a man-in-the-middle can attack this to cause an unnecessary rekey just as they can normal IKE. The first task for the WG is to decide which of these two quite different approaches to take. After we have done that, we can then hone the chosen proposal. During earlier discussion of the proposals, the following criteria were mentioned as ones that the WG should consider when thinking about the approaches: - Support for different scenarios (load balancers, active clusters, failover) - Security from man-in-the-middle DoS attacks - Resources used - Intellectual property rights So: please start discussing the two proposals with respect to these criteria or other criteria that are important to you. In a few weeks (hopefully well before the Maastricht meeting), I make a call for consensus and see where it leads us. --Paul Hoffman, Director --VPN Consortium From B22245@freescale.com Wed Aug 4 22:00:49 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1031E3A6969 for ; Wed, 4 Aug 2010 22:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGz5Go7s4RSr for ; Wed, 4 Aug 2010 22:00:44 -0700 (PDT) Received: from DB3EHSOBE006.bigfish.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by core3.amsl.com (Postfix) with ESMTP id 558533A6805 for ; Wed, 4 Aug 2010 22:00:44 -0700 (PDT) Received: from mail74-db3-R.bigfish.com (10.3.81.248) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 8.1.436.0; Thu, 5 Aug 2010 05:01:13 +0000 Received: from mail74-db3 (localhost.localdomain [127.0.0.1]) by mail74-db3-R.bigfish.com (Postfix) with ESMTP id B04EBD01A1 for ; Thu, 5 Aug 2010 05:01:13 +0000 (UTC) X-SpamScore: -37 X-BigFish: VS-37(zz542N1432N9371P853kzz1202hzz1033ILz2dh2a8h61h) X-Spam-TCS-SCL: 0:0 Received: from mail74-db3 (localhost.localdomain [127.0.0.1]) by mail74-db3 (MessageSwitch) id 1280984473178246_9795; Thu, 5 Aug 2010 05:01:13 +0000 (UTC) Received: from DB3EHSMHS012.bigfish.com (unknown [10.3.81.252]) by mail74-db3.bigfish.com (Postfix) with ESMTP id 29C9EB1804D for ; Thu, 5 Aug 2010 05:01:13 +0000 (UTC) Received: from az33egw02.freescale.net (192.88.158.103) by DB3EHSMHS012.bigfish.com (10.3.87.112) with Microsoft SMTP Server (TLS) id 14.0.482.44; Thu, 5 Aug 2010 05:01:12 +0000 Received: from az33smr01.freescale.net (az33smr01.freescale.net [10.64.34.199]) by az33egw02.freescale.net (8.14.3/8.14.3) with ESMTP id o7551ADx021127 for ; Wed, 4 Aug 2010 22:01:10 -0700 (MST) Received: from zin33exm29.fsl.freescale.net (zin33exm29.ap.freescale.net [10.232.192.28]) by az33smr01.freescale.net (8.13.1/8.13.0) with ESMTP id o755CUcw020165 for ; Thu, 5 Aug 2010 00:12:31 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Aug 2010 10:31:06 +0530 Message-ID: <402621A7D69DDA458D0E12F070D1E55F94A87A@zin33exm29.fsl.freescale.net> In-Reply-To: <20100804175040.GH4443@everywhere.sfbay.sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Question about port floating in IKEv2 Thread-Index: Acsz/d1WWaG7qjARQ3imMJKlZdOZywAXGhTA References: <20100804175040.GH4443@everywhere.sfbay.sun.com> From: V Jyothi-B22245 To: "Dan McDonald" , "Keith Welter" X-Reverse-DNS: az33egw02.freescale.net Cc: ipsec@ietf.org Subject: Re: [IPsec] Question about port floating in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 05:00:49 -0000 As the destination port is not changed,=20 NON-ESP marker should not be added to SA-INIT response. Thanks Jyothi -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Dan McDonald Sent: Wednesday, August 04, 2010 11:21 PM To: Keith Welter Cc: ipsec@ietf.org Subject: Re: [IPsec] Question about port floating in IKEv2 > Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec > endpoint that discovers a NAT between it and its correspondent (as > described below) MUST send all subsequent traffic from port 4500, > which NATs should not treat specially (as they might with port 500). >=20 > Since the responder detected the NAT, it MUST send all subsequent=20 > traffic (starting with the IKE_SA_INIT response) with source port=20 > 4500. Also, since the response MUST be sent to the port from whence=20 > the request came, the IKE_SA_INIT response destination port must be 500. >=20 > Is this interpretation correct?=20 The IKE_SA_INIT response destination port must match what the request was. This might mean a port OTHER than 500, though. Consider the behind-the-NAT initiator who gets his/her ports rewritten by said NAT? I'll see something for from . I'll send the reply to . Dan _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From smoonen@us.ibm.com Thu Aug 5 06:31:59 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 713CB3A6B27; Thu, 5 Aug 2010 06:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vks7j2vP5kmG; Thu, 5 Aug 2010 06:31:56 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 83FFD3A6B2D; Thu, 5 Aug 2010 06:31:24 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o75DR1Rb024393; Thu, 5 Aug 2010 07:27:01 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o75DVSMu068594; Thu, 5 Aug 2010 07:31:32 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o75DVOIX000393; Thu, 5 Aug 2010 07:31:24 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o75DVOp6000375; Thu, 5 Aug 2010 07:31:24 -0600 In-Reply-To: <4C59D035.50108@gmail.com> References: <4C59D035.50108@gmail.com> X-KeepSent: 88DFF0A4:2592C261-85257776:0049DC49; type=4; name=$KeepSent To: Yaron Sheffer X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: Scott C Moonen Date: Thu, 5 Aug 2010 09:28:26 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 08/05/2010 07:31:23 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFDE5DFDA5AD98f9e8a93df938690918c0ABBFDE5DFDA5AD9" Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] Failure detection proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 13:31:59 -0000 --0__=0ABBFDE5DFDA5AD98f9e8a93df938690918c0ABBFDE5DFDA5AD9 Content-type: multipart/alternative; Boundary="1__=0ABBFDE5DFDA5AD98f9e8a93df938690918c0ABBFDE5DFDA5AD9" --1__=0ABBFDE5DFDA5AD98f9e8a93df938690918c0ABBFDE5DFDA5AD9 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I think this is an important problem to solve and I'm willing to participate in discussion of the alternatives, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: IPsecme WG Date: 08/04/2010 04:48 PM Subject: [IPsec] Failure detection proposals Sent by: ipsec-bounces@ietf.org In the Maastricht meeting there was just a tiny bit of interest in the failure detection idea (reminder: the goal is to ensure that one peer discovers that the other IKE peer has restarted, within a short time duration, milliseconds instead of minutes). But we didn't see enough interest to justify having this as a WG item. So, one last time: if you= think this is a worthwhile idea, regardless of the proposals on the table, please say so publicly. If you speak up, we will expect you to contribute to the selection of the preferred document. If this is of no interest, fine. But if it is an important problem to solve and we don't take it on, we could end up with competing non-WG proposals. Which would be far from ideal. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Wednesday, July 07, 2010 8:03 PM To: IPsecme WG Subject: [IPsec] NUDGE: Starting discussion of failure detection propos= als [[ This topic generated a fair amount of discussion in the past; are folks still interested? ]] Greetings again. The WG has one item on our charter that we have barely= discussed, namely failure detection. The charter item says that the wor= k item is: >- A standards-track IKEv2 extension that allows an IKE peer to quickly= and securely detect that its opposite peer, while currently reachable, has = lost its IKEv2/IPsec state. Changes to how the peers recover from this situa= tion are beyond the scope of this work item, as is improving the detection o= f an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting points. I gave a brief presentation on failure detection at the last IETF meeting in Anaheim. The slides are at , and the following is directly derived from them. The basic problem being covered by the new extension is: - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob crashes - Alice keeps sending ESP to Bob - When Bob finally comes back up, he replies to Alice's ESP with INVALID_SPI notifications - Alice starts sending IKE liveness checks until she is "sure" that th= e INVALID_SPI responses are not a DoS attack; this could be "several minu= tes" - Then Alice rekeys Some other problem cases include: - Bob has two gateways in some failover architecture. One gateway goes= down, the other gateway detects this and wants to tell Alice to rekey - Bob has a bunch of gateways in some load-balancing or cluster architecture. One gateway is taken down on purpose, and the system want= s to tell Alice to rekey - Protocol robustness: Bob's gateway loses the SA without going down Our primary goal is that, as soon as Bob starts sending INVALID_SPI responses to Alice's ESP traffic, Bob and Alice should be able to quickly determine that this is not an attack and therefore they probabl= y want to rekey right away. Note that if Bob and Alice are also using session resumption, they can use that instead of rekeying; however, in the discussion here, we always use "rekey" to mean "rekey or, if appropriate, resume". The proposed extension does not include the actua= l rekeying, just the context for them to do it now. The WG has seen two proposed solutions, QCD and SIR. The following are brief summaries of the two proposals. In QCD (), Bob gives Alic= e a secret token in the AUTH exchange, and then puts the token in his INVALID_SPI response as a way to say "this SPI is gone". Bob must remember his tokens across reboots, or derive tokens from a master toke= n that he memorizes across reboots, and Alice must remember the token (or= a hash of it) for each SA. In SIR (), Alic= e sends a new Check_SPI query with a stateless cookie, essentially asking= "do you really not know about this SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing= is stored on either side, so a man-in-the-middle can attack this to cause an unnecessary rekey just as they can normal IKE. The first task for the WG is to decide which of these two quite different approaches to take. After we have done that, we can then hone= the chosen proposal. During earlier discussion of the proposals, the following criteria were mentioned as ones that the WG should consider when thinking about the approaches: - Support for different scenarios (load balancers, active clusters, failover) - Security from man-in-the-middle DoS attacks - Resources used - Intellectual property rights So: please start discussing the two proposals with respect to these criteria or other criteria that are important to you. In a few weeks (hopefully well before the Maastricht meeting), I make a call for consensus and see where it leads us. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFDE5DFDA5AD98f9e8a93df938690918c0ABBFDE5DFDA5AD9 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I think this is an important problem to solve and I'm willing to par= ticipate in discussion of the alternatives,

Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen

3D"InactiveYaron Sheffer ---08/= 04/2010 04:48:45 PM---In the Maastricht meeting there was just a tiny b= it of interest in the failure detection idea (remi

From: Yaron = Sheffer <yaronf.ietf@gmail.com>
To: IPsecme = WG <ipsec@ietf.org>
Date: 08/04/= 2010 04:48 PM
Subject: [IP= sec] Failure detection proposals
Sent by: ips= ec-bounces@ietf.org




In the Maastricht meeting there was just a tiny bit of interest in = the
failure detection idea (reminder: the goal is to ensure that one peer <= br> discovers that the other IKE peer has restarted, within a short time duration, milliseconds instead of minutes). But we didn't see enough interest to justify having this as a WG item. So, one last time: if you=
think this is a worthwhile idea, regardless of the proposals on the table, please say so publicly. If you speak up, we will expect you to <= br> contribute to the selection of the preferred document.

If this is of no interest, fine. But if it is an important problem to <= br> solve and we don't take it on, we could end up with competing non-WG proposals. Which would be far from ideal.

Thanks,
Yaron

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
Of Paul Hoffman
Sent: Wednesday, July 07, 2010 8:03 PM
To: IPsecme WG
Subject: [IPsec] NUDGE: Starting discussion of failure detection propos= als

[[ This topic generated a fair amount of discussion in the past; are folks still interested? ]]

Greetings again. The WG has one item on our charter that we have barely=
discussed, namely failure detection. The charter item says that the wor= k
item is:

>- A standards-track IKEv2 extension that allows an IKE peer to quic= kly and securely detect that its opposite peer, while currently reachab= le, has lost its IKEv2/IPsec state. Changes to how the peers recover fr= om this situation are beyond the scope of this work item, as is improvi= ng the detection of an unreachable or dead peer. Ideas from draft-nir-i= ke-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting = points.

I gave a brief presentation on failure detection at the last IETF
meeting in Anaheim. The slides are at
<http://www.ietf.org/proceedings/77/slides/ipsecme-4.pdf>, and the
following is directly derived from them.

The basic problem being covered by the new extension is:
-  Alice and Bob have SAs up and ESP traffic is flowing, but then = Bob
crashes
-  Alice keeps sending ESP to Bob
-  When Bob finally comes back up, he replies to Alice's ESP with =
INVALID_SPI notifications
-  Alice starts sending IKE liveness checks until she is "sur= e" that the
INVALID_SPI responses are not a DoS attack; this could be "several= minutes"
-  Then Alice rekeys

Some other problem cases include:
-  Bob has two gateways in some failover architecture. One gateway= goes
down, the other gateway detects this and wants to tell Alice to rekey -  Bob has a bunch of gateways in some load-balancing or cluster <= br> architecture. One gateway is taken down on purpose, and the system want= s
to tell Alice to rekey
-  Protocol robustness:  Bob's gateway loses the SA without g= oing down

Our primary goal is that, as soon as Bob starts sending INVALID_SPI responses to Alice's ESP traffic, Bob and Alice should be able to
quickly determine that this is not an attack and therefore they probabl= y
want to rekey right away. Note that if Bob and Alice are also using session resumption, they can use that instead of rekeying; however, in =
the discussion here, we always use "rekey" to mean "reke= y or, if
appropriate, resume". The proposed extension does not include the = actual
rekeying, just the context for them to do it now.

The WG has seen two proposed solutions, QCD and SIR. The following are =
brief summaries of the two proposals.

In QCD (<http://tools.ietf.org/html/draft-nir-ike-qcd>), = Bob gives Alice
a secret token in the AUTH exchange, and then puts the token in his INVALID_SPI response as a way to say "this SPI is gone". Bob = must
remember his tokens across reboots, or derive tokens from a master toke= n
that he memorizes across reboots, and Alice must remember the token (or=
a hash of it) for each SA.

In SIR
(<http://tools.ietf.org/id/draft-detienne-ikev2-recovery= -03.txt>), Alice
sends a new Check_SPI query with a stateless cookie, essentially asking=
"do you really not know about this
SPI?"; Bob responds by saying "I'm sure I don't know that SPI= ". Nothing
is stored on either side, so a man-in-the-middle can attack this to cause an unnecessary rekey just as they can normal IKE.

The first task for the WG is to decide which of these two quite
different approaches to take. After we have done that, we can then hone=
the chosen proposal. During earlier discussion of the proposals, the following criteria were mentioned as ones that the WG should consider <= br> when thinking about the approaches:

-  Support for different scenarios (load balancers, active cluster= s,
failover)
-  Security from man-in-the-middle DoS attacks
-  Resources used
-  Intellectual property rights

So: please start discussing the two proposals with respect to these criteria or other criteria that are important to you. In a few weeks (hopefully well before the Maastricht meeting), I make a call for
consensus and see where it leads us.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec

= --1__=0ABBFDE5DFDA5AD98f9e8a93df938690918c0ABBFDE5DFDA5AD9-- --0__=0ABBFDE5DFDA5AD98f9e8a93df938690918c0ABBFDE5DFDA5AD9 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFDE5DFDA5AD98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFDE5DFDA5AD98f9e8a93df938690918c0ABBFDE5DFDA5AD9-- From mcins1@gmail.com Thu Aug 5 07:46:35 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88DA23A6896 for ; Thu, 5 Aug 2010 07:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWtRrktGMaKJ for ; Thu, 5 Aug 2010 07:46:33 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id C2EE43A67DA for ; Thu, 5 Aug 2010 07:46:33 -0700 (PDT) Received: by pzk6 with SMTP id 6so2850917pzk.31 for ; Thu, 05 Aug 2010 07:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=vM/aFzy3zD2Lw+TbQureaT2dSQUh8eHI4MXk4Hb1hKU=; b=XJBMgSuv/Thuy5VUG05JtLucwHibjhllK+AbKiQbAfBhwP6uZoTrphUJPq6lcL38ti MzVquFGHl5pZaKqHeQarf/LX8E+Ubo8VOnW/4j8p0LBTMCaMXeme/T+dTcMiCOTLwWQS efUOIdN51BHxBWxt8NkHFYXQumY6ns0HnMDmA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=QNpetgB0KxgNF8cyVWnfJ+a/qyFlUo0Af9YgjJ7WaMTizHmdF5yy/GsrY+zUSfrFra DTjHQUjD54WpFNSZgRKJoaDM8LC/Qwj65W/zTD7xmFe6aNWmz13zswgbFY80fdzx5NRl HaQSkLnK8HR3NFyTIGFiovnyWFF9mnw7UoJ2I= Received: by 10.114.15.18 with SMTP id 18mr12368044wao.182.1281019609431; Thu, 05 Aug 2010 07:46:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.86.81 with HTTP; Thu, 5 Aug 2010 07:46:29 -0700 (PDT) In-Reply-To: <402621A7D69DDA458D0E12F070D1E55F94A87A@zin33exm29.fsl.freescale.net> References: <20100804175040.GH4443@everywhere.sfbay.sun.com> <402621A7D69DDA458D0E12F070D1E55F94A87A@zin33exm29.fsl.freescale.net> From: Matthew Cini Sarreo Date: Thu, 5 Aug 2010 16:46:29 +0200 Message-ID: To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=001636417b33c85350048d149ee3 Subject: Re: [IPsec] Question about port floating in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 14:46:35 -0000 --001636417b33c85350048d149ee3 Content-Type: text/plain; charset=ISO-8859-1 Only requests are allowed to float ports, responses MUST always be sent to the address and port they were received from. The NAT_DETECTION_*_IP payloads should still be computed using the original ports. For example: IKE_SA_INIT Request: x.x.x.x:501 to n.n.n.n:501. NAT_DETECTION_*_IP uses ports 501. IKE_SA_INIT Response: During parsing, NAT is detected and the responder keeps track of this and which side is behind NAT. n.n.n.n:501 to x.x.x.x:501. NAT_DETECTION_*_IP uses ports 501. IKE_AUTH request: NAT has been discovered by both sides at this point and both sides know who is behind an NAT device. x.x.x.x:4500 to n.n.n.n:4500. NON-ESP marker is included. Etc... Note that port 501 is used to make the point clearer. Reply to the port received from, regardless of what it is. Hope this helps, Matt On 5 August 2010 07:01, V Jyothi-B22245 wrote: > As the destination port is not changed, > NON-ESP marker should not be added to SA-INIT response. > > Thanks > Jyothi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Dan McDonald > Sent: Wednesday, August 04, 2010 11:21 PM > To: Keith Welter > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Question about port floating in IKEv2 > > > Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec > > endpoint that discovers a NAT between it and its correspondent (as > > described below) MUST send all subsequent traffic from port 4500, > > which NATs should not treat specially (as they might with port > 500). > > > > Since the responder detected the NAT, it MUST send all subsequent > > traffic (starting with the IKE_SA_INIT response) with source port > > 4500. Also, since the response MUST be sent to the port from whence > > the request came, the IKE_SA_INIT response destination port must be > 500. > > > > Is this interpretation correct? > > The IKE_SA_INIT response destination port must match what the request > was. > This might mean a port OTHER than 500, though. Consider the > behind-the-NAT initiator who gets his/her ports rewritten by said NAT? > I'll see something for from . I'll send the reply > to . > > Dan > _______________________________________________ > 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 > --001636417b33c85350048d149ee3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Only requests are allowed to float ports, responses MUST always be sent to = the address and port they were received from. The NAT_DETECTION_*_IP payloa= ds should still be computed using the original ports.

For example: IKE_SA_INIT Request:
x.x.x.x:501 to n.n.n.n:501. NAT_DETECTION_*_IP uses= ports 501.

IKE_SA_INIT Response:
During parsing, NAT is detected= and the responder keeps track of this and which side is behind NAT.
n.n.n.n:501 to x.x.x.x:501. NAT_DETECTION_*_IP uses ports 501.

IKE_A= UTH request:
NAT has been discovered by both sides at this point and bot= h sides know who is behind an NAT device.
x.x.x.x:4500=A0 to n.n.n.n:450= 0. NON-ESP marker is included.

Etc...

Note that port 501 is used to make the point clearer. Rep= ly to the port received from, regardless of what it is.

Hope this he= lps,
Matt


On 5 August 2010 07:01, = V Jyothi-B22245 <B22245@freescale.com> wrote:
As the destinatio= n port is not changed,
NON-ESP marker should not be added to SA-INIT response.

Thanks
Jyothi
-----Original Message-----
From: ipsec-bounces@ietf.org = [mailto:ipsec-bounces@ietf.org] On Behalf
Of Dan McDonald
Sent: Wednesday, August 04, 2010 11:21 PM
To: Keith Welter
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Question about port floating in IKEv2

> =A0 =A0Port 4500 is reserved for UDP-encapsulated ESP and IKE. =A0An I= Psec
> =A0 =A0endpoint that discovers a NAT between it and its correspondent = (as
> =A0 =A0described below) MUST send all subsequent traffic from port 450= 0,
> =A0 =A0which NATs should not treat specially (as they might with port<= br> 500).
>
> Since the responder detected the NAT, it MUST send all subsequent
> traffic (starting with the IKE_SA_INIT response) with source port
> 4500. =A0Also, since the response MUST be sent to the port from whence=
> the request came, the IKE_SA_INIT response destination port must be 500.
>
> Is this interpretation correct?

The IKE_SA_INIT response destination port must match what the request
was.
This might mean a port OTHER than 500, though. =A0Consider the
behind-the-NAT initiator who gets his/her ports rewritten by said NAT?
I'll see something for <me, 500> from <them, XXX>. =A0I'= ;ll send the reply
to <them, XXX>.

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


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

--001636417b33c85350048d149ee3-- From welterk@us.ibm.com Thu Aug 5 08:06:49 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC4B3A6B1B for ; Thu, 5 Aug 2010 08:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEA+XX5JuKoE for ; Thu, 5 Aug 2010 08:06:37 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 5AD383A6A7B for ; Thu, 5 Aug 2010 08:06:36 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o75F5A94025840 for ; Thu, 5 Aug 2010 09:05:10 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o75F75fY116488 for ; Thu, 5 Aug 2010 09:07:05 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o75F6tuG012323 for ; Thu, 5 Aug 2010 09:06:55 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o75F6sbx012251 for ; Thu, 5 Aug 2010 09:06:55 -0600 In-Reply-To: References: To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: F6D00524:0656E74D-88257776:0052C198; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Thu, 5 Aug 2010 08:06:54 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 08/05/2010 09:06:55, Serialize complete at 08/05/2010 09:06:55 Content-Type: multipart/alternative; boundary="=_alternative 005306A188257776_=" Subject: Re: [IPsec] Question about port floating in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 15:06:50 -0000 This is a multipart message in MIME format. --=_alternative 005306A188257776_= Content-Type: text/plain; charset="US-ASCII" Thanks Matt, question below. > Message: 4 > Date: Thu, 5 Aug 2010 16:46:29 +0200 > From: Matthew Cini Sarreo > Subject: Re: [IPsec] Question about port floating in IKEv2 > To: ipsec@ietf.org > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Only requests are allowed to float ports, Where is that stated? > responses MUST always be sent to > the address and port they were received from. The NAT_DETECTION_*_IP > payloads should still be computed using the original ports. > > For example: > IKE_SA_INIT Request: > x.x.x.x:501 to n.n.n.n:501. NAT_DETECTION_*_IP uses ports 501. > > IKE_SA_INIT Response: > During parsing, NAT is detected and the responder keeps track of this and > which side is behind NAT. > n.n.n.n:501 to x.x.x.x:501. NAT_DETECTION_*_IP uses ports 501. > > IKE_AUTH request: > NAT has been discovered by both sides at this point and both sides know who > is behind an NAT device. > x.x.x.x:4500 to n.n.n.n:4500. NON-ESP marker is included. > > Etc... > > Note that port 501 is used to make the point clearer. Reply to the port > received from, regardless of what it is. > > Hope this helps, > Matt --=_alternative 005306A188257776_= Content-Type: text/html; charset="US-ASCII"
Thanks Matt, question below.

> Message: 4
> Date: Thu, 5 Aug 2010 16:46:29 +0200
> From: Matthew Cini Sarreo <mcins1@gmail.com>
> Subject: Re: [IPsec] Question about port floating in IKEv2
> To: ipsec@ietf.org
> Message-ID:
>    <AANLkTimPyUGtM84N104acDVPuxTPiCFomV698fofOKG1@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Only requests are allowed to float ports,

Where is that stated?

> responses MUST always be sent to
> the address and port they were received from. The NAT_DETECTION_*_IP
> payloads should still be computed using the original ports.
>
> For example:
> IKE_SA_INIT Request:
> x.x.x.x:501 to n.n.n.n:501. NAT_DETECTION_*_IP uses ports 501.
>
> IKE_SA_INIT Response:
> During parsing, NAT is detected and the responder keeps track of this and
> which side is behind NAT.
> n.n.n.n:501 to x.x.x.x:501. NAT_DETECTION_*_IP uses ports 501.
>
> IKE_AUTH request:
> NAT has been discovered by both sides at this point and both sides know who
> is behind an NAT device.
> x.x.x.x:4500  to n.n.n.n:4500. NON-ESP marker is included.
>
> Etc...
>
> Note that port 501 is used to make the point clearer. Reply to the port
> received from, regardless of what it is.
>
> Hope this helps,
> Matt
 --=_alternative 005306A188257776_=-- From mcins1@gmail.com Thu Aug 5 08:23:33 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 918743A67D1 for ; Thu, 5 Aug 2010 08:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUFUhiQT3NNy for ; Thu, 5 Aug 2010 08:23:32 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 6D21C3A67A2 for ; Thu, 5 Aug 2010 08:23:32 -0700 (PDT) Received: by pxi20 with SMTP id 20so2832352pxi.31 for ; Thu, 05 Aug 2010 08:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=fpp7xrmJOHnvV/sVZnxCTxLHMURSVn9QijKU9C7XOQE=; b=EMNKl2b15Pyx6F9HLCCpEPYu2Gr8gAAHUKnSkWCwWA1IymmfoNbJ+69DfWy74uEN+s WTNP4td2mrNUtP0Ho0WGB1bQXvdkQH81Xh/ieSUiQITUP2YdNMabwhXPJTOuoQHORulu XZe7OYrVQESu7zdy9lu2S8P0yhAhNqbVjUVJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=pyr9WnwCqXOo9hGJW21/4wkJgUQ8BCVyfMrvvkaCHrkK0U1xDLUG9XDqQx5TF0Nvk+ 0TpKAOEonvK0iF19HAm3IeNBepRbMXm77ryyuB2ChnoCxJ/xdoB2leXvM2aH2xoOsXz5 B/TjFXxk+RB/C8mFsRkicljQs7lD+La/chZBE= Received: by 10.142.140.5 with SMTP id n5mr9264778wfd.116.1281021842798; Thu, 05 Aug 2010 08:24:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.86.81 with HTTP; Thu, 5 Aug 2010 08:23:42 -0700 (PDT) In-Reply-To: References: From: Matthew Cini Sarreo Date: Thu, 5 Aug 2010 17:23:42 +0200 Message-ID: To: Keith Welter , ipsec@ietf.org Content-Type: multipart/alternative; boundary=000e0cd2dc00e3cf87048d152348 Subject: Re: [IPsec] Question about port floating in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 15:23:33 -0000 --000e0cd2dc00e3cf87048d152348 Content-Type: text/plain; charset=ISO-8859-1 >From section 2.11 (Address and Port agility) MUST respond to the address and port from which the request was received. >From section 2.33 (NAT Traversal) An initiator can use port 4500 for both IKE and ESP, Also o The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP payloads if present and if they do not match the addresses in the outer packet MUST tunnel all future IKE and ESP packets associated with this IKE SA over UDP port 4500. This implies that only the initiator (of a request) can change the ports as the responder is forced to keep replying using the same port on which the request was received. In the way I understand it, this is not for the original initiator but for the initiator of the next exchange after the IKE_SA_INIT exchange is done. So if the original responder would initiate IKE_AUTH, it is allowed to float to 4500. I might be wrong as the text states the IKE initiator, so it could be that only the original initiator can do this, but if it is so, this might be problematic. Regards, Matt On 5 August 2010 17:06, Keith Welter wrote: > > Thanks Matt, question below. > > > Message: 4 > > Date: Thu, 5 Aug 2010 16:46:29 +0200 > > From: Matthew Cini Sarreo > > > Subject: Re: [IPsec] Question about port floating in IKEv2 > > To: ipsec@ietf.org > > Message-ID: > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > Only requests are allowed to float ports, > > > Where is that stated? > > > responses MUST always be sent to > > the address and port they were received from. The NAT_DETECTION_*_IP > > payloads should still be computed using the original ports. > > > > For example: > > IKE_SA_INIT Request: > > x.x.x.x:501 to n.n.n.n:501. NAT_DETECTION_*_IP uses ports 501. > > > > IKE_SA_INIT Response: > > During parsing, NAT is detected and the responder keeps track of this and > > which side is behind NAT. > > n.n.n.n:501 to x.x.x.x:501. NAT_DETECTION_*_IP uses ports 501. > > > > IKE_AUTH request: > > NAT has been discovered by both sides at this point and both sides know > who > > is behind an NAT device. > > x.x.x.x:4500 to n.n.n.n:4500. NON-ESP marker is included. > > > > Etc... > > > > Note that port 501 is used to make the point clearer. Reply to the port > > received from, regardless of what it is. > > > > Hope this helps, > > Matt > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --000e0cd2dc00e3cf87048d152348 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >From section 2.11 (Address and Port agility)
MUST respond to the address= and port from which the request was received.

From section 2.33 (NA= T Traversal)
An initiator can use port 4500 for both IKE and ESP,

Also
=A0=A0 o=A0 The IKE initiator MUST check the NAT_DETECTION_SOUR= CE_IP or=A0 =A0=A0 NAT_DETECTION_DESTINATION_IP payloads if present and if = they do not match the addresses in the outer packet MUST tunnel all future = IKE and ESP packets associated with this IKE SA over UDP port 4500.

This implies that only the initiator (of a request) can change the port= s as the responder is forced to keep replying using the same port on which = the request was received.

In the way I understand it, this is not fo= r the original initiator but for the initiator of the next exchange after t= he IKE_SA_INIT exchange is done. So if the original responder would initiat= e IKE_AUTH, it is allowed to float to 4500. I might be wrong as the text st= ates the IKE initiator, so it could be that only the original initiator can= do this, but if it is so, this might be problematic.

Regards,
Matt


On 5 August 2010= 17:06, Keith Welter <welterk@us.ibm.com> wrote:

Thanks Matt, question below.

> Message: 4
> Date: Thu, 5 Aug 2010 16:46:29 +0200
> From: Matthew Cini Sarreo <mcins1@gmail.com>

> Subject: Re: [IPsec] Question about port floating in IKEv2
> To: ipsec@ietf.org=
> Message-ID:
> =A0 =A0<AANLkTimPyUGtM84N104acDVPuxTPiCFomV6= 98fofOKG1@mail.gmail.com>
> Content-Type: text/plain; charset=3D"iso-8859-1"

>
> Only requests are allowed to float ports,


Where is that stated?

> responses MUST always be sent to
> the address and port they were received from. The NAT_DETECTION_*_IP > payloads should still be computed using the original ports.
>
> For example:
> IKE_SA_INIT Request:
> x.x.x.x:501 to n.n.n.n:501. NAT_DETECTION_*_IP uses ports 501.
>
> IKE_SA_INIT Response:
> During parsing, NAT is detected and the responder keeps track of this and
> which side is behind NAT.
> n.n.n.n:501 to x.x.x.x:501. NAT_DETECTION_*_IP uses ports 501.
>
> IKE_AUTH request:
> NAT has been discovered by both sides at this point and both sides know who
> is behind an NAT device.
> x.x.x.x:4500 =A0to n.n.n.n:4500. NON-ESP marker is included.
>
> Etc...
>
> Note that port 501 is used to make the point clearer. Reply to the port
> received from, regardless of what it is.
>
> Hope this helps,
> Matt

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


--000e0cd2dc00e3cf87048d152348-- From welterk@us.ibm.com Thu Aug 5 09:11:16 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8FFD3A68CC for ; Thu, 5 Aug 2010 09:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTx5qJbWzmGZ for ; Thu, 5 Aug 2010 09:11:15 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id E9B003A6A6C for ; Thu, 5 Aug 2010 09:11:14 -0700 (PDT) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o75G4NYZ014967 for ; Thu, 5 Aug 2010 10:04:23 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o75GBIEi078052 for ; Thu, 5 Aug 2010 10:11:20 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o75GBEoI028680 for ; Thu, 5 Aug 2010 10:11:14 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o75GBD81028546; Thu, 5 Aug 2010 10:11:13 -0600 In-Reply-To: References: To: Matthew Cini Sarreo , ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 1471797E:8DCF9089-88257776:00580A8E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP3 SHF32 December 02, 2009 From: Keith Welter Message-ID: Date: Thu, 5 Aug 2010 09:11:12 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 08/05/2010 10:11:13, Serialize complete at 08/05/2010 10:11:13 Content-Type: multipart/alternative; boundary="=_alternative 0058E9E888257776_=" Subject: Re: [IPsec] Question about port floating in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 16:11:17 -0000 This is a multipart message in MIME format. --=_alternative 0058E9E888257776_= Content-Type: text/plain; charset="US-ASCII" Thanks again Matt. I was lead astray by this text: Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec endpoint that discovers a NAT between it and its correspondent (as described below) MUST send all subsequent traffic from port 4500, which NATs should not treat specially (as they might with port 500). It seems to me that "all subsequent traffic" contradicts the other text you referred to. Assuming that the intent is that only requests are allowed to float ports then I think this "all subsequent traffic" text is incorrect. I understand that IKEv2bis is on the RFC editor's queue so it is probably too late to modify this text directly. I wonder if anyone else thinks this issue is worth addressing, perhaps as an erratum? Keith Welter IBM z/OS Communications Server Developer 1-415-545-2694 (T/L: 473-2694) Matthew Cini Sarreo wrote on 08/05/2010 08:23:42 AM: > [image removed] > > Re: [IPsec] Question about port floating in IKEv2 > > Matthew Cini Sarreo > > to: > > Keith Welter, ipsec > > 08/05/2010 08:25 AM > > From section 2.11 (Address and Port agility) > MUST respond to the address and port from which the request was received. > > From section 2.33 (NAT Traversal) > An initiator can use port 4500 for both IKE and ESP, > > Also > o The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or > NAT_DETECTION_DESTINATION_IP payloads if present and if they do > not match the addresses in the outer packet MUST tunnel all future > IKE and ESP packets associated with this IKE SA over UDP port 4500. > > This implies that only the initiator (of a request) can change the > ports as the responder is forced to keep replying using the same > port on which the request was received. > > In the way I understand it, this is not for the original initiator > but for the initiator of the next exchange after the IKE_SA_INIT > exchange is done. So if the original responder would initiate > IKE_AUTH, it is allowed to float to 4500. I might be wrong as the > text states the IKE initiator, so it could be that only the original > initiator can do this, but if it is so, this might be problematic. > > Regards, > Matt > > On 5 August 2010 17:06, Keith Welter wrote: > > Thanks Matt, question below. > > > Message: 4 > > Date: Thu, 5 Aug 2010 16:46:29 +0200 > > From: Matthew Cini Sarreo > > > Subject: Re: [IPsec] Question about port floating in IKEv2 > > To: ipsec@ietf.org > > Message-ID: > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > Only requests are allowed to float ports, > > > Where is that stated? > > > responses MUST always be sent to > > the address and port they were received from. The NAT_DETECTION_*_IP > > payloads should still be computed using the original ports. > > > > For example: > > IKE_SA_INIT Request: > > x.x.x.x:501 to n.n.n.n:501. NAT_DETECTION_*_IP uses ports 501. > > > > IKE_SA_INIT Response: > > During parsing, NAT is detected and the responder keeps track of this and > > which side is behind NAT. > > n.n.n.n:501 to x.x.x.x:501. NAT_DETECTION_*_IP uses ports 501. > > > > IKE_AUTH request: > > NAT has been discovered by both sides at this point and both sides know who > > is behind an NAT device. > > x.x.x.x:4500 to n.n.n.n:4500. NON-ESP marker is included. > > > > Etc... > > > > Note that port 501 is used to make the point clearer. Reply to the port > > received from, regardless of what it is. > > > > Hope this helps, > > Matt > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --=_alternative 0058E9E888257776_= Content-Type: text/html; charset="US-ASCII"
Thanks again Matt.

I was lead astray by this text:
   Port 4500 is reserved for UDP-encapsulated ESP and IKE.  An IPsec
  endpoint that discovers a NAT between it and its correspondent (as
  described below) MUST send all subsequent traffic from port 4500,
  which NATs should not treat specially (as they might with port 500).
It seems to me that "all subsequent traffic" contradicts the other text you referred to.  Assuming that the intent is that only requests are allowed to float ports then I think this "all subsequent traffic" text is incorrect.

I understand that IKEv2bis is on the RFC editor's queue so it is probably too late to modify this text directly.  I wonder if anyone else thinks this issue is worth addressing, perhaps as an erratum?

Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)

Matthew Cini Sarreo <mcins1@gmail.com> wrote on 08/05/2010 08:23:42 AM:

> [image removed]
>
> Re: [IPsec] Question about port floating in IKEv2
>
> Matthew Cini Sarreo
>
> to:
>
> Keith Welter, ipsec
>
> 08/05/2010 08:25 AM
>
> From section 2.11 (Address and Port agility)
> MUST respond to the address and port from which the request was received.
>
> From section 2.33 (NAT Traversal)
> An initiator can use port 4500 for both IKE and ESP,
>
> Also
>    o  The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or 
>    NAT_DETECTION_DESTINATION_IP payloads if present and if they do
> not match the addresses in the outer packet MUST tunnel all future
> IKE and ESP packets associated with this IKE SA over UDP port 4500.
>
> This implies that only the initiator (of a request) can change the
> ports as the responder is forced to keep replying using the same
> port on which the request was received.
>
> In the way I understand it, this is not for the original initiator
> but for the initiator of the next exchange after the IKE_SA_INIT
> exchange is done. So if the original responder would initiate
> IKE_AUTH, it is allowed to float to 4500. I might be wrong as the
> text states the IKE initiator, so it could be that only the original
> initiator can do this, but if it is so, this might be problematic.
>
> Regards,
> Matt
>

> On 5 August 2010 17:06, Keith Welter <welterk@us.ibm.com> wrote:
>
> Thanks Matt, question below.
>
> > Message: 4
> > Date: Thu, 5 Aug 2010 16:46:29 +0200
> > From: Matthew Cini Sarreo <mcins1@gmail.com>
>
> > Subject: Re: [IPsec] Question about port floating in IKEv2
> > To: ipsec@ietf.org
> > Message-ID:
> >    <AANLkTimPyUGtM84N104acDVPuxTPiCFomV698fofOKG1@mail.gmail.com>
> > Content-Type: text/plain; charset="iso-8859-1"
>
> >
> > Only requests are allowed to float ports,
>
>
> Where is that stated?
>
> > responses MUST always be sent to
> > the address and port they were received from. The NAT_DETECTION_*_IP
> > payloads should still be computed using the original ports.
> >
> > For example:
> > IKE_SA_INIT Request:
> > x.x.x.x:501 to n.n.n.n:501. NAT_DETECTION_*_IP uses ports 501.
> >
> > IKE_SA_INIT Response:
> > During parsing, NAT is detected and the responder keeps track of this and
> > which side is behind NAT.
> > n.n.n.n:501 to x.x.x.x:501. NAT_DETECTION_*_IP uses ports 501.
> >
> > IKE_AUTH request:
> > NAT has been discovered by both sides at this point and both sides know who
> > is behind an NAT device.
> > x.x.x.x:4500  to n.n.n.n:4500. NON-ESP marker is included.
> >
> > Etc...
> >
> > Note that port 501 is used to make the point clearer. Reply to the port
> > received from, regardless of what it is.
> >
> > Hope this helps,
> > Matt
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
 --=_alternative 0058E9E888257776_=-- From ynir@checkpoint.com Thu Aug 5 13:18:27 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67D5C3A6881 for ; Thu, 5 Aug 2010 13:18:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.692 X-Spam-Level: X-Spam-Status: No, score=-2.692 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giFOZ--8q8uH for ; Thu, 5 Aug 2010 13:18:26 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id D1A5F3A68B2 for ; Thu, 5 Aug 2010 13:18:22 -0700 (PDT) X-CheckPoint: {4C5B2804-0-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o75KIpDq001760; Thu, 5 Aug 2010 23:18:51 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 5 Aug 2010 23:19:22 +0300 From: Yoav Nir To: Yaron Sheffer Date: Thu, 5 Aug 2010 23:19:22 +0300 Thread-Topic: [IPsec] Failure detection proposals Thread-Index: Acs0232k74V9+Qq7S/mkwnsiFZGcfA== Message-ID: <083B56D1-92E0-4259-A2B2-69FD3296559D@checkpoint.com> References: <4C59D035.50108@gmail.com> In-Reply-To: <4C59D035.50108@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] Failure detection proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 20:18:27 -0000 On Aug 4, 2010, at 11:40 PM, Yaron Sheffer wrote: > In the Maastricht meeting there was just a tiny bit of interest in the=20 > failure detection idea (reminder: the goal is to ensure that one peer=20 > discovers that the other IKE peer has restarted, within a short time=20 > duration, milliseconds instead of minutes). But we didn't see enough=20 > interest to justify having this as a WG item. So, one last time: if you=20 > think this is a worthwhile idea, regardless of the proposals on the=20 > table, please say so publicly. If you speak up, we will expect you to=20 > contribute to the selection of the preferred document. I think it comes as no surprise that I think it's a worthwhile idea, and th= at I am willing to contribute to the selection. The idea for this came to m= e not out of idle analysis of the IKEv2 RFC, but from a bug report from my = company's QA department ("it takes 2 minutes for the tunnel to come back up= after we clear the SAs") > If this is of no interest, fine. But if it is an important problem to=20 > solve and we don't take it on, we could end up with competing non-WG=20 > proposals. Which would be far from ideal. We are already there with competing non-WG proposals. I think it is the IPs= ecME working group that should decide between them. The alternative to the = working group deciding this is to dump this in the AD's lap, which IMHO is = worse.=20 From mcins1@gmail.com Thu Aug 5 13:56:35 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F32F03A67A4 for ; Thu, 5 Aug 2010 13:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q33ExdLKXS-J for ; Thu, 5 Aug 2010 13:56:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B60E63A6864 for ; Thu, 5 Aug 2010 13:56:29 -0700 (PDT) Received: by vws10 with SMTP id 10so5872773vws.31 for ; Thu, 05 Aug 2010 13:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=fT4VFYoSxJ1muJ76E6oh2j35NICYc7LAalrb460iYmQ=; b=quPKVXmjYBryELHBU10H43ZbSR85ZRRYu0NxC9bMZEr/aYBqYmO6J90mDqH3vcmoA+ 9crISbDafvBnqU/dIf+fZsxJPUFNPAueAWLWKM4BYxIuZxHZQTVU7lwTuY8fQ7wnhh7k slAdQmsfnwUkPPrVaiXw76csbjwHmK2AaqIRg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=MVg5IPyDcjCPm/wAViaFVJoITvaVSaHAnzxQiGXle1mqAmu6dhQXyhM61VQnpjFKoh /hTGrD2EJcDysVYXKjkw9ypsNSKVIjPKXo39O4vy/Mb89Q4a7NDl0TX/KNQzZZZGSzbf Od3s3VyLD2bSzvgOBXpMlomK6feQ/sHQFP80A= Received: by 10.220.125.86 with SMTP id x22mr601608vcr.125.1281041820192; Thu, 05 Aug 2010 13:57:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.86.81 with HTTP; Thu, 5 Aug 2010 13:56:40 -0700 (PDT) In-Reply-To: References: From: Matthew Cini Sarreo Date: Thu, 5 Aug 2010 22:56:40 +0200 Message-ID: To: Keith Welter , ipsec@ietf.org Content-Type: multipart/alternative; boundary=001636c598c5a291e3048d19ca34 Subject: Re: [IPsec] Question about port floating in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 20:56:35 -0000 --001636c598c5a291e3048d19ca34 Content-Type: text/plain; charset=ISO-8859-1 I think all subsequent traffic refers to all new IKEv2 requests and all ESP traffic originating from the IPsec endpoint where the IKEv2 that discovered the NAT is on. Regards, Matt On 5 August 2010 18:11, Keith Welter wrote: > > Thanks again Matt. > > I was lead astray by this text: > Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec > endpoint that discovers a NAT between it and its correspondent (as > described below) MUST send all subsequent traffic from port 4500, > which NATs should not treat specially (as they might with port 500). > > It seems to me that "all subsequent traffic" contradicts the other text you > referred to. Assuming that the intent is that only requests are allowed to > float ports then I think this "all subsequent traffic" text is incorrect. > > I understand that IKEv2bis is on the RFC editor's queue so it is probably > too late to modify this text directly. I wonder if anyone else thinks this > issue is worth addressing, perhaps as an erratum? > > > Keith Welter > IBM z/OS Communications Server Developer > 1-415-545-2694 (T/L: 473-2694) > > > Matthew Cini Sarreo wrote on 08/05/2010 08:23:42 AM: > > > [image removed] > > > > Re: [IPsec] Question about port floating in IKEv2 > > > > Matthew Cini Sarreo > > > > to: > > > > Keith Welter, ipsec > > > > 08/05/2010 08:25 AM > > > > From section 2.11 (Address and Port agility) > > MUST respond to the address and port from which the request was received. > > > > From section 2.33 (NAT Traversal) > > An initiator can use port 4500 for both IKE and ESP, > > > > Also > > o The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or > > NAT_DETECTION_DESTINATION_IP payloads if present and if they do > > not match the addresses in the outer packet MUST tunnel all future > > IKE and ESP packets associated with this IKE SA over UDP port 4500. > > > > This implies that only the initiator (of a request) can change the > > ports as the responder is forced to keep replying using the same > > port on which the request was received. > > > > In the way I understand it, this is not for the original initiator > > but for the initiator of the next exchange after the IKE_SA_INIT > > exchange is done. So if the original responder would initiate > > IKE_AUTH, it is allowed to float to 4500. I might be wrong as the > > text states the IKE initiator, so it could be that only the original > > initiator can do this, but if it is so, this might be problematic. > > > > Regards, > > Matt > > > > > On 5 August 2010 17:06, Keith Welter wrote: > > > > Thanks Matt, question below. > > > > > Message: 4 > > > Date: Thu, 5 Aug 2010 16:46:29 +0200 > > > From: Matthew Cini Sarreo > > > > > Subject: Re: [IPsec] Question about port floating in IKEv2 > > > To: ipsec@ietf.org > > > Message-ID: > > > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > > > Only requests are allowed to float ports, > > > > > > Where is that stated? > > > > > responses MUST always be sent to > > > the address and port they were received from. The NAT_DETECTION_*_IP > > > payloads should still be computed using the original ports. > > > > > > For example: > > > IKE_SA_INIT Request: > > > x.x.x.x:501 to n.n.n.n:501. NAT_DETECTION_*_IP uses ports 501. > > > > > > IKE_SA_INIT Response: > > > During parsing, NAT is detected and the responder keeps track of this > and > > > which side is behind NAT. > > > n.n.n.n:501 to x.x.x.x:501. NAT_DETECTION_*_IP uses ports 501. > > > > > > IKE_AUTH request: > > > NAT has been discovered by both sides at this point and both sides know > who > > > is behind an NAT device. > > > x.x.x.x:4500 to n.n.n.n:4500. NON-ESP marker is included. > > > > > > Etc... > > > > > > Note that port 501 is used to make the point clearer. Reply to the port > > > received from, regardless of what it is. > > > > > > Hope this helps, > > > Matt > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > --001636c598c5a291e3048d19ca34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think all subsequent traffic refers to all new IKEv2 requests and all ESP= traffic originating from the IPsec endpoint where the IKEv2 that discovere= d the NAT is on.

Regards,
Matt

On 5 August 2010 18:11, Keith Welter <welterk@us.ibm.com> wrote:

Thanks again Matt.

I was lead astray by this text:
=A0 =A0Port 4500 is reserved for= UDP-encapsulated ESP and IKE. =A0An IPsec
=A0 endpoint that discovers a NAT between it and its correspondent (as
=A0 described below) MUST send all subsequent traffic from port 4500,
=A0 which NATs should not treat specially (as they might with port 500).
It seems to me that "all subsequent tra= ffic" contradicts the other text you referred to. =A0Assuming that the intent is that only requests are allowed to float ports then I think this "al= l subsequent traffic" text is incorrect.

I understand that IKEv2bis is on the RFC editor= 9;s queue so it is probably too late to modify this text directly. =A0I wonder if anyone else thinks this issue is worth addressing, perhaps as an erratum?


Keith Welter
IBM z/OS Communications Server Developer
1-415-545-2694 (T/L: 473-2694)

Matthew Cini Sarreo <mcins1@gmail.com> wrote on 08/05/2010 08:23:42 AM:

> [image removed]
>
> Re: [IPsec] Question about port floating in IKEv2
>
> Matthew Cini Sarreo
>
> to:
>
> Keith Welter, ipsec
>
> 08/05/2010 08:25 AM
>
> From section 2.11 (Address and Port agility)
> MUST respond to the address and port from which the request was receiv= ed.
>
> From section 2.33 (NAT Traversal)
> An initiator can use port 4500 for both IKE and ESP,
>
> Also
> =A0=A0 o=A0 The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or=A0
> =A0=A0 NAT_DETECTION_DESTINATION_IP payloads if present and if they do
> not match the addresses in the outer packet MUST tunnel all future
> IKE and ESP packets associated with this IKE SA over UDP port 4500. >
> This implies that only the initiator (of a request) can change the
> ports as the responder is forced to keep replying using the same
> port on which the request was received.
>
> In the way I understand it, this is not for the original initiator
> but for the initiator of the next exchange after the IKE_SA_INIT
> exchange is done. So if the original responder would initiate
> IKE_AUTH, it is allowed to float to 4500. I might be wrong as the
> text states the IKE initiator, so it could be that only the original > initiator can do this, but if it is so, this might be problematic.
>
> Regards,
> Matt
>

> On 5 August 2010 17:06, Keith Welter <welterk@us.ibm.com&= gt; wrote:
>
> Thanks Matt, question below.
>
> > Message: 4
> > Date: Thu, 5 Aug 2010 16:46:29 +0200
> > From: Matthew Cini Sarreo <mcins1@gmail.com>
>
> > Subject: Re: [IPsec] Question about port floating in IKEv2=
> > To: ipsec@ietf.org
> > Message-ID:
> > =A0 =A0<AANLkTimPyUGtM84N104acDVPuxTPiC= FomV698fofOKG1@mail.gmail.com>
> > Content-Type: text/plain; charset=3D"iso-8859-1"=
>
> >
> > Only requests are allowed to float ports,
>
>
> Where is that stated?
>
> > responses MUST always be sent to
> > the address and port they were received from. The NAT_DETECTION_*= _IP
> > payloads should still be computed using the original ports.
> >
> > For example:
> > IKE_SA_INIT Request:
> > x.x.x.x:501 to n.n.n.n:501. NAT_DETECTION_*_IP uses ports 501. > >
> > IKE_SA_INIT Response:
> > During parsing, NAT is detected and the responder keeps track of this and
> > which side is behind NAT.
> > n.n.n.n:501 to x.x.x.x:501. NAT_DETECTION_*_IP uses ports 501. > >
> > IKE_AUTH request:
> > NAT has been discovered by both sides at this point and both sides know who
> > is behind an NAT device.
> > x.x.x.x:4500 =A0to n.n.n.n:4500. NON-ESP marker is included.
> >
> > Etc...
> >
> > Note that port 501 is used to make the point clearer. Reply to the port
> > received from, regardless of what it is.
> >
> > Hope this helps,
> > Matt
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org=
> https://www.ietf.org/mailman/listinfo/= ipsec

--001636c598c5a291e3048d19ca34-- From B22245@freescale.com Thu Aug 5 23:19:29 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F33023A67CC for ; Thu, 5 Aug 2010 23:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycQG+B2Pb4oS for ; Thu, 5 Aug 2010 23:19:27 -0700 (PDT) Received: from DB3EHSOBE003.bigfish.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by core3.amsl.com (Postfix) with ESMTP id DF0813A67A7 for ; Thu, 5 Aug 2010 23:19:26 -0700 (PDT) Received: from mail50-db3-R.bigfish.com (10.3.81.245) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 8.1.436.0; Fri, 6 Aug 2010 06:19:57 +0000 Received: from mail50-db3 (localhost.localdomain [127.0.0.1]) by mail50-db3-R.bigfish.com (Postfix) with ESMTP id 1A2C610D028F for ; Fri, 6 Aug 2010 06:19:57 +0000 (UTC) X-SpamScore: -51 X-BigFish: VS-51(zz542N936eM4015L9371Pzz1202hzz1033IL5eeePz2dh2a8h61h) X-Spam-TCS-SCL: 0:0 Received: from mail50-db3 (localhost.localdomain [127.0.0.1]) by mail50-db3 (MessageSwitch) id 1281075595558719_11484; Fri, 6 Aug 2010 06:19:55 +0000 (UTC) Received: from DB3EHSMHS003.bigfish.com (unknown [10.3.81.251]) by mail50-db3.bigfish.com (Postfix) with ESMTP id 7BCA012B004B for ; Fri, 6 Aug 2010 06:19:55 +0000 (UTC) Received: from az33egw02.freescale.net (192.88.158.103) by DB3EHSMHS003.bigfish.com (10.3.87.103) with Microsoft SMTP Server (TLS) id 14.0.482.44; Fri, 6 Aug 2010 06:19:54 +0000 Received: from az33smr02.freescale.net (az33smr02.freescale.net [10.64.34.200]) by az33egw02.freescale.net (8.14.3/8.14.3) with ESMTP id o766Jlkn022597 for ; Thu, 5 Aug 2010 23:19:52 -0700 (MST) Received: from zin33exm29.fsl.freescale.net (zin33exm29.ap.freescale.net [10.232.192.28]) by az33smr02.freescale.net (8.13.1/8.13.0) with ESMTP id o766Jp0v021208 for ; Fri, 6 Aug 2010 01:19:52 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB352F.5CFF6045" Date: Fri, 6 Aug 2010 11:49:21 +0530 Message-ID: <402621A7D69DDA458D0E12F070D1E55F24E83A@zin33exm29.fsl.freescale.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Failure detection proposals Thread-Index: Acs0FU391oeCX22VSGW7/RKa88xWUABGgFCF References: <4C59D035.50108@gmail.com> From: V Jyothi-B22245 To: "Yaron Sheffer" , "IPsecme WG" X-Reverse-DNS: az33egw02.freescale.net Subject: Re: [IPsec] Failure detection proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 06:19:29 -0000 ------_=_NextPart_001_01CB352F.5CFF6045 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I am interested to work on this issue. =20 thanks jyothi ________________________________ From: ipsec-bounces@ietf.org on behalf of Yaron Sheffer Sent: Thu 8/5/2010 2:10 AM To: IPsecme WG Subject: [IPsec] Failure detection proposals In the Maastricht meeting there was just a tiny bit of interest in the failure detection idea (reminder: the goal is to ensure that one peer discovers that the other IKE peer has restarted, within a short time duration, milliseconds instead of minutes). But we didn't see enough interest to justify having this as a WG item. So, one last time: if you think this is a worthwhile idea, regardless of the proposals on the table, please say so publicly. If you speak up, we will expect you to contribute to the selection of the preferred document. If this is of no interest, fine. But if it is an important problem to solve and we don't take it on, we could end up with competing non-WG proposals. Which would be far from ideal. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Wednesday, July 07, 2010 8:03 PM To: IPsecme WG Subject: [IPsec] NUDGE: Starting discussion of failure detection = proposals [[ This topic generated a fair amount of discussion in the past; are folks still interested? ]] Greetings again. The WG has one item on our charter that we have barely discussed, namely failure detection. The charter item says that the work item is: >- A standards-track IKEv2 extension that allows an IKE peer to quickly = and securely detect that its opposite peer, while currently reachable, = has lost its IKEv2/IPsec state. Changes to how the peers recover from = this situation are beyond the scope of this work item, as is improving = the detection of an unreachable or dead peer. Ideas from = draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as = starting points. I gave a brief presentation on failure detection at the last IETF meeting in Anaheim. The slides are at , and the following is directly derived from them. The basic problem being covered by the new extension is: - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob crashes - Alice keeps sending ESP to Bob - When Bob finally comes back up, he replies to Alice's ESP with INVALID_SPI notifications - Alice starts sending IKE liveness checks until she is "sure" that the INVALID_SPI responses are not a DoS attack; this could be "several = minutes" - Then Alice rekeys Some other problem cases include: - Bob has two gateways in some failover architecture. One gateway goes down, the other gateway detects this and wants to tell Alice to rekey - Bob has a bunch of gateways in some load-balancing or cluster architecture. One gateway is taken down on purpose, and the system wants to tell Alice to rekey - Protocol robustness: Bob's gateway loses the SA without going down Our primary goal is that, as soon as Bob starts sending INVALID_SPI responses to Alice's ESP traffic, Bob and Alice should be able to quickly determine that this is not an attack and therefore they probably want to rekey right away. Note that if Bob and Alice are also using session resumption, they can use that instead of rekeying; however, in the discussion here, we always use "rekey" to mean "rekey or, if appropriate, resume". The proposed extension does not include the actual rekeying, just the context for them to do it now. The WG has seen two proposed solutions, QCD and SIR. The following are brief summaries of the two proposals. In QCD (), Bob gives Alice a secret token in the AUTH exchange, and then puts the token in his INVALID_SPI response as a way to say "this SPI is gone". Bob must remember his tokens across reboots, or derive tokens from a master token that he memorizes across reboots, and Alice must remember the token (or a hash of it) for each SA. In SIR (), Alice sends a new Check_SPI query with a stateless cookie, essentially asking "do you really not know about this SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing is stored on either side, so a man-in-the-middle can attack this to cause an unnecessary rekey just as they can normal IKE. The first task for the WG is to decide which of these two quite different approaches to take. After we have done that, we can then hone the chosen proposal. During earlier discussion of the proposals, the following criteria were mentioned as ones that the WG should consider when thinking about the approaches: - Support for different scenarios (load balancers, active clusters, failover) - Security from man-in-the-middle DoS attacks - Resources used - Intellectual property rights So: please start discussing the two proposals with respect to these criteria or other criteria that are important to you. In a few weeks (hopefully well before the Maastricht meeting), I make a call for consensus and see where it leads us. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01CB352F.5CFF6045 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [IPsec] Failure detection proposals=0A= =0A= =0A= =0A=
=0A=
Hi,
=0A=
 
=0A=
I am interested to work on = this issue.
=0A=
 
=0A=
thanks
=0A=
jyothi
=0A=

=0A=
=0A= From: ipsec-bounces@ietf.org on = behalf of Yaron Sheffer
Sent: Thu 8/5/2010 2:10 = AM
To: IPsecme WG
Subject: [IPsec] Failure detection = proposals

=0A=
=0A=

In the Maastricht meeting there was just a tiny bit of = interest in the
failure detection idea (reminder: the goal is to = ensure that one peer
discovers that the other IKE peer has restarted, = within a short time
duration, milliseconds instead of minutes). But = we didn't see enough
interest to justify having this as a WG item. = So, one last time: if you
think this is a worthwhile idea, regardless = of the proposals on the
table, please say so publicly. If you speak = up, we will expect you to
contribute to the selection of the = preferred document.

If this is of no interest, fine. But if it is = an important problem to
solve and we don't take it on, we could end = up with competing non-WG
proposals. Which would be far from = ideal.

Thanks,
        = Yaron

-----Original Message-----
From: ipsec-bounces@ietf.org = [mailto:ipsec-bounces@ietf.org]= On Behalf
Of Paul Hoffman
Sent: Wednesday, July 07, 2010 8:03 = PM
To: IPsecme WG
Subject: [IPsec] NUDGE: Starting discussion of = failure detection proposals

[[ This topic generated a fair amount = of discussion in the past; are
folks still interested? = ]]

Greetings again. The WG has one item on our charter that we = have barely
discussed, namely failure detection. The charter item = says that the work
item is:

>- A standards-track IKEv2 = extension that allows an IKE peer to quickly and securely detect that = its opposite peer, while currently reachable, has lost its IKEv2/IPsec = state. Changes to how the peers recover from this situation are beyond = the scope of this work item, as is improving the detection of an = unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and = draft-detienne-ikev2-recovery-03 can be used as starting = points.

I gave a brief presentation on failure detection at the = last IETF
meeting in Anaheim. The slides are at
<http://w= ww.ietf.org/proceedings/77/slides/ipsecme-4.pdf>, and = the
following is directly derived from them.

The basic problem = being covered by the new extension is:
-  Alice and Bob have SAs = up and ESP traffic is flowing, but then Bob
crashes
-  Alice = keeps sending ESP to Bob
-  When Bob finally comes back up, he = replies to Alice's ESP with
INVALID_SPI notifications
-  = Alice starts sending IKE liveness checks until she is "sure" that = the
INVALID_SPI responses are not a DoS attack; this could be = "several minutes"
-  Then Alice rekeys

Some other problem = cases include:
-  Bob has two gateways in some failover = architecture. One gateway goes
down, the other gateway detects this = and wants to tell Alice to rekey
-  Bob has a bunch of gateways = in some load-balancing or cluster
architecture. One gateway is taken = down on purpose, and the system wants
to tell Alice to = rekey
-  Protocol robustness:  Bob's gateway loses the SA = without going down

Our primary goal is that, as soon as Bob = starts sending INVALID_SPI
responses to Alice's ESP traffic, Bob and = Alice should be able to
quickly determine that this is not an attack = and therefore they probably
want to rekey right away. Note that if = Bob and Alice are also using
session resumption, they can use that = instead of rekeying; however, in
the discussion here, we always use = "rekey" to mean "rekey or, if
appropriate, resume". The proposed = extension does not include the actual
rekeying, just the context for = them to do it now.

The WG has seen two proposed solutions, QCD = and SIR. The following are
brief summaries of the two = proposals.

In QCD (<http://tools.ietf.o= rg/html/draft-nir-ike-qcd>), Bob gives Alice
a secret token in = the AUTH exchange, and then puts the token in his
INVALID_SPI = response as a way to say "this SPI is gone". Bob must
remember his = tokens across reboots, or derive tokens from a master token
that he = memorizes across reboots, and Alice must remember the token (or
a = hash of it) for each SA.

In SIR
(<ht= tp://tools.ietf.org/id/draft-detienne-ikev2-recovery-03.txt>), = Alice
sends a new Check_SPI query with a stateless cookie, = essentially asking
"do you really not know about this
SPI?"; Bob = responds by saying "I'm sure I don't know that SPI". Nothing
is = stored on either side, so a man-in-the-middle can attack this = to
cause an unnecessary rekey just as they can normal IKE.

The = first task for the WG is to decide which of these two quite
different = approaches to take. After we have done that, we can then hone
the = chosen proposal. During earlier discussion of the proposals, = the
following criteria were mentioned as ones that the WG should = consider
when thinking about the approaches:

-  Support = for different scenarios (load balancers, active = clusters,
failover)
-  Security from man-in-the-middle DoS = attacks
-  Resources used
-  Intellectual property = rights

So: please start discussing the two proposals with respect = to these
criteria or other criteria that are important to you. In a = few weeks
(hopefully well before the Maastricht meeting), I make a = call for
consensus and see where it leads us.

--Paul Hoffman, = Director
--VPN = Consortium
_______________________________________________
IPsec = mailing list
IPsec@ietf.org
https://www.ietf.org= /mailman/listinfo/ipsec

------_=_NextPart_001_01CB352F.5CFF6045-- From apvelan@cisco.com Thu Aug 5 23:46:29 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B76123A6819 for ; Thu, 5 Aug 2010 23:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6FRiqnSqsn7 for ; Thu, 5 Aug 2010 23:46:28 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 12BE43A67CC for ; Thu, 5 Aug 2010 23:46:28 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAIZMW0xAaMHG/2dsb2JhbACBRJ52cahNmyeFOgSEH4db Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-2.cisco.com with ESMTP; 06 Aug 2010 06:46:56 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o766kHkw011053; Fri, 6 Aug 2010 06:46:54 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Aug 2010 12:16:53 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3533.27C6F565" Date: Fri, 6 Aug 2010 12:16:53 +0530 Message-ID: In-Reply-To: <402621A7D69DDA458D0E12F070D1E55F24E83A@zin33exm29.fsl.freescale.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Failure detection proposals Thread-Index: Acs0FU391oeCX22VSGW7/RKa88xWUABGgFCFAADmweA= References: <4C59D035.50108@gmail.com> <402621A7D69DDA458D0E12F070D1E55F24E83A@zin33exm29.fsl.freescale.net> From: "Palanivelan A (apvelan)" To: "V Jyothi-B22245" , "Yaron Sheffer" , "IPsecme WG" X-OriginalArrivalTime: 06 Aug 2010 06:46:53.0643 (UTC) FILETIME=[27BC09B0:01CB3533] Subject: Re: [IPsec] Failure detection proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 06:46:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3533.27C6F565 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi There, =20 This looks interesting and I will also be happy to contribute there. I do have a draft on BFD that is in the final stages of ISR-review. I currently work more on the security stuff and I guess, I can contribute here. =20 Regards, A.Palanivelan =20 From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of V Jyothi-B22245 Sent: Friday, August 06, 2010 11:49 AM To: Yaron Sheffer; IPsecme WG Subject: Re: [IPsec] Failure detection proposals =20 Hi, =20 I am interested to work on this issue. =20 thanks jyothi =20 ________________________________ From: ipsec-bounces@ietf.org on behalf of Yaron Sheffer Sent: Thu 8/5/2010 2:10 AM To: IPsecme WG Subject: [IPsec] Failure detection proposals In the Maastricht meeting there was just a tiny bit of interest in the failure detection idea (reminder: the goal is to ensure that one peer discovers that the other IKE peer has restarted, within a short time duration, milliseconds instead of minutes). But we didn't see enough interest to justify having this as a WG item. So, one last time: if you think this is a worthwhile idea, regardless of the proposals on the table, please say so publicly. If you speak up, we will expect you to contribute to the selection of the preferred document. If this is of no interest, fine. But if it is an important problem to solve and we don't take it on, we could end up with competing non-WG proposals. Which would be far from ideal. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Wednesday, July 07, 2010 8:03 PM To: IPsecme WG Subject: [IPsec] NUDGE: Starting discussion of failure detection proposals [[ This topic generated a fair amount of discussion in the past; are folks still interested? ]] Greetings again. The WG has one item on our charter that we have barely discussed, namely failure detection. The charter item says that the work item is: >- A standards-track IKEv2 extension that allows an IKE peer to quickly and securely detect that its opposite peer, while currently reachable, has lost its IKEv2/IPsec state. Changes to how the peers recover from this situation are beyond the scope of this work item, as is improving the detection of an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting points. I gave a brief presentation on failure detection at the last IETF meeting in Anaheim. The slides are at , and the following is directly derived from them. The basic problem being covered by the new extension is: - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob crashes - Alice keeps sending ESP to Bob - When Bob finally comes back up, he replies to Alice's ESP with INVALID_SPI notifications - Alice starts sending IKE liveness checks until she is "sure" that the INVALID_SPI responses are not a DoS attack; this could be "several minutes" - Then Alice rekeys Some other problem cases include: - Bob has two gateways in some failover architecture. One gateway goes down, the other gateway detects this and wants to tell Alice to rekey - Bob has a bunch of gateways in some load-balancing or cluster architecture. One gateway is taken down on purpose, and the system wants to tell Alice to rekey - Protocol robustness: Bob's gateway loses the SA without going down Our primary goal is that, as soon as Bob starts sending INVALID_SPI responses to Alice's ESP traffic, Bob and Alice should be able to quickly determine that this is not an attack and therefore they probably want to rekey right away. Note that if Bob and Alice are also using session resumption, they can use that instead of rekeying; however, in the discussion here, we always use "rekey" to mean "rekey or, if appropriate, resume". The proposed extension does not include the actual rekeying, just the context for them to do it now. The WG has seen two proposed solutions, QCD and SIR. The following are brief summaries of the two proposals. In QCD (), Bob gives Alice a secret token in the AUTH exchange, and then puts the token in his INVALID_SPI response as a way to say "this SPI is gone". Bob must remember his tokens across reboots, or derive tokens from a master token that he memorizes across reboots, and Alice must remember the token (or a hash of it) for each SA. In SIR (), Alice sends a new Check_SPI query with a stateless cookie, essentially asking "do you really not know about this SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing is stored on either side, so a man-in-the-middle can attack this to cause an unnecessary rekey just as they can normal IKE. The first task for the WG is to decide which of these two quite different approaches to take. After we have done that, we can then hone the chosen proposal. During earlier discussion of the proposals, the following criteria were mentioned as ones that the WG should consider when thinking about the approaches: - Support for different scenarios (load balancers, active clusters, failover) - Security from man-in-the-middle DoS attacks - Resources used - Intellectual property rights So: please start discussing the two proposals with respect to these criteria or other criteria that are important to you. In a few weeks (hopefully well before the Maastricht meeting), I make a call for consensus and see where it leads us. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01CB3533.27C6F565 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [IPsec] Failure detection proposals

Hi There,

 

This looks interesting and I will also be happy to = contribute there.

I do have a draft on BFD that is in the final stages of ISR-review. I  currently  work more on the security stuff and = I guess, I can contribute here.

 

Regards,

A.Palanivelan

 

From:= ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of = V Jyothi-B22245
Sent: Friday, August 06, 2010 11:49 AM
To: Yaron Sheffer; IPsecme WG
Subject: Re: [IPsec] Failure detection = proposals

 

Hi,

 

I am interested to work on this issue.

 

thanks=

jyothi=

 

From: ipsec-bounces@ietf.org on behalf of = Yaron Sheffer
Sent: Thu 8/5/2010 2:10 AM
To: IPsecme WG
Subject: [IPsec] Failure detection = proposals

In = the Maastricht meeting there was just a tiny bit of interest in the
failure detection idea (reminder: the goal is to ensure that one = peer
discovers that the other IKE peer has restarted, within a short time
duration, milliseconds instead of minutes). But we didn't see enough
interest to justify having this as a WG item. So, one last time: if = you
think this is a worthwhile idea, regardless of the proposals on the
table, please say so publicly. If you speak up, we will expect you = to
contribute to the selection of the preferred document.

If this is of no interest, fine. But if it is an important problem = to
solve and we don't take it on, we could end up with competing non-WG
proposals. Which would be far from ideal.

Thanks,
        Yaron

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]= On Behalf
Of Paul Hoffman
Sent: Wednesday, July 07, 2010 8:03 PM
To: IPsecme WG
Subject: [IPsec] NUDGE: Starting discussion of failure detection = proposals

[[ This topic generated a fair amount of discussion in the past; are
folks still interested? ]]

Greetings again. The WG has one item on our charter that we have = barely
discussed, namely failure detection. The charter item says that the = work
item is:

>- A standards-track IKEv2 extension that allows an IKE peer to = quickly and securely detect that its opposite peer, while currently reachable, has = lost its IKEv2/IPsec state. Changes to how the peers recover from this situation = are beyond the scope of this work item, as is improving the detection of an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting points.

I gave a brief presentation on failure detection at the last IETF
meeting in Anaheim. The slides are at
<http://w= ww.ietf.org/proceedings/77/slides/ipsecme-4.pdf>, and the
following is directly derived from them.

The basic problem being covered by the new extension is:
-  Alice and Bob have SAs up and ESP traffic is flowing, but then = Bob
crashes
-  Alice keeps sending ESP to Bob
-  When Bob finally comes back up, he replies to Alice's ESP = with
INVALID_SPI notifications
-  Alice starts sending IKE liveness checks until she is = "sure" that the
INVALID_SPI responses are not a DoS attack; this could be "several minutes"
-  Then Alice rekeys

Some other problem cases include:
-  Bob has two gateways in some failover architecture. One gateway = goes
down, the other gateway detects this and wants to tell Alice to = rekey
-  Bob has a bunch of gateways in some load-balancing or = cluster
architecture. One gateway is taken down on purpose, and the system = wants
to tell Alice to rekey
-  Protocol robustness:  Bob's gateway loses the SA without = going down

Our primary goal is that, as soon as Bob starts sending INVALID_SPI
responses to Alice's ESP traffic, Bob and Alice should be able to
quickly determine that this is not an attack and therefore they = probably
want to rekey right away. Note that if Bob and Alice are also using
session resumption, they can use that instead of rekeying; however, = in
the discussion here, we always use "rekey" to mean "rekey = or, if
appropriate, resume". The proposed extension does not include the = actual
rekeying, just the context for them to do it now.

The WG has seen two proposed solutions, QCD and SIR. The following = are
brief summaries of the two proposals.

In QCD (<http://tools.ietf.o= rg/html/draft-nir-ike-qcd>), Bob gives Alice
a secret token in the AUTH exchange, and then puts the token in his
INVALID_SPI response as a way to say "this SPI is gone". Bob = must
remember his tokens across reboots, or derive tokens from a master = token
that he memorizes across reboots, and Alice must remember the token = (or
a hash of it) for each SA.

In SIR
(<ht= tp://tools.ietf.org/id/draft-detienne-ikev2-recovery-03.txt>), Alice
sends a new Check_SPI query with a stateless cookie, essentially = asking
"do you really not know about this
SPI?"; Bob responds by saying "I'm sure I don't know that = SPI". Nothing
is stored on either side, so a man-in-the-middle can attack this to
cause an unnecessary rekey just as they can normal IKE.

The first task for the WG is to decide which of these two quite
different approaches to take. After we have done that, we can then = hone
the chosen proposal. During earlier discussion of the proposals, the
following criteria were mentioned as ones that the WG should = consider
when thinking about the approaches:

-  Support for different scenarios (load balancers, active = clusters,
failover)
-  Security from man-in-the-middle DoS attacks
-  Resources used
-  Intellectual property rights

So: please start discussing the two proposals with respect to these
criteria or other criteria that are important to you. In a few weeks
(hopefully well before the Maastricht meeting), I make a call for
consensus and see where it leads us.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org= /mailman/listinfo/ipsec

------_=_NextPart_001_01CB3533.27C6F565-- From zhangdacheng@huawei.com Sun Aug 8 19:15:56 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1A33A6A12 for ; Sun, 8 Aug 2010 19:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.371 X-Spam-Level: X-Spam-Status: No, score=-0.371 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDQERpR9CXxt for ; Sun, 8 Aug 2010 19:15:55 -0700 (PDT) Received: from szxga05-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 5C36C3A680F for ; Sun, 8 Aug 2010 19:15:55 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6V0025I4ZG2Z@szxga05-in.huawei.com> for ipsec@ietf.org; Mon, 09 Aug 2010 10:16:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6V0003S4ZFE5@szxga05-in.huawei.com> for ipsec@ietf.org; Mon, 09 Aug 2010 10:16:28 +0800 (CST) Received: from z00133208 ([10.110.98.54]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L6V00DB74ZF4Z@szxml06-in.huawei.com> for ipsec@ietf.org; Mon, 09 Aug 2010 10:16:27 +0800 (CST) Date: Mon, 09 Aug 2010 10:16:27 +0800 From: Dacheng Zhang In-reply-to: <4C59D035.50108@gmail.com> To: 'Yaron Sheffer' , 'IPsecme WG' Message-id: <00ee01cb3768$df8e9120$36626e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Thread-index: Acs0FVLmAUO7DoFZQIiCy1XdZ5ZDwgDU3Tdg Subject: Re: [IPsec] Failure detection proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 02:15:56 -0000 As other experts said, this is an interesting issue and worth us spending efforts on it. I would like to join this work. > > In the Maastricht meeting there was just a tiny bit of > interest in the failure detection idea (reminder: the goal is > to ensure that one peer discovers that the other IKE peer has > restarted, within a short time duration, milliseconds instead > of minutes). But we didn't see enough interest to justify > having this as a WG item. So, one last time: if you think > this is a worthwhile idea, regardless of the proposals on the > table, please say so publicly. If you speak up, we will > expect you to contribute to the selection of the preferred document. > > If this is of no interest, fine. But if it is an important > problem to solve and we don't take it on, we could end up > with competing non-WG proposals. Which would be far from ideal. > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Paul Hoffman > Sent: Wednesday, July 07, 2010 8:03 PM > To: IPsecme WG > Subject: [IPsec] NUDGE: Starting discussion of failure > detection proposals > > [[ This topic generated a fair amount of discussion in the > past; are folks still interested? ]] > > Greetings again. The WG has one item on our charter that we > have barely discussed, namely failure detection. The charter > item says that the work item is: > > >- A standards-track IKEv2 extension that allows an IKE peer > to quickly and securely detect that its opposite peer, while > currently reachable, has lost its IKEv2/IPsec state. Changes > to how the peers recover from this situation are beyond the > scope of this work item, as is improving the detection of an > unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and > draft-detienne-ikev2-recovery-03 can be used as starting points. > > I gave a brief presentation on failure detection at the last > IETF meeting in Anaheim. The slides are at > , > and the following is directly derived from them. > > The basic problem being covered by the new extension is: > - Alice and Bob have SAs up and ESP traffic is flowing, but > then Bob crashes > - Alice keeps sending ESP to Bob > - When Bob finally comes back up, he replies to Alice's ESP > with INVALID_SPI notifications > - Alice starts sending IKE liveness checks until she is > "sure" that the INVALID_SPI responses are not a DoS attack; > this could be "several minutes" > - Then Alice rekeys > > Some other problem cases include: > - Bob has two gateways in some failover architecture. One > gateway goes down, the other gateway detects this and wants > to tell Alice to rekey > - Bob has a bunch of gateways in some load-balancing or > cluster architecture. One gateway is taken down on purpose, > and the system wants to tell Alice to rekey > - Protocol robustness: Bob's gateway loses the SA without going down > > Our primary goal is that, as soon as Bob starts sending > INVALID_SPI responses to Alice's ESP traffic, Bob and Alice > should be able to quickly determine that this is not an > attack and therefore they probably want to rekey right away. > Note that if Bob and Alice are also using session resumption, > they can use that instead of rekeying; however, in the > discussion here, we always use "rekey" to mean "rekey or, if > appropriate, resume". The proposed extension does not include > the actual rekeying, just the context for them to do it now. > > The WG has seen two proposed solutions, QCD and SIR. The > following are brief summaries of the two proposals. > > In QCD (), Bob > gives Alice a secret token in the AUTH exchange, and then > puts the token in his INVALID_SPI response as a way to say > "this SPI is gone". Bob must remember his tokens across > reboots, or derive tokens from a master token that he > memorizes across reboots, and Alice must remember the token > (or a hash of it) for each SA. > > In SIR > ( t>), Alice sends a new Check_SPI query with a stateless > cookie, essentially asking "do you really not know about this > SPI?"; Bob responds by saying "I'm sure I don't know that > SPI". Nothing is stored on either side, so a > man-in-the-middle can attack this to cause an unnecessary > rekey just as they can normal IKE. > > The first task for the WG is to decide which of these two > quite different approaches to take. After we have done that, > we can then hone the chosen proposal. During earlier > discussion of the proposals, the following criteria were > mentioned as ones that the WG should consider when thinking > about the approaches: > > - Support for different scenarios (load balancers, active clusters, > failover) > - Security from man-in-the-middle DoS attacks > - Resources used > - Intellectual property rights > > So: please start discussing the two proposals with respect to > these criteria or other criteria that are important to you. > In a few weeks (hopefully well before the Maastricht > meeting), I make a call for consensus and see where it leads us. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From wierbows@us.ibm.com Mon Aug 9 06:13:33 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4938628C0F4; Mon, 9 Aug 2010 06:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.179 X-Spam-Level: X-Spam-Status: No, score=-5.179 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+-VhFu1mMmf; Mon, 9 Aug 2010 06:13:31 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.143]) by core3.amsl.com (Postfix) with ESMTP id 9F03E28C0DC; Mon, 9 Aug 2010 06:13:30 -0700 (PDT) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e3.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o79CwreE005211; Mon, 9 Aug 2010 08:58:53 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o79DDpp7351492; Mon, 9 Aug 2010 09:13:51 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o79DDpxX012771; Mon, 9 Aug 2010 10:13:51 -0300 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o79DDpeI012765; Mon, 9 Aug 2010 10:13:51 -0300 In-Reply-To: References: <4C59D035.50108@gmail.com> X-KeepSent: 4106F9C6:02AEE433-8525777A:00487D45; type=4; name=$KeepSent To: IPsecme WG , ipsec-bounces@ietf.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: David Wierbowski Date: Mon, 9 Aug 2010 09:13:45 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 08/09/2010 09:13:50 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0ABBFDE9DFDBFBD58f9e8a93df938690918c0ABBFDE9DFDBFBD5" Content-Disposition: inline Subject: Re: [IPsec] Failure detection proposals X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 13:13:33 -0000 --0__=0ABBFDE9DFDBFBD58f9e8a93df938690918c0ABBFDE9DFDBFBD5 Content-type: text/plain; charset=US-ASCII I agree with Scott and I am also willing to participate in discussion of the alternatives. Dave Wierbowski From: Scott C Moonen/Raleigh/IBM@IBMUS To: Yaron Sheffer Cc: IPsecme WG , ipsec-bounces@ietf.org Date: 08/05/2010 09:33 AM Subject: Re: [IPsec] Failure detection proposals Sent by: ipsec-bounces@ietf.org I think this is an important problem to solve and I'm willing to participate in discussion of the alternatives, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen (Embedded image moved to file: pic03142.gif)Inactive hide details for Yaron Sheffer ---08/04/2010 04:48:45 PM---In the Maastricht meeting there was just a tiny bit of inteYaron Sheffer ---08/04/2010 04:48:45 PM---In the Maastricht meeting there was just a tiny bit of interest in the failure detection idea (remi From: Yaron Sheffer To: IPsecme WG Date: 08/04/2010 04:48 PM Subject: [IPsec] Failure detection proposals Sent by: ipsec-bounces@ietf.org In the Maastricht meeting there was just a tiny bit of interest in the failure detection idea (reminder: the goal is to ensure that one peer discovers that the other IKE peer has restarted, within a short time duration, milliseconds instead of minutes). But we didn't see enough interest to justify having this as a WG item. So, one last time: if you think this is a worthwhile idea, regardless of the proposals on the table, please say so publicly. If you speak up, we will expect you to contribute to the selection of the preferred document. If this is of no interest, fine. But if it is an important problem to solve and we don't take it on, we could end up with competing non-WG proposals. Which would be far from ideal. Thanks, Yaron -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Wednesday, July 07, 2010 8:03 PM To: IPsecme WG Subject: [IPsec] NUDGE: Starting discussion of failure detection proposals [[ This topic generated a fair amount of discussion in the past; are folks still interested? ]] Greetings again. The WG has one item on our charter that we have barely discussed, namely failure detection. The charter item says that the work item is: >- A standards-track IKEv2 extension that allows an IKE peer to quickly and securely detect that its opposite peer, while currently reachable, has lost its IKEv2/IPsec state. Changes to how the peers recover from this situation are beyond the scope of this work item, as is improving the detection of an unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and draft-detienne-ikev2-recovery-03 can be used as starting points. I gave a brief presentation on failure detection at the last IETF meeting in Anaheim. The slides are at , and the following is directly derived from them. The basic problem being covered by the new extension is: - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob crashes - Alice keeps sending ESP to Bob - When Bob finally comes back up, he replies to Alice's ESP with INVALID_SPI notifications - Alice starts sending IKE liveness checks until she is "sure" that the INVALID_SPI responses are not a DoS attack; this could be "several minutes" - Then Alice rekeys Some other problem cases include: - Bob has two gateways in some failover architecture. One gateway goes down, the other gateway detects this and wants to tell Alice to rekey - Bob has a bunch of gateways in some load-balancing or cluster architecture. One gateway is taken down on purpose, and the system wants to tell Alice to rekey - Protocol robustness: Bob's gateway loses the SA without going down Our primary goal is that, as soon as Bob starts sending INVALID_SPI responses to Alice's ESP traffic, Bob and Alice should be able to quickly determine that this is not an attack and therefore they probably want to rekey right away. Note that if Bob and Alice are also using session resumption, they can use that instead of rekeying; however, in the discussion here, we always use "rekey" to mean "rekey or, if appropriate, resume". The proposed extension does not include the actual rekeying, just the context for them to do it now. The WG has seen two proposed solutions, QCD and SIR. The following are brief summaries of the two proposals. In QCD (), Bob gives Alice a secret token in the AUTH exchange, and then puts the token in his INVALID_SPI response as a way to say "this SPI is gone". Bob must remember his tokens across reboots, or derive tokens from a master token that he memorizes across reboots, and Alice must remember the token (or a hash of it) for each SA. In SIR (), Alice sends a new Check_SPI query with a stateless cookie, essentially asking "do you really not know about this SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing is stored on either side, so a man-in-the-middle can attack this to cause an unnecessary rekey just as they can normal IKE. The first task for the WG is to decide which of these two quite different approaches to take. After we have done that, we can then hone the chosen proposal. During earlier discussion of the proposals, the following criteria were mentioned as ones that the WG should consider when thinking about the approaches: - Support for different scenarios (load balancers, active clusters, failover) - Security from man-in-the-middle DoS attacks - Resources used - Intellectual property rights So: please start discussing the two proposals with respect to these criteria or other criteria that are important to you. In a few weeks (hopefully well before the Maastricht meeting), I make a call for consensus and see where it leads us. --Paul Hoffman, Director --VPN Consortium _______________________________________________ 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 --0__=0ABBFDE9DFDBFBD58f9e8a93df938690918c0ABBFDE9DFDBFBD5 Content-type: image/gif; name="pic03142.gif" Content-Disposition: attachment; filename="pic03142.gif" Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFDE9DFDBFBD58f9e8a93df938690918c0ABBFDE9DFDBFBD5-- From yaronf.ietf@gmail.com Tue Aug 10 03:19:22 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56FD03A695D for ; Tue, 10 Aug 2010 03:19:22 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CssM+LO7ILt for ; Tue, 10 Aug 2010 03:19:20 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 72E2F3A68FA for ; Tue, 10 Aug 2010 03:19:20 -0700 (PDT) Received: by eyb7 with SMTP id 7so4279892eyb.31 for ; Tue, 10 Aug 2010 03:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=a+NXI4KywrTdHYpPxh7ldcolLE2kXRmx/fM10YvNUic=; b=MNVjq6XueLi8JgKuuHhBQhEr7sGfNykp6ICwO1u/xPvS0mwPwsDwbAYVExUJZ1+7MW ZQKtE1HDDnDcqbrOOwy3d+9YAum3cCPgdxEoAsBFAqwM8uXj723dzeWkTgz5fe4yjKzl +FTQlbob8I9qdv3g66uJ/h/eoLKdXd6T0L3wc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=jlCzL7Pp9IZ6ubxhCXt3jeMh95Amp35OV1essdIyHheBbO5hCw0jY8FPNGDMAGdEUn F4Rjc52jQgqYgdwE4cV+TKTwdd/mJFb4W1apMvOPn8xEM46ZB7+QTzUS0IfUkAl92sU7 +V8b6z9tV7t2PVmmnLyn6dmtcDKSPZxebVjh8= Received: by 10.213.10.200 with SMTP id q8mr3978859ebq.42.1281435594879; Tue, 10 Aug 2010 03:19:54 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-178-4-195.red.bezeqint.net [79.178.4.195]) by mx.google.com with ESMTPS id z55sm9493511eeh.21.2010.08.10.03.19.53 (version=SSLv3 cipher=RC4-MD5); Tue, 10 Aug 2010 03:19:53 -0700 (PDT) Message-ID: <4C6127C7.7070008@gmail.com> Date: Tue, 10 Aug 2010 13:19:51 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: IPsecme WG References: <4C59D035.50108@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] Failure detection proposals, stage 2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 10:19:22 -0000 OK, Paul and I are finally convinced that we have sufficient WG interest in solving this problem. Now, I'd like to ask the people who have responded (as well as others) to read the two drafts, and to tell us why they prefer the one over the other. Quoting myself: "If you speak up, we will expect you to contribute to the selection of the preferred document". Please respond with comments to the drafts and/or a comparison within the next week, i.e. by August 17. Thanks, Yaron > From: Yaron Sheffer > To: IPsecme WG > Date: 08/04/2010 04:48 PM > Subject: [IPsec] Failure detection proposals > Sent by: ipsec-bounces@ietf.org > > > > In the Maastricht meeting there was just a tiny bit of interest in the > failure detection idea (reminder: the goal is to ensure that one peer > discovers that the other IKE peer has restarted, within a short time > duration, milliseconds instead of minutes). But we didn't see enough > interest to justify having this as a WG item. So, one last time: if you > think this is a worthwhile idea, regardless of the proposals on the > table, please say so publicly. If you speak up, we will expect you to > contribute to the selection of the preferred document. > > If this is of no interest, fine. But if it is an important problem to > solve and we don't take it on, we could end up with competing non-WG > proposals. Which would be far from ideal. > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Paul Hoffman > Sent: Wednesday, July 07, 2010 8:03 PM > To: IPsecme WG > Subject: [IPsec] NUDGE: Starting discussion of failure detection proposals > > [[ This topic generated a fair amount of discussion in the past; are > folks still interested? ]] > > Greetings again. The WG has one item on our charter that we have barely > discussed, namely failure detection. The charter item says that the work > item is: > >> - A standards-track IKEv2 extension that allows an IKE peer to quickly and > securely detect that its opposite peer, while currently reachable, has lost > its IKEv2/IPsec state. Changes to how the peers recover from this situation > are beyond the scope of this work item, as is improving the detection of an > unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and > draft-detienne-ikev2-recovery-03 can be used as starting points. > > I gave a brief presentation on failure detection at the last IETF > meeting in Anaheim. The slides are at > , and the > following is directly derived from them. > > The basic problem being covered by the new extension is: > - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob > crashes > - Alice keeps sending ESP to Bob > - When Bob finally comes back up, he replies to Alice's ESP with > INVALID_SPI notifications > - Alice starts sending IKE liveness checks until she is "sure" that the > INVALID_SPI responses are not a DoS attack; this could be "several minutes" > - Then Alice rekeys > > Some other problem cases include: > - Bob has two gateways in some failover architecture. One gateway goes > down, the other gateway detects this and wants to tell Alice to rekey > - Bob has a bunch of gateways in some load-balancing or cluster > architecture. One gateway is taken down on purpose, and the system wants > to tell Alice to rekey > - Protocol robustness: Bob's gateway loses the SA without going down > > Our primary goal is that, as soon as Bob starts sending INVALID_SPI > responses to Alice's ESP traffic, Bob and Alice should be able to > quickly determine that this is not an attack and therefore they probably > want to rekey right away. Note that if Bob and Alice are also using > session resumption, they can use that instead of rekeying; however, in > the discussion here, we always use "rekey" to mean "rekey or, if > appropriate, resume". The proposed extension does not include the actual > rekeying, just the context for them to do it now. > > The WG has seen two proposed solutions, QCD and SIR. The following are > brief summaries of the two proposals. > > In QCD (), Bob gives Alice > a secret token in the AUTH exchange, and then puts the token in his > INVALID_SPI response as a way to say "this SPI is gone". Bob must > remember his tokens across reboots, or derive tokens from a master token > that he memorizes across reboots, and Alice must remember the token (or > a hash of it) for each SA. > > In SIR > (), Alice > sends a new Check_SPI query with a stateless cookie, essentially asking > "do you really not know about this > SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing > is stored on either side, so a man-in-the-middle can attack this to > cause an unnecessary rekey just as they can normal IKE. > > The first task for the WG is to decide which of these two quite > different approaches to take. After we have done that, we can then hone > the chosen proposal. During earlier discussion of the proposals, the > following criteria were mentioned as ones that the WG should consider > when thinking about the approaches: > > - Support for different scenarios (load balancers, active clusters, > failover) > - Security from man-in-the-middle DoS attacks > - Resources used > - Intellectual property rights > > So: please start discussing the two proposals with respect to these > criteria or other criteria that are important to you. In a few weeks > (hopefully well before the Maastricht meeting), I make a call for > consensus and see where it leads us. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From root@core3.amsl.com Tue Aug 10 10:30:05 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 356B03A6A98; Tue, 10 Aug 2010 10:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100810173004.356B03A6A98@core3.amsl.com> Date: Tue, 10 Aug 2010 10:30:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-roadmap-09.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:30:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap Author(s) : S. Frankel, S. Krishnan Filename : draft-ietf-ipsecme-roadmap-09.txt Pages : 61 Date : 2010-08-10 Over the past few years, the number of RFCs that define and use IPsec and IKE has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes the previous IPsec Document Roadmap [RFC2411]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-roadmap-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-roadmap-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-10102811.I-D@ietf.org> --NextPart-- From sheila.frankel@nist.gov Tue Aug 10 10:33:51 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A3973A6A92; Tue, 10 Aug 2010 10:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzVeQeiBg4OA; Tue, 10 Aug 2010 10:33:49 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 590E03A6AAE; Tue, 10 Aug 2010 10:33:49 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o7AHY5d0011924; Tue, 10 Aug 2010 13:34:06 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 10 Aug 2010 13:34:05 -0400 From: "Frankel, Sheila E." To: "david.black@emc.com" , "paul.hoffman@vpnc.org" , "gen-art@ietf.org" , "suresh.krishnan@ericsson.com" Date: Tue, 10 Aug 2010 13:30:46 -0400 Thread-Topic: Roadmap doc updated in response to Gen-ART Review Thread-Index: AQHLOLIvQW+cXxxVikatXwC0wDMO6g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: "ipsec@ietf.org" , "turners@ieca.com" , "yaron.ietf@gmail.com" Subject: [IPsec] Roadmap doc updated in response to Gen-ART Review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:33:51 -0000 An updated IPsec/IKE roadmap (version 09) was submitted in response to the Gen-ART review. Here are the changes that were made in response to that review: > I found one open issue - Sections 5.4.1 and 5.4.2 mis-state the applicability > of combined mode algorithms to IPsec-v2. All of the other comments in this > review are minor. See below. > Section 2.2 lists the RFC # range for IPsec-v1. Please also list the RFC > # ranges for IPsec-v2 and IPsec-v3. The v1 RFCs are mentioned here for completeness, since they are not included elsewhere. For v2 and v3, added the phrase "see Section 3.1.x for the RFC descriptions." > ** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined mode > algorithms are "not a feature of IPsec-v2" and hence lists them as N/A. > That's not correct. The correct situation is: > - Combined mode algorithms for ESP can be negotiated as encryption > algorithms (the integrity protection algorithm would typically > be omitted proposals that do this). > - Combined mode algorithms cannot be used with IKEv1, as they're > incompatible with its design (see the Introduction section of > RFC 5282 for a more detailed explanation). > Hence the N/A entries for IKEv1 are correct, but both AES-CCM and AES-GCM > should be "optional" for ESPv2 (and the NOTE should be revised accordingly). The roadmap already includes the following statement in Section 5.4: Although ESP-v2 did not originally include combined mode algorithms, some IKEv1 implementations have added the capability to negotiate combined mode algorithms for use in IPsec SAs; these implementations do not include the capability to use combined mode algorithms to protect IKE SAs. Added the following to the NOTEs for the combined mode algorithms: Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. > Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC 5116. RFC 5116 described the underlying framework, but does not mention IKE or IPsec. Just as this doc does not include the RFCs that define the SHA-1 algorithm or the HMAC algorithm, it does not include this framework RFC. > Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3. If that > is correct, it should be stated. Added "This document applies only to IKEv1 and IPsec-v2; it does not apply to IKEv2 and IPsec-v3." > Section 8.8.1 also appears to be IPsec-v2 only, and in addition to stating > that should comment that this was not widely adopted, and NAT traversal > is the commonly used mechanism to deal with NATs. Added "Although the model presented here uses terminology from IKEv1, it can be deployed within IKEv1, IKEv2, IPsec-v2 and IPsec-v3. > In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel". If you want > to cite the RFCs involved, IP over FC is RFC 4338 and FC over IP is RFC 3821. Deleted "/SCSI" In general, the roadmap only cites IKE/IPsec-related RFCs, but not the RFCs that define the non-IKE/IPsec underlying protocols. Although RFC 3821 mentions the use of IKE/IPsec for Fibre Channel, unlike RFC 4595, it does not alter IKE/IPsec in any way. > idnits 2.12.04 found some minor nits: > ** There are 4 instances of too long lines in the document, the longest one > being 3 characters in excess of 72. Fixed this. Sheila and Suresh From david.black@emc.com Tue Aug 10 13:41:22 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B182A3A67E1; Tue, 10 Aug 2010 13:41:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.404 X-Spam-Level: X-Spam-Status: No, score=-106.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkW3AxAuUvtV; Tue, 10 Aug 2010 13:41:21 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 58A273A69B2; Tue, 10 Aug 2010 13:41:21 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o7AKfqkt002963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2010 16:41:52 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 10 Aug 2010 16:41:44 -0400 Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com [128.221.166.229]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o7AKeOT3026711; Tue, 10 Aug 2010 16:41:43 -0400 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 16:41:39 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Aug 2010 16:41:38 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Roadmap doc updated in response to Gen-ART Review Thread-Index: AQHLOLIvQW+cXxxVikatXwC0wDMO6pLbI9HA References: From: To: , , , X-OriginalArrivalTime: 10 Aug 2010 20:41:39.0957 (UTC) FILETIME=[6F280A50:01CB38CC] X-EMM-MHVC: 1 X-EMM-MFVC: 1 Cc: ipsec@ietf.org, turners@ieca.com, yaron.ietf@gmail.com, david.black@emc.com Subject: Re: [IPsec] Roadmap doc updated in response to Gen-ART Review X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 20:41:22 -0000 Sheila and Suresh, These changes look good. The only thing I would have added is a sentence in Section 8.8.1 to say that RFC 2709's security model has not been widely adopted, and the more common approach is NAT traversal. Whether to add this is a matter of editorial taste, as NAT traversal is covered earlier in the draft (Sections 3.2.1 and 4.1.2.1), so the -09 version of this draft is fine with me Many thanks for all the time and effort that you've put into this draft. Thanks, --David > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Frankel, Sheila E. > Sent: Tuesday, August 10, 2010 1:31 PM > To: Black, David; paul.hoffman@vpnc.org; gen-art@ietf.org; suresh.krishnan@ericsson.com > Cc: ipsec@ietf.org; turners@ieca.com; yaron.ietf@gmail.com > Subject: [IPsec] Roadmap doc updated in response to Gen-ART Review >=20 > An updated IPsec/IKE roadmap (version 09) was submitted in response to the Gen-ART review. > Here are the changes that were made in response to that review: >=20 > > I found one open issue - Sections 5.4.1 and 5.4.2 mis-state the applicability > > of combined mode algorithms to IPsec-v2. All of the other comments in this > > review are minor. >=20 > See below. >=20 > > Section 2.2 lists the RFC # range for IPsec-v1. Please also list the RFC > > # ranges for IPsec-v2 and IPsec-v3. >=20 > The v1 RFCs are mentioned here for completeness, since they are not included > elsewhere. For v2 and v3, added the phrase "see Section 3.1.x for the RFC > descriptions." >=20 > > ** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined mode > > algorithms are "not a feature of IPsec-v2" and hence lists them as N/A. > > That's not correct. The correct situation is: > > - Combined mode algorithms for ESP can be negotiated as encryption > > algorithms (the integrity protection algorithm would typically > > be omitted proposals that do this). > > - Combined mode algorithms cannot be used with IKEv1, as they're > > incompatible with its design (see the Introduction section of > > RFC 5282 for a more detailed explanation). > > Hence the N/A entries for IKEv1 are correct, but both AES-CCM and AES-GCM > > should be "optional" for ESPv2 (and the NOTE should be revised accordingly). >=20 > The roadmap already includes the following statement in Section 5.4: > Although ESP-v2 did not originally include combined mode algorithms, > some IKEv1 implementations have added the capability to negotiate > combined mode algorithms for use in IPsec SAs; these implementations > do not include the capability to use combined mode algorithms to > protect IKE SAs. >=20 > Added the following to the NOTEs for the combined mode algorithms: > Although some IKEv1/IPsec-v2 implementations include this capability > (see Section 5.4), it is not part of the protocol. >=20 > > Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC 5116. >=20 > RFC 5116 described the underlying framework, but does not mention IKE or IPsec. > Just as this doc does not include the RFCs that define the SHA-1 algorithm or > the HMAC algorithm, it does not include this framework RFC. >=20 > > Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3. If that > > is correct, it should be stated. >=20 > Added "This document applies only to IKEv1 and IPsec-v2; it does not apply to IKEv2 and IPsec-v3." >=20 > > Section 8.8.1 also appears to be IPsec-v2 only, and in addition to stating > > that should comment that this was not widely adopted, and NAT traversal > > is the commonly used mechanism to deal with NATs. >=20 > Added "Although the model presented here uses terminology from IKEv1, it can be deployed within > IKEv1, IKEv2, IPsec-v2 and IPsec-v3. >=20 > > In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel". If you want > > to cite the RFCs involved, IP over FC is RFC 4338 and FC over IP is RFC 3821. >=20 > Deleted "/SCSI" In general, the roadmap only cites IKE/IPsec-related RFCs, but > not the RFCs that define the non-IKE/IPsec underlying protocols. Although > RFC 3821 mentions the use of IKE/IPsec for Fibre Channel, unlike RFC 4595, it > does not alter IKE/IPsec in any way. >=20 > > idnits 2.12.04 found some minor nits: >=20 > > ** There are 4 instances of too long lines in the document, the longest one > > being 3 characters in excess of 72. >=20 > Fixed this. >=20 > Sheila and Suresh > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From david.black@emc.com Tue Aug 10 13:51:33 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002153A6ADB; Tue, 10 Aug 2010 13:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.393 X-Spam-Level: X-Spam-Status: No, score=-106.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eBQvdlnunkF; Tue, 10 Aug 2010 13:51:31 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 3ABB03A6842; Tue, 10 Aug 2010 13:51:30 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o7AKpo4V012186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2010 16:51:51 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.145]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 10 Aug 2010 16:51:45 -0400 Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o7AKpNk2004770; Tue, 10 Aug 2010 16:51:44 -0400 Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 16:50:21 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Aug 2010 16:50:20 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-ipsecme-roadmap-09 Thread-Index: Acshbdh+rbRNBc1hT52qc/HpStEy/gXXw2Fw References: From: To: , , , X-OriginalArrivalTime: 10 Aug 2010 20:50:21.0957 (UTC) FILETIME=[A64AEB50:01CB38CD] X-EMM-MHVC: 1 X-EMM-MFVC: 1 Cc: ipsec@ietf.org, turners@ieca.com, paul.hoffman@vpnc.org, yaronf@checkpoint.com Subject: [IPsec] Gen-ART review of draft-ietf-ipsecme-roadmap-09 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 20:51:33 -0000 I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at = http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq . Summary: This draft is ready for publication as an Informational RFC. The -09 version of this draft has satisfactorily addressed all of the = comments in the Gen-ART review of the -08 version. Many thanks to the = authors. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Sunday, July 11, 2010 10:57 PM > To: 'gen-art@ietf.org'; Frankel, Sheila E.; = 'suresh.krishnan@ericsson.com' > Cc: ipsec@ietf.org; Paul Hoffman; Yaron Sheffer; Sean Turner; Black, = David > Subject: Gen-ART review of draft-ietf-ipsecme-roadmap-08 >=20 > I am the assigned Gen-ART reviewer for this draft. For background on = Gen-ART, please see the FAQ at > http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq . >=20 > Please resolve these comments along with any other comments you may = receive. >=20 > Summary: > This draft is on the right track, but has open issues, described in = the review. >=20 > This is a very useful summary of all of the RFCs (and some in-progress = Internet-Drafts) that specify > or are related to IPsec. It will be very useful to those new to = IPsec, as it describes the > organization of the RFCs and relationships among them. >=20 > I found one open issue - Sections 5.4.1 and 5.4.2 mis-state the = applicability of combined mode > algorithms to IPsec-v2. All of the other comments in this review are = minor. >=20 > Section 2.2 lists the RFC # range for IPsec-v1. Please also list the = RFC # ranges for IPsec-v2 and > IPsec-v3. >=20 > ** Sections 5.4.1 and 5.4.2 both contain a NOTE stating that combined = mode algorithms are "not a > feature of IPsec-v2" and hence lists them as N/A. That's not correct. = The correct situation is: > - Combined mode algorithms for ESP can be negotiated as encryption > algorithms (the integrity protection algorithm would typically > be omitted proposals that do this). > - Combined mode algorithms cannot be used with IKEv1, as they're > incompatible with its design (see the Introduction section of > RFC 5282 for a more detailed explanation). > Hence the N/A entries for IKEv1 are correct, but both AES-CCM and = AES-GCM should be "optional" for > ESPv2 (and the NOTE should be revised accordingly). >=20 > Section 5.4.3 - RFC 5282 is based on a combined mode framework in RFC = 5116. >=20 > Section 8.4.1 appears to apply to IPsec-v2 only, and not IPsec-v3. If = that is correct, it should be > stated. >=20 > Section 8.8.1 also appears to be IPsec-v2 only, and in addition to = stating that should comment that > this was not widely adopted, and NAT traversal is the commonly used = mechanism to deal with NATs. >=20 > In Section 9.2.1, "Fibre Channel/SCSI" --> "Fibre Channel". If you = want to cite the RFCs involved, IP > over FC is RFC 4338 and FC over IP is RFC 3821. >=20 > idnits 2.12.04 found some minor nits: >=20 > ** There are 4 instances of too long lines in the document, the = longest one > being 3 characters in excess of 72. >=20 > 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-7786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From smoonen@us.ibm.com Wed Aug 11 13:23:27 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31E3C3A680C for ; Wed, 11 Aug 2010 13:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.617 X-Spam-Level: X-Spam-Status: No, score=-5.617 tagged_above=-999 required=5 tests=[AWL=0.982, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG2JNp6NGyOV for ; Wed, 11 Aug 2010 13:23:26 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 3582E3A67D1 for ; Wed, 11 Aug 2010 13:23:26 -0700 (PDT) Received: from d03relay05.boulder.ibm.com (d03relay05.boulder.ibm.com [9.17.195.107]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o7BKF6Bd007480 for ; Wed, 11 Aug 2010 14:15:06 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay05.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o7BKNZGQ118462 for ; Wed, 11 Aug 2010 14:23:39 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o7BKNYoN020503 for ; Wed, 11 Aug 2010 14:23:34 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o7BKNY2E020470 for ; Wed, 11 Aug 2010 14:23:34 -0600 X-KeepSent: 13B87C14:6D2A26A3-8525777C:006ECE36; type=4; name=$KeepSent To: ipsec@ietf.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: Scott C Moonen Date: Wed, 11 Aug 2010 16:15:33 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 08/11/2010 14:23:33 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=0ABBFDEFDFFD48A68f9e8a93df938690918c0ABBFDEFDFFD48A6" Content-Disposition: inline Subject: [IPsec] question about ESN and IANA registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 20:23:27 -0000 --0__=0ABBFDEFDFFD48A68f9e8a93df938690918c0ABBFDEFDFFD48A6 Content-type: text/plain; charset=US-ASCII The IANA registry currently lists the ESN transform as optional for ESP, AH in IKEv2. From http://www.iana.org/assignments/ikev2-parameters: Registry: Transform Type Description Used In Reference -------- ------------------------------- --------------------------- --------- . . . 5 Extended Sequence Numbers (ESN) (Optional in AH and ESP) [RFC-ietf-ipsecme-ikev2bis-11.txt] However, both RFC 4306 and ikev2bis indicate that ESN is mandatory: Protocol Mandatory Types Optional Types --------------------------------------------------- IKE ENCR, PRF, INTEG*, D-H ESP ENCR, ESN INTEG, D-H AH INTEG, ESN D-H I believe the registry is in error and I'm hoping that posting here is an effective way to suggest a fix. Thanks, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen --0__=0ABBFDEFDFFD48A68f9e8a93df938690918c0ABBFDEFDFFD48A6 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

The IANA registry currently lists the ESN transform as optional for ESP, AH in IKEv2. From http://www.iana.org/assignments/ikev2-parameters:

Registry:
Transform
Type Description Used In Reference
-------- ------------------------------- --------------------------- ---------
. . .
5 Extended Sequence Numbers (ESN) (Optional in AH and ESP) [RFC-ietf-ipsecme-ikev2bis-11.txt]

However, both RFC 4306 and ikev2bis indicate that ESN is mandatory:

Protocol Mandatory Types Optional Types
---------------------------------------------------
IKE ENCR, PRF, INTEG*, D-H
ESP ENCR, ESN INTEG, D-H
AH INTEG, ESN D-H

I believe the registry is in error and I'm hoping that posting here is an effective way to suggest a fix. Thanks,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/in/smoonen --0__=0ABBFDEFDFFD48A68f9e8a93df938690918c0ABBFDEFDFFD48A6-- From paul.hoffman@vpnc.org Wed Aug 11 14:16:20 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651083A6823 for ; Wed, 11 Aug 2010 14:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.986 X-Spam-Level: X-Spam-Status: No, score=-100.986 tagged_above=-999 required=5 tests=[AWL=1.060, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJU2JgBu5qRn for ; Wed, 11 Aug 2010 14:16:19 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 600E13A67D1 for ; Wed, 11 Aug 2010 14:16:19 -0700 (PDT) Received: from [10.20.30.158] (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7BLGrqW049625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2010 14:16:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 11 Aug 2010 14:16:47 -0700 To: Scott C Moonen , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] question about ESN and IANA registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 21:16:20 -0000 At 4:15 PM -0400 8/11/10, Scott C Moonen wrote: >The IANA registry currently lists the ESN transform as optional for ESP, AH in IKEv2. From http://www.iana.org/assignments/ikev2-parameters: > >Registry: >Transform >Type Description Used In Reference >-------- ------------------------------- --------------------------- --------- >. . . >5 Extended Sequence Numbers (ESN) (Optional in AH and ESP) [RFC-ietf-ipsecme-ikev2bis-11.txt] > >However, both RFC 4306 and ikev2bis indicate that ESN is mandatory: > >Protocol Mandatory Types Optional Types >--------------------------------------------------- >IKE ENCR, PRF, INTEG*, D-H >ESP ENCR, ESN INTEG, D-H >AH INTEG, ESN D-H > >I believe the registry is in error and I'm hoping that posting here is an effective way to suggest a fix. Thanks, I agree that support for ESN is required in both AH and ESP, even if it is only to say "No ESN" in the proposals. --Paul Hoffman, Director --VPN Consortium From root@core3.amsl.com Fri Aug 13 11:15:10 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 09B213A6888; Fri, 13 Aug 2010 11:15:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100813181506.09B213A6888@core3.amsl.com> Date: Fri, 13 Aug 2010 11:15:03 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-roadmap-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 18:15:15 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap Author(s) : S. Frankel, S. Krishnan Filename : draft-ietf-ipsecme-roadmap-10.txt Pages : 61 Date : 2010-08-13 Over the past few years, the number of RFCs that define and use IPsec and IKE has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes the previous IPsec Document Roadmap [RFC2411]. The obsoleted IPsec roadmap [RFC2411] briefly described the interrelationship of the various classes of base IPsec documents. The major focus of [RFC2411] was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-roadmap-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-roadmap-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-13110835.I-D@ietf.org> --NextPart-- From sheila.frankel@nist.gov Fri Aug 13 11:18:34 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0FAE3A67F3; Fri, 13 Aug 2010 11:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0+tf9dlpALZ; Fri, 13 Aug 2010 11:18:33 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 5C7873A6833; Fri, 13 Aug 2010 11:18:33 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o7DIIv2O012043; Fri, 13 Aug 2010 14:18:57 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Fri, 13 Aug 2010 14:18:57 -0400 From: "Frankel, Sheila E." To: "Polk, William T." , "iesg@ietf.org" , Sean Turner Date: Fri, 13 Aug 2010 14:18:37 -0400 Thread-Topic: COMMENT: Thread-Index: Acs6I3ExJISmMnP8QKurchfMIeLZCwA75oVE Message-ID: References: <20100812133607.23681.71079.idtracker@localhost> In-Reply-To: <20100812133607.23681.71079.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: sheila.frankel@nist.gov Cc: "ipsec@ietf.org" , "ipsecme-chairs@tools.ietf.org" , "suresh.krishnan@ericsson.com" Subject: Re: [IPsec] COMMENT: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 18:18:34 -0000 We just submitted an updated version (-10) of the IPsec/IKE Roadmap doc. In accordance with Sean's recommendations, we addressed Tim Polk's comments as follows: > Comment: > (1) I understand that this is a forklift upgrade for RFC 2411, so the usual > "Changes Since ..." section would not be helpful. However, this document > has a very similar title and does obsolete 2411 if approved. Perhaps a few > sentences in the intro to describe that relationship would be useful! The original intro includes: This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes the previous IPsec Document Roadmap [RFC2411]. Added the following: The obsoleted IPsec roadmap [RFC2411] briefly described the interrelationship of the various classes of base IPsec documents. The major focus of [RFC2411] was to specify the recommended contents of documents specifying additional encryption and authentication algorithms. > (2) RFC 5282 should be added to the list of base documents in section > 4.1.2, IKEv2. As noted in section 5.4, 5282 added the capability to negotiate > combined mode algorithms to IKEv2. IKEv2 already has the capability to negotiate combined mode algs for use in ESP/AH. RFC 5282 adds the capability to use combined mode algs for IKEv2's own traffic. This is one of a number of add-ons; it is not part of the base IKEv2. > (3) Section 5.4.3 is misplaced. GMAC is an Integrity protection algorithm > and should appear in section 5.3. This will necessitate forward pointers > to section 5.4, since it is based on a combined mode algorithm, but it does > not fit with the other algorithms in 5.4 which are providing both encryption > and integrity-protection. As stated in Section 5.4.3, GMAC has 2 versions: an integrity protection alg for AH, and a combined mode alg with null enc for ESP. We chose to place it with the combined mode algs, but mentioned it in Section 5.3 (the intro section for integrity protection algs). > (4) In section 5.2.1, last sentence of the first paragraph: > > This number (the value 11 for ESP_NULL) is found on the IANA registries > for both IKEv1 and IKEv2, but it is not mentioned in this RFC. > > "this RFC" is ambiguous - I gather the authors meant RFC 2410 (since the > value is clearly mentioned in *this* RFC). I suggest: > > s/this RFC/[RFC2410]/ DONE Sheila and Suresh ____________________________________ From: Sean Turner [turners@ieca.com] Sent: Thursday, August 12, 2010 12:15 PM To: draft-ietf-ipsecme-roadmap@tools.ietf.org Cc: ipsecme-chairs@tools.ietf.org Subject: Re: COMMENT: The state of this document is now "Approved: point raised - write up needed". I'd like the authors to generate a new version that address #1 and #4. I don't think we should do #2 or #3. They are comments not discusses so we don't have to get him to agree to us not doing them. I'll be watching for the new version. spt From smoonen@us.ibm.com Fri Aug 13 12:07:13 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563353A679F; Fri, 13 Aug 2010 12:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.126 X-Spam-Level: X-Spam-Status: No, score=-5.126 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZHSynVCDEzG; Fri, 13 Aug 2010 12:07:08 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id 8197C3A63D3; Fri, 13 Aug 2010 12:07:07 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o7DJ0JmR002197; Fri, 13 Aug 2010 13:00:19 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o7DJ7Ktp038862; Fri, 13 Aug 2010 13:07:26 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o7DJ7JH8016882; Fri, 13 Aug 2010 13:07:20 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o7DJ7JsG016874; Fri, 13 Aug 2010 13:07:19 -0600 In-Reply-To: <4C6127C7.7070008@gmail.com> References: <4C59D035.50108@gmail.com> <4C6127C7.7070008@gmail.com> X-KeepSent: DDD18999:6E3B5F6D-8525777E:006721B6; type=4; name=$KeepSent To: Yaron Sheffer X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: Scott C Moonen Date: Fri, 13 Aug 2010 15:07:03 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 08/13/2010 13:07:19 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFDEDDFF4A7268f9e8a93df938690918c0ABBFDEDDFF4A726" Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] Failure detection proposals, stage 2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 19:07:13 -0000 --0__=0ABBFDEDDFF4A7268f9e8a93df938690918c0ABBFDEDDFF4A726 Content-type: multipart/alternative; Boundary="1__=0ABBFDEDDFF4A7268f9e8a93df938690918c0ABBFDEDDFF4A726" --1__=0ABBFDEDDFF4A7268f9e8a93df938690918c0ABBFDEDDFF4A726 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I've looked over the two drafts. My summary impression is that I prefe= r QCD, albeit for subjective reasons. It is less complicated and therefo= re simpler to implement and test. I think I would have a higher degree of= confidence in planning it for our implementation, and I suspect it woul= d see more quick and widespread use. Some comments/questions for the individual drafts: QCD: (1) Why can't the N(QCD_TOKEN) appear in the CREATE_CHILD_SA request message for rekeying the IKE SA? (2) The draft (perhaps in the section 5 intro) should emphasize that th= e tokens MUST be produced in such a way that different IKE SPI pairs are unlikely to share the same token value. Recovery: (1) The draft needs to specify how the IKE message header bits are expe= cted to be set for the various flows. (2) The draft should explicitly acknowledge cases where it is (with goo= d reason) breaking specific MUST NOT statements in ikev2bis (e.g., a coup= le of cases of "MUST NOT respond"). (3) I dislike the MITM weakness but I understand that this is not the m= ost attractive fruit for a MITM. (4) Nit: acronym plurals shouldn't use apostrophes (i.e., "SAs" is preferred to "SA's"). Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yaron Sheffer To: IPsecme WG Date: 08/10/2010 06:20 AM Subject: [IPsec] Failure detection proposals, stage 2 Sent by: ipsec-bounces@ietf.org OK, Paul and I are finally convinced that we have sufficient WG interes= t in solving this problem. Now, I'd like to ask the people who have responded (as well as others) to read the two drafts, and to tell us wh= y they prefer the one over the other. Quoting myself: "If you speak up, we will expect you to contribute to the selection of the preferred document". Please respond with comments to the drafts and/or a comparison within the next week, i.e. by August 17. Thanks, Yaron > From: Yaron Sheffer > To: IPsecme WG > Date: 08/04/2010 04:48 PM > Subject: [IPsec] Failure detection proposals > Sent by: ipsec-bounces@ietf.org > > > > In the Maastricht meeting there was just a tiny bit of interest in th= e > failure detection idea (reminder: the goal is to ensure that one peer= > discovers that the other IKE peer has restarted, within a short time > duration, milliseconds instead of minutes). But we didn't see enough > interest to justify having this as a WG item. So, one last time: if y= ou > think this is a worthwhile idea, regardless of the proposals on the > table, please say so publicly. If you speak up, we will expect you to= > contribute to the selection of the preferred document. > > If this is of no interest, fine. But if it is an important problem to= > solve and we don't take it on, we could end up with competing non-WG > proposals. Which would be far from ideal. > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behal= f > Of Paul Hoffman > Sent: Wednesday, July 07, 2010 8:03 PM > To: IPsecme WG > Subject: [IPsec] NUDGE: Starting discussion of failure detection proposals > > [[ This topic generated a fair amount of discussion in the past; are > folks still interested? ]] > > Greetings again. The WG has one item on our charter that we have bare= ly > discussed, namely failure detection. The charter item says that the w= ork > item is: > >> - A standards-track IKEv2 extension that allows an IKE peer to quick= ly and > securely detect that its opposite peer, while currently reachable, ha= s lost > its IKEv2/IPsec state. Changes to how the peers recover from this situation > are beyond the scope of this work item, as is improving the detection= of an > unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and > draft-detienne-ikev2-recovery-03 can be used as starting points. > > I gave a brief presentation on failure detection at the last IETF > meeting in Anaheim. The slides are at > , and the > following is directly derived from them. > > The basic problem being covered by the new extension is: > - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob= > crashes > - Alice keeps sending ESP to Bob > - When Bob finally comes back up, he replies to Alice's ESP with > INVALID_SPI notifications > - Alice starts sending IKE liveness checks until she is "sure" that = the > INVALID_SPI responses are not a DoS attack; this could be "several minutes" > - Then Alice rekeys > > Some other problem cases include: > - Bob has two gateways in some failover architecture. One gateway go= es > down, the other gateway detects this and wants to tell Alice to rekey= > - Bob has a bunch of gateways in some load-balancing or cluster > architecture. One gateway is taken down on purpose, and the system wa= nts > to tell Alice to rekey > - Protocol robustness: Bob's gateway loses the SA without going dow= n > > Our primary goal is that, as soon as Bob starts sending INVALID_SPI > responses to Alice's ESP traffic, Bob and Alice should be able to > quickly determine that this is not an attack and therefore they proba= bly > want to rekey right away. Note that if Bob and Alice are also using > session resumption, they can use that instead of rekeying; however, i= n > the discussion here, we always use "rekey" to mean "rekey or, if > appropriate, resume". The proposed extension does not include the act= ual > rekeying, just the context for them to do it now. > > The WG has seen two proposed solutions, QCD and SIR. The following ar= e > brief summaries of the two proposals. > > In QCD (), Bob gives Al= ice > a secret token in the AUTH exchange, and then puts the token in his > INVALID_SPI response as a way to say "this SPI is gone". Bob must > remember his tokens across reboots, or derive tokens from a master to= ken > that he memorizes across reboots, and Alice must remember the token (= or > a hash of it) for each SA. > > In SIR > (), Al= ice > sends a new Check_SPI query with a stateless cookie, essentially aski= ng > "do you really not know about this > SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothi= ng > is stored on either side, so a man-in-the-middle can attack this to > cause an unnecessary rekey just as they can normal IKE. > > The first task for the WG is to decide which of these two quite > different approaches to take. After we have done that, we can then ho= ne > the chosen proposal. During earlier discussion of the proposals, the > following criteria were mentioned as ones that the WG should consider= > when thinking about the approaches: > > - Support for different scenarios (load balancers, active clusters, > failover) > - Security from man-in-the-middle DoS attacks > - Resources used > - Intellectual property rights > > So: please start discussing the two proposals with respect to these > criteria or other criteria that are important to you. In a few weeks > (hopefully well before the Maastricht meeting), I make a call for > consensus and see where it leads us. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBFDEDDFF4A7268f9e8a93df938690918c0ABBFDEDDFF4A726 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I've looked over the two drafts. My summary impression is that I pr= efer QCD, albeit for subjective reasons. It is less complicated and th= erefore simpler to implement and test. I think I would have a higher d= egree of confidence in planning it for our implementation, and I suspec= t it would see more quick and widespread use.

Some comments/questions for the individual drafts:

QCD:
(1) Why can't the N(QCD_TOKEN) appear in the CREATE_CHILD_SA request me= ssage for rekeying the IKE SA?
(2) The draft (perhaps in the section 5 intro) should emphasize that th= e tokens MUST be produced in such a way that different IKE SPI pairs ar= e unlikely to share the same token value.

Recovery:
(1) The draft needs to specify how the IKE message header bits are expe= cted to be set for the various flows.
(2) The draft should explicitly acknowledge cases where it is (with goo= d reason) breaking specific MUST NOT statements in ikev2bis (e.g., a co= uple of cases of "MUST NOT respond").
(3) I dislike the MITM weakness but I understand that this is not the m= ost attractive fruit for a MITM.
(4) Nit: acronym plurals shouldn't use apostrophes (i.e., "SAs&quo= t; is preferred to "SA's").


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen

3D"InactiveYaron Sheffer ---08/= 10/2010 06:20:17 AM---OK, Paul and I are finally convinced that we have= sufficient WG interest in solving this problem. N

From: Yaron = Sheffer <yaronf.ietf@gmail.com>
To: IPsecme = WG <ipsec@ietf.org>
Date: 08/10/= 2010 06:20 AM
Subject: [IP= sec] Failure detection proposals, stage 2
Sent by: ips= ec-bounces@ietf.org




OK, Paul and I are finally convinced that we have sufficient WG int= erest
in solving this problem. Now, I'd like to ask the people who have
responded (as well as others) to read the two drafts, and to tell us wh= y
they prefer the one over the other.

Quoting myself: "If you speak up, we will expect you to contribute= to
the selection of the preferred document".

Please respond with comments to the drafts and/or a comparison within <= br> the next week, i.e. by August 17.

Thanks,
Yaron

> From: Yaron Sheffer<yaronf.ietf@gmail.com>
> To: IPsecme WG<ipsec@ietf.org>
> Date: 08/04/2010 04:48 PM
> Subject: [IPsec] Failure detection proposals
> Sent by: ipsec-bounces@ietf.org
>
>
>
> In the Maastricht meeting there was just a tiny bit of interest in= the
> failure detection idea (reminder: the goal is to ensure that one p= eer
> discovers that the other IKE peer has restarted, within a short ti= me
> duration, milliseconds instead of minutes). But we didn't see enou= gh
> interest to justify having this as a WG item. So, one last time: i= f you
> think this is a worthwhile idea, regardless of the proposals on th= e
> table, please say so publicly. If you speak up, we will expect you= to
> contribute to the selection of the preferred document.
>
> If this is of no interest, fine. But if it is an important problem= to
> solve and we don't take it on, we could end up with competing non-= WG
> proposals. Which would be far from ideal.
>
> Thanks,
> Yaron
>
> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Paul Hoffman
> Sent: Wednesday, July 07, 2010 8:03 PM
> To: IPsecme WG
> Subject: [IPsec] NUDGE: Starting discussion of failure detection p= roposals
>
> [[ This topic generated a fair amount of discussion in the past; a= re
> folks still interested? ]]
>
> Greetings again. The WG has one item on our charter that we have b= arely
> discussed, namely failure detection. The charter item says that th= e work
> item is:
>
>> - A standards-track IKEv2 extension that allows an IKE peer to= quickly and
> securely detect that its opposite peer, while currently reachable,= has lost
> its IKEv2/IPsec state. Changes to how the peers recover from this = situation
> are beyond the scope of this work item, as is improving the detect= ion of an
> unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and
> draft-detienne-ikev2-recovery-03 can be used as starting points. >
> I gave a brief presentation on failure detection at the last IETF<= br> > meeting in Anaheim. The slides are at
> <http://www.ietf.org/proceedings/77/slides/ipsecme-4.pdf<= /a>>, and the
> following is directly derived from them.
>
> The basic problem being covered by the new extension is:
> -  Alice and Bob have SAs up and ESP traffic is flowing, but = then Bob
> crashes
> -  Alice keeps sending ESP to Bob
> -  When Bob finally comes back up, he replies to Alice's ESP = with
> INVALID_SPI notifications
> -  Alice starts sending IKE liveness checks until she is &quo= t;sure" that the
> INVALID_SPI responses are not a DoS attack; this could be "se= veral minutes"
> -  Then Alice rekeys
>
> Some other problem cases include:
> -  Bob has two gateways in some failover architecture. One ga= teway goes
> down, the other gateway detects this and wants to tell Alice to re= key
> -  Bob has a bunch of gateways in some load-balancing or clus= ter
> architecture. One gateway is taken down on purpose, and the system= wants
> to tell Alice to rekey
> -  Protocol robustness:  Bob's gateway loses the SA with= out going down
>
> Our primary goal is that, as soon as Bob starts sending INVALID_SP= I
> responses to Alice's ESP traffic, Bob and Alice should be able to<= br> > quickly determine that this is not an attack and therefore they pr= obably
> want to rekey right away. Note that if Bob and Alice are also usin= g
> session resumption, they can use that instead of rekeying; however= , in
> the discussion here, we always use "rekey" to mean "= ;rekey or, if
> appropriate, resume". The proposed extension does not include= the actual
> rekeying, just the context for them to do it now.
>
> The WG has seen two proposed solutions, QCD and SIR. The following= are
> brief summaries of the two proposals.
>
> In QCD (<http://tools.ietf.org/html/draft-nir-ike-qcd&g= t;), Bob gives Alice
> a secret token in the AUTH exchange, and then puts the token in hi= s
> INVALID_SPI response as a way to say "this SPI is gone".= Bob must
> remember his tokens across reboots, or derive tokens from a master= token
> that he memorizes across reboots, and Alice must remember the toke= n (or
> a hash of it) for each SA.
>
> In SIR
> (<http://tools.ietf.org/id/draft-detienne-ikev2-rec= overy-03.txt>), Alice
> sends a new Check_SPI query with a stateless cookie, essentially a= sking
> "do you really not know about this
> SPI?"; Bob responds by saying "I'm sure I don't know tha= t SPI". Nothing
> is stored on either side, so a man-in-the-middle can attack this t= o
> cause an unnecessary rekey just as they can normal IKE.
>
> The first task for the WG is to decide which of these two quite > different approaches to take. After we have done that, we can then= hone
> the chosen proposal. During earlier discussion of the proposals, t= he
> following criteria were mentioned as ones that the WG should consi= der
> when thinking about the approaches:
>
> -  Support for different scenarios (load balancers, active cl= usters,
> failover)
> -  Security from man-in-the-middle DoS attacks
> -  Resources used
> -  Intellectual property rights
>
> So: please start discussing the two proposals with respect to thes= e
> criteria or other criteria that are important to you. In a few wee= ks
> (hopefully well before the Maastricht meeting), I make a call for<= br> > consensus and see where it leads us.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> h= ttps://www.ietf.org/mailman/listinfo/ipsec
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> h= ttps://www.ietf.org/mailman/listinfo/ipsec
>
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> h= ttps://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec

= --1__=0ABBFDEDDFF4A7268f9e8a93df938690918c0ABBFDEDDFF4A726-- --0__=0ABBFDEDDFF4A7268f9e8a93df938690918c0ABBFDEDDFF4A726 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFDEDDFF4A7268f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFDEDDFF4A7268f9e8a93df938690918c0ABBFDEDDFF4A726-- From ynir@checkpoint.com Fri Aug 13 12:29:05 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB95F3A6836; Fri, 13 Aug 2010 12:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF0gBYLl9EOU; Fri, 13 Aug 2010 12:29:05 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id CA48E3A68D8; Fri, 13 Aug 2010 12:29:01 -0700 (PDT) X-CheckPoint: {4C65AB04-3-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o7DJTaIg025260; Fri, 13 Aug 2010 22:29:36 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 13 Aug 2010 22:30:05 +0300 From: Yoav Nir To: Scott C Moonen Date: Fri, 13 Aug 2010 22:29:34 +0300 Thread-Topic: [IPsec] Failure detection proposals, stage 2 Thread-Index: Acs7He33RhgqUcopRoaCB5Sx1eEahA== Message-ID: <65A407A0-6E5D-4619-BE09-F867457E905F@checkpoint.com> References: <4C59D035.50108@gmail.com> <4C6127C7.7070008@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Failure detection proposals, stage 2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 19:29:06 -0000 On Aug 13, 2010, at 10:07 PM, Scott C Moonen wrote: > I've looked over the two drafts. My summary impression is that I prefer Q= CD, albeit for subjective reasons. It is less complicated and therefore sim= pler to implement and test. I think I would have a higher degree of confide= nce in planning it for our implementation, and I suspect it would see more = quick and widespread use. >=20 > Some comments/questions for the individual drafts: >=20 > QCD: > (1) Why can't the N(QCD_TOKEN) appear in the CREATE_CHILD_SA request mess= age for rekeying the IKE SA? >=20 The QCD token depends on the IKE SPIs. The Initiator SPI is sent in the req= uest, but the Responder SPI is sent in the response. Because of this, the I= nitiator cannot calculate the QCD token when sending the rekey request. The= responder, however, has both IKE SPIs, and is able to send the QCD token i= n the CREATE_CHILD_SA response. > (2) The draft (perhaps in the section 5 intro) should emphasize that the = tokens MUST be produced in such a way that different IKE SPI pairs are unli= kely to share the same token value. >=20 I can add a bullet point there saying something like "The method of token g= eneration MUST be such, that a collision of QCD tokens between different pa= irs of IKE SPI will be highly unlikely." Is that satisfactory? I will leave it to others to answer for SIR. From smoonen@us.ibm.com Fri Aug 13 12:37:35 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569A33A63D3; Fri, 13 Aug 2010 12:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.962 X-Spam-Level: X-Spam-Status: No, score=-4.962 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDHtqdR8zeaG; Fri, 13 Aug 2010 12:37:34 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id C909F3A6955; Fri, 13 Aug 2010 12:37:33 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e38.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o7DJUklv030959; Fri, 13 Aug 2010 13:30:46 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o7DJbvr9090678; Fri, 13 Aug 2010 13:37:59 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o7DJbtw9021196; Fri, 13 Aug 2010 13:37:56 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o7DJbtPo021184; Fri, 13 Aug 2010 13:37:55 -0600 In-Reply-To: <65A407A0-6E5D-4619-BE09-F867457E905F@checkpoint.com> References: <4C59D035.50108@gmail.com> <4C6127C7.7070008@gmail.com> <65A407A0-6E5D-4619-BE09-F867457E905F@checkpoint.com> X-KeepSent: 195F894D:AF3AEC2F-8525777E:006BAF88; type=4; name=$KeepSent To: Yoav Nir X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: Scott C Moonen Date: Fri, 13 Aug 2010 15:37:49 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 08/13/2010 13:37:55 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBFDEDDFF829188f9e8a93df938690918c0ABBFDEDDFF82918" Cc: IPsecme WG , "ipsec-bounces@ietf.org" Subject: Re: [IPsec] Failure detection proposals, stage 2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 19:37:35 -0000 --0__=0ABBFDEDDFF829188f9e8a93df938690918c0ABBFDEDDFF82918 Content-type: multipart/alternative; Boundary="1__=0ABBFDEDDFF829188f9e8a93df938690918c0ABBFDEDDFF82918" --1__=0ABBFDEDDFF829188f9e8a93df938690918c0ABBFDEDDFF82918 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Yoav, > The QCD token depends on the IKE SPIs. The Initiator SPI is sent in t= he > request, but the Responder SPI is sent in the response. Because of th= is, > the Initiator cannot calculate the QCD token when sending the rekey request. > The responder, however, has both IKE SPIs, and is able to send the QC= D token > in the CREATE_CHILD_SA response. Aah, right, that makes sense. > I can add a bullet point there saying something like "The method of t= oken > generation MUST be such, that a collision of QCD tokens between diffe= rent > pairs of IKE SPI will be highly unlikely." Is that satisfactory? Yes, thanks! Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yoav Nir To: Scott C Moonen/Raleigh/IBM@IBMUS Cc: Yaron Sheffer , IPsecme WG , "ipsec-bounces@ietf.org" Date: 08/13/2010 03:34 PM Subject: Re: [IPsec] Failure detection proposals, stage 2 On Aug 13, 2010, at 10:07 PM, Scott C Moonen wrote: > I've looked over the two drafts. My summary impression is that I pref= er QCD, albeit for subjective reasons. It is less complicated and therefor= e simpler to implement and test. I think I would have a higher degree of confidence in planning it for our implementation, and I suspect it woul= d see more quick and widespread use. > > Some comments/questions for the individual drafts: > > QCD: > (1) Why can't the N(QCD_TOKEN) appear in the CREATE_CHILD_SA request message for rekeying the IKE SA? > The QCD token depends on the IKE SPIs. The Initiator SPI is sent in the= request, but the Responder SPI is sent in the response. Because of this= , the Initiator cannot calculate the QCD token when sending the rekey request. The responder, however, has both IKE SPIs, and is able to send= the QCD token in the CREATE_CHILD_SA response. > (2) The draft (perhaps in the section 5 intro) should emphasize that = the tokens MUST be produced in such a way that different IKE SPI pairs are unlikely to share the same token value. > I can add a bullet point there saying something like "The method of tok= en generation MUST be such, that a collision of QCD tokens between differe= nt pairs of IKE SPI will be highly unlikely." Is that satisfactory? I will leave it to others to answer for SIR. = --1__=0ABBFDEDDFF829188f9e8a93df938690918c0ABBFDEDDFF82918 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Yoav,

> The QCD token depends on the IKE SPIs. The Initiator SPI is se= nt in the
> request, but the Responder SPI is sent in the response. Becaus= e of this,
> the Initiator cannot calculate the QCD token when sending the = rekey request.
> The responder, however, has both IKE SPIs, and is able to send= the QCD token
> in the CREATE_CHILD_SA response.

Aah, right, that makes sense.

> I can add a bullet point there saying something like "The= method of token
> generation MUST be such, that a collision of QCD tokens betwee= n different
> pairs of IKE SPI will be highly unlikely." Is that satisf= actory?

Yes, thanks!


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen

3D"InactiveYoav Nir ---08/13= /2010 03:34:22 PM---On Aug 13, 2010, at 10:07 PM, Scott C Moonen wrote:= > I've looked over the two drafts. My summary im

From: Yoav N= ir <ynir@checkpoint.com>
To: Scott C = Moonen/Raleigh/IBM@IBMUS
Cc: Yaron Sh= effer <yaronf.ietf@gmail.com>, IPsecme WG <ipsec@ietf.org>,= "ipsec-bounces@ietf.org" <ipsec-bounces@ietf.org>
Date: 08/13/= 2010 03:34 PM
Subject: Re:= [IPsec] Failure detection proposals, stage 2





On Aug 13, 2010, at 10:07 PM, Scott C Moonen wrote:

> I've looked over the two drafts. My summary impression is that I p= refer QCD, albeit for subjective reasons. It is less complicated and th= erefore simpler to implement and test. I think I would have a higher de= gree of confidence in planning it for our implementation, and I suspect= it would see more quick and widespread use.
>
> Some comments/questions for the individual drafts:
>
> QCD:
> (1) Why can't the N(QCD_TOKEN) appear in the CREATE_CHILD_SA reque= st message for rekeying the IKE SA?
>
The QCD token depends on the IKE SPIs. The Initiator SPI is sent in the= request, but the Responder SPI is sent in the response. Because of thi= s, the Initiator cannot calculate the QCD token when sending the rekey = request. The responder, however, has both IKE SPIs, and is able to send= the QCD token in the CREATE_CHILD_SA response.

> (2) The draft (perhaps in the section 5 intro) should emphasize th= at the tokens MUST be produced in such a way that different IKE SPI pai= rs are unlikely to share the same token value.
>

I can add a bullet point there saying something like "The method o= f token generation MUST be such, that a collision of QCD tokens between= different pairs of IKE SPI will be highly unlikely." Is that sati= sfactory?


I will leave it to others to answer for SIR.


= --1__=0ABBFDEDDFF829188f9e8a93df938690918c0ABBFDEDDFF82918-- --0__=0ABBFDEDDFF829188f9e8a93df938690918c0ABBFDEDDFF82918 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBFDEDDFF829188f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFDEDDFF829188f9e8a93df938690918c0ABBFDEDDFF82918-- From wierbows@us.ibm.com Sun Aug 15 20:20:47 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22FD63A68F8; Sun, 15 Aug 2010 20:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.25 X-Spam-Level: X-Spam-Status: No, score=-4.25 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykE7TUJ7y1tn; Sun, 15 Aug 2010 20:20:45 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by core3.amsl.com (Postfix) with ESMTP id 0771C3A688F; Sun, 15 Aug 2010 20:20:44 -0700 (PDT) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e7.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o7G37cRM020104; Sun, 15 Aug 2010 23:07:38 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o7G3LEBD1634384; Sun, 15 Aug 2010 23:21:14 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o7G3LEhM011986; Mon, 16 Aug 2010 00:21:14 -0300 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o7G3LEH6011971; Mon, 16 Aug 2010 00:21:14 -0300 In-Reply-To: References: <4C59D035.50108@gmail.com> <4C6127C7.7070008@gmail.com> X-KeepSent: F2146BD2:D8A567E3-85257781:00117E8E; type=4; name=$KeepSent To: IPsecme WG , ipsec-bounces@ietf.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 Message-ID: From: David Wierbowski Date: Sun, 15 Aug 2010 23:21:07 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 08/15/2010 23:21:13 MIME-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0ABBFD12DF82F81E8f9e8a93df938690918c0ABBFD12DF82F81E" Content-Disposition: inline Subject: Re: [IPsec] Failure detection proposals, stage 2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 03:20:47 -0000 --0__=0ABBFD12DF82F81E8f9e8a93df938690918c0ABBFD12DF82F81E Content-type: text/plain; charset=US-ASCII I also prefer the QCD draft over the SIR draft. My reasons are similar to Scott's. I feel the method in QCD is sufficient and the SIR method is overly complex for the problem at hand. I think SIR would be bigger to implement and more error prone than QCD. In short I think the SIR method is a much bigger stick than needed. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 From: Scott C Moonen/Raleigh/IBM@IBMUS To: Yaron Sheffer Cc: IPsecme WG , ipsec-bounces@ietf.org Date: 08/13/2010 03:10 PM Subject: Re: [IPsec] Failure detection proposals, stage 2 Sent by: ipsec-bounces@ietf.org I've looked over the two drafts. My summary impression is that I prefer QCD, albeit for subjective reasons. It is less complicated and therefore simpler to implement and test. I think I would have a higher degree of confidence in planning it for our implementation, and I suspect it would see more quick and widespread use. Some comments/questions for the individual drafts: QCD: (1) Why can't the N(QCD_TOKEN) appear in the CREATE_CHILD_SA request message for rekeying the IKE SA? (2) The draft (perhaps in the section 5 intro) should emphasize that the tokens MUST be produced in such a way that different IKE SPI pairs are unlikely to share the same token value. Recovery: (1) The draft needs to specify how the IKE message header bits are expected to be set for the various flows. (2) The draft should explicitly acknowledge cases where it is (with good reason) breaking specific MUST NOT statements in ikev2bis (e.g., a couple of cases of "MUST NOT respond"). (3) I dislike the MITM weakness but I understand that this is not the most attractive fruit for a MITM. (4) Nit: acronym plurals shouldn't use apostrophes (i.e., "SAs" is preferred to "SA's"). Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen (Embedded image moved to file: pic56651.gif)Inactive hide details for Yaron Sheffer ---08/10/2010 06:20:17 AM---OK, Paul and I are finally convinced that we have sufficienYaron Sheffer ---08/10/2010 06:20:17 AM---OK, Paul and I are finally convinced that we have sufficient WG interest in solving this problem. N From: Yaron Sheffer To: IPsecme WG Date: 08/10/2010 06:20 AM Subject: [IPsec] Failure detection proposals, stage 2 Sent by: ipsec-bounces@ietf.org OK, Paul and I are finally convinced that we have sufficient WG interest in solving this problem. Now, I'd like to ask the people who have responded (as well as others) to read the two drafts, and to tell us why they prefer the one over the other. Quoting myself: "If you speak up, we will expect you to contribute to the selection of the preferred document". Please respond with comments to the drafts and/or a comparison within the next week, i.e. by August 17. Thanks, Yaron > From: Yaron Sheffer > To: IPsecme WG > Date: 08/04/2010 04:48 PM > Subject: [IPsec] Failure detection proposals > Sent by: ipsec-bounces@ietf.org > > > > In the Maastricht meeting there was just a tiny bit of interest in the > failure detection idea (reminder: the goal is to ensure that one peer > discovers that the other IKE peer has restarted, within a short time > duration, milliseconds instead of minutes). But we didn't see enough > interest to justify having this as a WG item. So, one last time: if you > think this is a worthwhile idea, regardless of the proposals on the > table, please say so publicly. If you speak up, we will expect you to > contribute to the selection of the preferred document. > > If this is of no interest, fine. But if it is an important problem to > solve and we don't take it on, we could end up with competing non-WG > proposals. Which would be far from ideal. > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Paul Hoffman > Sent: Wednesday, July 07, 2010 8:03 PM > To: IPsecme WG > Subject: [IPsec] NUDGE: Starting discussion of failure detection proposals > > [[ This topic generated a fair amount of discussion in the past; are > folks still interested? ]] > > Greetings again. The WG has one item on our charter that we have barely > discussed, namely failure detection. The charter item says that the work > item is: > >> - A standards-track IKEv2 extension that allows an IKE peer to quickly and > securely detect that its opposite peer, while currently reachable, has lost > its IKEv2/IPsec state. Changes to how the peers recover from this situation > are beyond the scope of this work item, as is improving the detection of an > unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and > draft-detienne-ikev2-recovery-03 can be used as starting points. > > I gave a brief presentation on failure detection at the last IETF > meeting in Anaheim. The slides are at > , and the > following is directly derived from them. > > The basic problem being covered by the new extension is: > - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob > crashes > - Alice keeps sending ESP to Bob > - When Bob finally comes back up, he replies to Alice's ESP with > INVALID_SPI notifications > - Alice starts sending IKE liveness checks until she is "sure" that the > INVALID_SPI responses are not a DoS attack; this could be "several minutes" > - Then Alice rekeys > > Some other problem cases include: > - Bob has two gateways in some failover architecture. One gateway goes > down, the other gateway detects this and wants to tell Alice to rekey > - Bob has a bunch of gateways in some load-balancing or cluster > architecture. One gateway is taken down on purpose, and the system wants > to tell Alice to rekey > - Protocol robustness: Bob's gateway loses the SA without going down > > Our primary goal is that, as soon as Bob starts sending INVALID_SPI > responses to Alice's ESP traffic, Bob and Alice should be able to > quickly determine that this is not an attack and therefore they probably > want to rekey right away. Note that if Bob and Alice are also using > session resumption, they can use that instead of rekeying; however, in > the discussion here, we always use "rekey" to mean "rekey or, if > appropriate, resume". The proposed extension does not include the actual > rekeying, just the context for them to do it now. > > The WG has seen two proposed solutions, QCD and SIR. The following are > brief summaries of the two proposals. > > In QCD (), Bob gives Alice > a secret token in the AUTH exchange, and then puts the token in his > INVALID_SPI response as a way to say "this SPI is gone". Bob must > remember his tokens across reboots, or derive tokens from a master token > that he memorizes across reboots, and Alice must remember the token (or > a hash of it) for each SA. > > In SIR > (), Alice > sends a new Check_SPI query with a stateless cookie, essentially asking > "do you really not know about this > SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing > is stored on either side, so a man-in-the-middle can attack this to > cause an unnecessary rekey just as they can normal IKE. > > The first task for the WG is to decide which of these two quite > different approaches to take. After we have done that, we can then hone > the chosen proposal. During earlier discussion of the proposals, the > following criteria were mentioned as ones that the WG should consider > when thinking about the approaches: > > - Support for different scenarios (load balancers, active clusters, > failover) > - Security from man-in-the-middle DoS attacks > - Resources used > - Intellectual property rights > > So: please start discussing the two proposals with respect to these > criteria or other criteria that are important to you. In a few weeks > (hopefully well before the Maastricht meeting), I make a call for > consensus and see where it leads us. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --0__=0ABBFD12DF82F81E8f9e8a93df938690918c0ABBFD12DF82F81E Content-type: image/gif; name="pic56651.gif" Content-Disposition: attachment; filename="pic56651.gif" Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBFD12DF82F81E8f9e8a93df938690918c0ABBFD12DF82F81E-- From apvelan@cisco.com Sun Aug 15 22:09:10 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B7463A6824 for ; Sun, 15 Aug 2010 22:09:10 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-O8xbEMP+NM for ; Sun, 15 Aug 2010 22:09:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2718C3A67ED for ; Sun, 15 Aug 2010 22:09:09 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEJlaExAaMHG/2dsb2JhbACgQHGeNZprhTsEhCuIIA X-IronPort-AV: E=Sophos;i="4.55,374,1278288000"; d="scan'208";a="352334823" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 16 Aug 2010 05:09:44 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7G59CXK019761; Mon, 16 Aug 2010 05:09:36 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Aug 2010 10:39:13 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Aug 2010 10:37:03 +0530 Message-ID: In-Reply-To: <4C6127C7.7070008@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Failure detection proposals, stage 2 Thread-Index: Acs4dZvLNNDExhPZTeuIUDyH4YwRrAEilLCA References: <4C6127C7.7070008@gmail.com> From: "Palanivelan A (apvelan)" To: "Yaron Sheffer" , "IPsecme WG" X-OriginalArrivalTime: 16 Aug 2010 05:09:13.0247 (UTC) FILETIME=[2ACC12F0:01CB3D01] Subject: Re: [IPsec] Failure detection proposals, stage 2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 05:09:10 -0000 Hi, I had a look at both the documents and here are my thoughts. I support QCD to be taken forward of the two. Both these documents have good thoughts in addressing the issue, but also have gaps in terms of security. Both these designs are prone to security attacks and going by the proposed solutions, the QCD seems the better of the two. Some effort into Liveness detection mechanism , the method of generating secured QCD token and managing the token in an optimized manner are some of the items that can be worked on from the QCD draft. I think, Fixing these items would lead to a more secured and acceptable solution and I will be more than happy to work with the team on these items. Thanks and Regards, A.Palanivelan -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Tuesday, August 10, 2010 3:50 PM To: IPsecme WG Subject: [IPsec] Failure detection proposals, stage 2 OK, Paul and I are finally convinced that we have sufficient WG interest in solving this problem. Now, I'd like to ask the people who have=20 responded (as well as others) to read the two drafts, and to tell us why they prefer the one over the other. Quoting myself: "If you speak up, we will expect you to contribute to=20 the selection of the preferred document". Please respond with comments to the drafts and/or a comparison within=20 the next week, i.e. by August 17. Thanks, Yaron > From: Yaron Sheffer > To: IPsecme WG > Date: 08/04/2010 04:48 PM > Subject: [IPsec] Failure detection proposals > Sent by: ipsec-bounces@ietf.org > > > > In the Maastricht meeting there was just a tiny bit of interest in the > failure detection idea (reminder: the goal is to ensure that one peer > discovers that the other IKE peer has restarted, within a short time > duration, milliseconds instead of minutes). But we didn't see enough > interest to justify having this as a WG item. So, one last time: if you > think this is a worthwhile idea, regardless of the proposals on the > table, please say so publicly. If you speak up, we will expect you to > contribute to the selection of the preferred document. > > If this is of no interest, fine. But if it is an important problem to > solve and we don't take it on, we could end up with competing non-WG > proposals. Which would be far from ideal. > > Thanks, > Yaron > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Paul Hoffman > Sent: Wednesday, July 07, 2010 8:03 PM > To: IPsecme WG > Subject: [IPsec] NUDGE: Starting discussion of failure detection proposals > > [[ This topic generated a fair amount of discussion in the past; are > folks still interested? ]] > > Greetings again. The WG has one item on our charter that we have barely > discussed, namely failure detection. The charter item says that the work > item is: > >> - A standards-track IKEv2 extension that allows an IKE peer to quickly and > securely detect that its opposite peer, while currently reachable, has lost > its IKEv2/IPsec state. Changes to how the peers recover from this situation > are beyond the scope of this work item, as is improving the detection of an > unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and > draft-detienne-ikev2-recovery-03 can be used as starting points. > > I gave a brief presentation on failure detection at the last IETF > meeting in Anaheim. The slides are at > , and the > following is directly derived from them. > > The basic problem being covered by the new extension is: > - Alice and Bob have SAs up and ESP traffic is flowing, but then Bob > crashes > - Alice keeps sending ESP to Bob > - When Bob finally comes back up, he replies to Alice's ESP with > INVALID_SPI notifications > - Alice starts sending IKE liveness checks until she is "sure" that the > INVALID_SPI responses are not a DoS attack; this could be "several minutes" > - Then Alice rekeys > > Some other problem cases include: > - Bob has two gateways in some failover architecture. One gateway goes > down, the other gateway detects this and wants to tell Alice to rekey > - Bob has a bunch of gateways in some load-balancing or cluster > architecture. One gateway is taken down on purpose, and the system wants > to tell Alice to rekey > - Protocol robustness: Bob's gateway loses the SA without going down > > Our primary goal is that, as soon as Bob starts sending INVALID_SPI > responses to Alice's ESP traffic, Bob and Alice should be able to > quickly determine that this is not an attack and therefore they probably > want to rekey right away. Note that if Bob and Alice are also using > session resumption, they can use that instead of rekeying; however, in > the discussion here, we always use "rekey" to mean "rekey or, if > appropriate, resume". The proposed extension does not include the actual > rekeying, just the context for them to do it now. > > The WG has seen two proposed solutions, QCD and SIR. The following are > brief summaries of the two proposals. > > In QCD (), Bob gives Alice > a secret token in the AUTH exchange, and then puts the token in his > INVALID_SPI response as a way to say "this SPI is gone". Bob must > remember his tokens across reboots, or derive tokens from a master token > that he memorizes across reboots, and Alice must remember the token (or > a hash of it) for each SA. > > In SIR > (), Alice > sends a new Check_SPI query with a stateless cookie, essentially asking > "do you really not know about this > SPI?"; Bob responds by saying "I'm sure I don't know that SPI". Nothing > is stored on either side, so a man-in-the-middle can attack this to > cause an unnecessary rekey just as they can normal IKE. > > The first task for the WG is to decide which of these two quite > different approaches to take. After we have done that, we can then hone > the chosen proposal. During earlier discussion of the proposals, the > following criteria were mentioned as ones that the WG should consider > when thinking about the approaches: > > - Support for different scenarios (load balancers, active clusters, > failover) > - Security from man-in-the-middle DoS attacks > - Resources used > - Intellectual property rights > > So: please start discussing the two proposals with respect to these > criteria or other criteria that are important to you. In a few weeks > (hopefully well before the Maastricht meeting), I make a call for > consensus and see where it leads us. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From zhangdacheng@huawei.com Mon Aug 16 03:31:37 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A4163A69A5 for ; Mon, 16 Aug 2010 03:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYFG2R47Lwd5 for ; Mon, 16 Aug 2010 03:31:35 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 1E1D03A69B1 for ; Mon, 16 Aug 2010 03:31:35 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7800CEVQLCKR@szxga04-in.huawei.com> for ipsec@ietf.org; Mon, 16 Aug 2010 18:32:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7800CL9QLB33@szxga04-in.huawei.com> for ipsec@ietf.org; Mon, 16 Aug 2010 18:31:59 +0800 (CST) Received: from z00133208 ([10.110.98.54]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7800FDIQLBG1@szxml06-in.huawei.com> for ipsec@ietf.org; Mon, 16 Aug 2010 18:31:59 +0800 (CST) Date: Mon, 16 Aug 2010 18:31:58 +0800 From: Dacheng Zhang In-reply-to: To: 'Yaron Sheffer' , 'IPsecme WG' Message-id: <001301cb3d2e$4195d700$02000008@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Thread-index: Acs4dZvLNNDExhPZTeuIUDyH4YwRrAEilLCAAAtvEkA= Subject: Re: [IPsec] Failure detection proposals, stage 2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 10:31:37 -0000 Hi,=20 I think both solutions are very interesting. But after carefully consideration, I prefer to support QCD.=20 Firstly, compared to SIR, the QCD solution is simpler. It can use fewer packets to achieve the objective, because a peer can verify the token directly after receiving an INVALID_SPI packet. Secondly, in SIR, a peer has to wait for a certain period to ensure that = it did not get a CHECK_SPI (NACK) packet from an attacker. This solution = seems relatively ineffective and low efficient. (According to the draft, the period should be a least a few m-seconds. However, I don=A1=AFt think it = is long enough. It is just my humble opinion. --Dacheng >=20 > Hi, >=20 > I had a look at both the documents and here are my thoughts. >=20 > I support QCD to be taken forward of the two. >=20 > Both these documents have good thoughts in addressing the=20 > issue, but also have gaps in terms of security. Both these=20 > designs are prone to security attacks and going by the=20 > proposed solutions, the QCD seems the better of the two. >=20 > Some effort into Liveness detection mechanism , the method of=20 > generating secured QCD token and managing the token in an=20 > optimized manner are some of the items that can be worked on=20 > from the QCD draft. I think, Fixing these items would lead=20 > to a more secured and acceptable solution and I will be more=20 > than happy to work with the team on these items. >=20 > Thanks and Regards, > A.Palanivelan >=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Yaron Sheffer > Sent: Tuesday, August 10, 2010 3:50 PM > To: IPsecme WG > Subject: [IPsec] Failure detection proposals, stage 2 >=20 > OK, Paul and I are finally convinced that we have sufficient=20 > WG interest >=20 > in solving this problem. Now, I'd like to ask the people who=20 > have responded (as well as others) to read the two drafts,=20 > and to tell us why >=20 > they prefer the one over the other. >=20 > Quoting myself: "If you speak up, we will expect you to=20 > contribute to the selection of the preferred document". >=20 > Please respond with comments to the drafts and/or a=20 > comparison within the next week, i.e. by August 17. >=20 > Thanks, > Yaron >=20 > > From: Yaron Sheffer > > To: IPsecme WG > > Date: 08/04/2010 04:48 PM > > Subject: [IPsec] Failure detection proposals Sent by:=20 > > ipsec-bounces@ietf.org > > > > > > > > In the Maastricht meeting there was just a tiny bit of=20 > interest in the=20 > > failure detection idea (reminder: the goal is to ensure=20 > that one peer=20 > > discovers that the other IKE peer has restarted, within a=20 > short time=20 > > duration, milliseconds instead of minutes). But we didn't=20 > see enough=20 > > interest to justify having this as a WG item. So, one last time: if > you > > think this is a worthwhile idea, regardless of the proposals on the=20 > > table, please say so publicly. If you speak up, we will=20 > expect you to=20 > > contribute to the selection of the preferred document. > > > > If this is of no interest, fine. But if it is an important=20 > problem to=20 > > solve and we don't take it on, we could end up with=20 > competing non-WG=20 > > proposals. Which would be far from ideal. > > > > Thanks, > > Yaron > > > > -----Original Message----- > > From: ipsec-bounces@ietf.org=20 > [mailto:ipsec-bounces@ietf.org] On Behalf=20 > > Of Paul Hoffman > > Sent: Wednesday, July 07, 2010 8:03 PM > > To: IPsecme WG > > Subject: [IPsec] NUDGE: Starting discussion of failure detection > proposals > > > > [[ This topic generated a fair amount of discussion in the=20 > past; are=20 > > folks still interested? ]] > > > > Greetings again. The WG has one item on our charter that we have > barely > > discussed, namely failure detection. The charter item says that the > work > > item is: > > > >> - A standards-track IKEv2 extension that allows an IKE peer to > quickly and > > securely detect that its opposite peer, while currently=20 > reachable, has > lost > > its IKEv2/IPsec state. Changes to how the peers recover from this > situation > > are beyond the scope of this work item, as is improving the=20 > detection > of an > > unreachable or dead peer. Ideas from draft-nir-ike-qcd-05 and > > draft-detienne-ikev2-recovery-03 can be used as starting points. > > > > I gave a brief presentation on failure detection at the last IETF=20 > > meeting in Anaheim. The slides are at=20 > > , and the=20 > > following is directly derived from them. > > > > The basic problem being covered by the new extension is: > > - Alice and Bob have SAs up and ESP traffic is flowing,=20 > but then Bob=20 > > crashes > > - Alice keeps sending ESP to Bob > > - When Bob finally comes back up, he replies to Alice's ESP with=20 > > INVALID_SPI notifications > > - Alice starts sending IKE liveness checks until she is "sure" that > the > > INVALID_SPI responses are not a DoS attack; this could be "several > minutes" > > - Then Alice rekeys > > > > Some other problem cases include: > > - Bob has two gateways in some failover architecture. One gateway > goes > > down, the other gateway detects this and wants to tell=20 > Alice to rekey > > - Bob has a bunch of gateways in some load-balancing or cluster=20 > > architecture. One gateway is taken down on purpose, and the system > wants > > to tell Alice to rekey > > - Protocol robustness: Bob's gateway loses the SA without=20 > going down > > > > Our primary goal is that, as soon as Bob starts sending INVALID_SPI=20 > > responses to Alice's ESP traffic, Bob and Alice should be able to=20 > > quickly determine that this is not an attack and therefore they > probably > > want to rekey right away. Note that if Bob and Alice are also using=20 > > session resumption, they can use that instead of rekeying;=20 > however, in=20 > > the discussion here, we always use "rekey" to mean "rekey or, if=20 > > appropriate, resume". The proposed extension does not include the > actual > > rekeying, just the context for them to do it now. > > > > The WG has seen two proposed solutions, QCD and SIR. The=20 > following are=20 > > brief summaries of the two proposals. > > > > In QCD (), Bob gives > Alice > > a secret token in the AUTH exchange, and then puts the token in his=20 > > INVALID_SPI response as a way to say "this SPI is gone". Bob must=20 > > remember his tokens across reboots, or derive tokens from a master > token > > that he memorizes across reboots, and Alice must remember the token > (or > > a hash of it) for each SA. > > > > In SIR > > (), > Alice > > sends a new Check_SPI query with a stateless cookie, essentially > asking > > "do you really not know about this > > SPI?"; Bob responds by saying "I'm sure I don't know that SPI". > Nothing > > is stored on either side, so a man-in-the-middle can attack this to=20 > > cause an unnecessary rekey just as they can normal IKE. > > > > The first task for the WG is to decide which of these two quite=20 > > different approaches to take. After we have done that, we can then > hone > > the chosen proposal. During earlier discussion of the=20 > proposals, the=20 > > following criteria were mentioned as ones that the WG=20 > should consider=20 > > when thinking about the approaches: > > > > - Support for different scenarios (load balancers, active clusters, > > failover) > > - Security from man-in-the-middle DoS attacks > > - Resources used > > - Intellectual property rights > > > > So: please start discussing the two proposals with respect to these=20 > > criteria or other criteria that are important to you. In a=20 > few weeks=20 > > (hopefully well before the Maastricht meeting), I make a call for=20 > > consensus and see where it leads us. > > > > --Paul Hoffman, Director > > --VPN Consortium > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Mon Aug 16 05:28:35 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959123A6358 for ; Mon, 16 Aug 2010 05:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.297 X-Spam-Level: X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0IHFjFwzg9t for ; Mon, 16 Aug 2010 05:28:34 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0243A680E for ; Mon, 16 Aug 2010 05:28:33 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o7GCT832026006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Aug 2010 15:29:08 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o7GCT8ar026872; Mon, 16 Aug 2010 15:29:08 +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: <19561.12052.39645.676482@fireball.kivinen.iki.fi> Date: Mon, 16 Aug 2010 15:29:08 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 26 min Cc: ipsec@ietf.org Subject: [IPsec] question about ESN and IANA registry X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 12:28:35 -0000 Scott C Moonen writes: > > The IANA registry currently lists the ESN transform as optional for ESP, AH > in IKEv2. From http://www.iana.org/assignments/ikev2-parameters: > > Registry: > Transform > Type Description Used In > Reference > -------- ------------------------------- --------------------------- > --------- > . . . > 5 Extended Sequence Numbers (ESN) (Optional in AH and ESP) > [RFC-ietf-ipsecme-ikev2bis-11.txt] > > However, both RFC 4306 and ikev2bis indicate that ESN is mandatory: > > Protocol Mandatory Types Optional Types > --------------------------------------------------- > IKE ENCR, PRF, INTEG*, D-H > ESP ENCR, ESN INTEG, D-H > AH INTEG, ESN D-H > > I believe the registry is in error and I'm hoping that posting here is an > effective way to suggest a fix. Thanks, There has been lots of different interpretations whether including ESN of none to the proposal or not (if that is the only one that is supported). Those were seen in the interop events just before RFC4306 was published, and if I remember correctly there was some late changes text changes to the RFC4306 because of this. If you check draft-ietf-ipsec-ikev2-17.txt that still contains text saying: Extended Sequence Numbers (ESN) 5 (Optional in AH and ESP) This was changed to Extended Sequence Numbers (ESN) 5 (AH and ESP) before the RFC was published: http://tools.ietf.org/rfcdiff?url2=rfc4306 There was poll on the ipsec list on 04 Mar 2005: http://www.ietf.org/mail-archive/web/ipsec/current/msg01367.html about this and the solution was to change the ESN transform to mandatory. This change was done while the document was still in RFC editor queue, so this means the IANA might have already taken the older version and created the registry based on that. So this is clearly a error, and I will send request to IANA to fix this. -- kivinen@iki.fi From iesg-secretary@ietf.org Mon Aug 16 11:01:34 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FD733A6A0D; Mon, 16 Aug 2010 11:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjJzmCB8tC8c; Mon, 16 Aug 2010 11:01:33 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A78383A68B2; Mon, 16 Aug 2010 11:01:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no Message-ID: <20100816180132.7199.26179.idtracker@localhost> Date: Mon, 16 Aug 2010 11:01:32 -0700 Cc: ipsecme mailing list , ipsecme chair , Internet Architecture Board , RFC Editor Subject: [IPsec] Document Action: 'IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap' to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 18:01:34 -0000 The IESG has approved the following document: - 'IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap' as an Informational RFC This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Sean Turner and Tim Polk. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-ipsecme-roadmap/ Technical Summary This is actually not a technical document: as the abstract says, "This document is a snapshot of IPsec- and IKE-related RFCs." It covers a myriad of RFCs that relate heavily or lightly to all versions of IPsec and IKE, including those that did not originate with the IPsec and IPsecME Working Groups. Working Group Summary The document has rough consensus of the IPsecME WG. Document Quality This document is exhaustive and should help any implementer who wants to understand the many different facets of IPsec to find the other RFCs that they need. Personnel Paul Hoffman is Document Shepherd. Sean Turner is the responsible Area Director. From paul.hoffman@vpnc.org Mon Aug 23 09:17:25 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 099703A6A11 for ; Mon, 23 Aug 2010 09:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.762 X-Spam-Level: X-Spam-Status: No, score=-99.762 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNM-CmyQGocj for ; Mon, 23 Aug 2010 09:17:14 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2F4E23A68E6 for ; Mon, 23 Aug 2010 09:17:10 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7NGHgnV067280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Aug 2010 09:17:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C6127C7.7070008@gmail.com> References: <4C59D035.50108@gmail.com> <4C6127C7.7070008@gmail.com> Date: Mon, 23 Aug 2010 09:17:41 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] Failure detection proposals, stage 2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 16:17:25 -0000 >From the responses to Yaron's request, there is a clear consensus in the WG to start with QCD as the WG's work item. We'll talk to the authors of the QCD draft about how they want to proceed with taking this into the WG. --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Wed Aug 25 13:43:43 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 718BA3A6B62 for ; Wed, 25 Aug 2010 13:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbZgsFy77H7F for ; Wed, 25 Aug 2010 13:43:41 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 6E6963A6B65 for ; Wed, 25 Aug 2010 13:43:27 -0700 (PDT) X-CheckPoint: {4C758DF1-F-1B221DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id o7PKhxn4021613 for ; Wed, 25 Aug 2010 23:43:59 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 25 Aug 2010 23:44:40 +0300 From: Yoav Nir To: IPsecme WG Date: Wed, 25 Aug 2010 23:43:56 +0300 Thread-Topic: [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text Thread-Index: ActEllYvXTKWkERPQnmzm9nlKwbJpw== Message-ID: References: <4C75752F.5020409@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Fwd: [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 20:43:43 -0000 Hi all This might be of interest to the group. Joe is suggesting here (and in the = next messages on the thread) to update RFC 4301. Begin forwarded message: > From: Joe Touch > Date: August 25, 2010 10:55:27 PM GMT+03:00 > To: Thomas Narten > Cc: "saag@ietf.org" > Subject: Re: [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text >=20 > Hi, Tom, >=20 > On 8/25/2010 6:20 AM, Thomas Narten wrote: >> To recap, I presented on the issue of updating the IPsec/IKEv2 text >> at the 6man meeting in Maastricht, as well as at the SAAG meeting. My >> sense of both of those discussions is that there is support for >> changing the general recommendation to a SHOULD. >>=20 >> I got some good feedback in SAAG about the wording (refer to the >> security architecture generally rather than IKEv2, etc.). >>=20 >> New proposed text below. >>=20 >> This text would go into draft-ietf-ipv6-node-requirements, which >> updates RFC 4294. >>=20 >> Comments? >=20 > First, this seems to override Sec 10 of RFC4301, so it would need to=20 > update RFC4301 as well. >=20 > Some other comments below. >=20 > Joe >=20 >> Thomas >>=20 >> 10. Security >>=20 >> This section describes the specification for security for IPv6 nodes. >>=20 >> Achieving security in practice is a complex undertaking. Operational >> procedures, protocols, key distribution mechanisms, certificate >> management approaches, etc. are all components that impact the level >> of security actually achieved in practice. More importantly, >> deficiencies or a poor fit in any one individual component can >> significantly reduce the overall effectiveness of a particular >> security approach. >>=20 >> IPsec provides channel security at the Internet layer, making it >> possible to provide secure communication for all (or a subset of) >> communication flows at the IP layer between pairs of internet nodes. >> IPsec provides sufficient flexibility and granularity that individual >> TCP connections can (selectively) be protected, etc. >=20 > IPsec can protect down to the socket pair (src addr/src port/dst=20 > addr/dst port) granularity, but there are two important issues. First,=20 > this is rarely done; it is more common to protect services (i.e., at=20 > least letting the src port of incoming SYNs float). Second, such=20 > granularity would reuse an SA for different TCP connections that reuse=20 > the port pair. >=20 > I.e., there is no way I am aware of to ensure that IPsec changes SA keys= =20 > for a socket pair for each TCP connection that reuses that socket.=20 > TCP-AO can achieve this, however. >=20 > So it is not individual TCP connections that are protected; it is=20 > individual socket pairs (at best), and more likely all connections=20 > between two specific endpoints for a given service. >=20 > [FWIW, this might be a good opportunity for the IPsec doc to crossref=20 > TCP-AO, and to have at least a short note as to when each is preferred,=20 > or to refer to that discussion in the TCP-AO document] >=20 >> Although IPsec can be used with manual keying in some cases, such >> usage has limited applicability and is not recommended. >>=20 >> A range of security technologies and approaches proliferate today >> (e.g., IPsec, TLS, SSH, etc.) >=20 > It might be useful to add TCP-AO here. >=20 >> No one approach has emerged as an >> ideal technology for all needs and environments. Moreover, IPsec is >> not viewed as the ideal security technology in all cases and is >> unlikely to displace the others. >=20 > It's important to note, however, that although any of these protects the= =20 > user data, only IPsec and TCP-AO protect TCP connections from disruption= =20 > attacks. >=20 >> Previously, IPv6 mandated implementation of IPsec and recommended the >> key management approach of IKE. This document updates that >> recommendation by making support of the IP Security Architecture [RFC >> 4301] a SHOULD for all IPv6 nodes. Note that the IPsec Architecture >> requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both >> manual and automatic key management. Currently the default automated >> key management protocol to implement is IKEv2. >>=20 >> This document recognizes that there exists a range of device types >> and environments where other approaches to security than IPsec can be >> justified. For example, special-purpose devices may support only a >> very limited number or type of applications and an application- >> specific security approach may be sufficient for limited management >> or configuration capabilities. Alternatively, some devices my run on >> extremely constrained hardware (e.g., sensors) where the full IP >> Security Architecture is not justified. >>=20 >> 10.1. Requirements >>=20 >> "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be >> supported by all IPv6 nodes. Note that the IPsec Architecture >> requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both >> manual and automatic key management. Currently the default automated >> key management protocol to implement is IKEv2. >>=20 >> 10.2. Transforms and Algorithms >>=20 >> The current set of mandatory-to-implement algorithms for the IP >> Security Architcture are defined in 'Cryptographic Algorithm >> Implementation Requirements For ESP and AH' [RFC4835]. IPv6 nodes >> implementing the IP Security Architecture MUST conform to the >> requirements in [RFC4835]. Preferred cryptographic algorithms often >> change more frequently than security protocols. Therefore >> implementations MUST allow for migration into new algorithms, as >> RFC4835 is replaced or updated in the future. >=20 > This might also be a good opportunity to revisit the issue of=20 > recommendations for tunnel and transport mode inclusion. During the=20 > revision of RFC4301, IMO the recommendations on transport mode were=20 > vague with respect to routers (RFC4301, end of section 4.1). >=20 > I feel it is important to indicate the following: >=20 > --- >=20 > Any device that acts like a host (i.e., sources packets with IP=20 > addresses assigned to their own interfaces) and implements IPsec MUST=20 > implement transport mode. All devices (hosts and gateways) that=20 > implement IPsec MUST implement tunnel mode. Because gateways always act=20 > as hosts for some protocols (as noted in RFC 1812), the conclusion is=20 > that all devices that implement IPsec MUST implement both tunnel and=20 > transport mode. >=20 > In summary, >=20 > a) A host implementation of IPsec MUST support both transport and > tunnel mode. This is true for native, BITS, and BITW > implementations for hosts. >=20 > b) A security gateway MUST support both transport and tunnel mode. > Transport mode should be used only when the security gateway > is acting as a host, e.g., for network management, or to > provide security between two intermediate systems along a path, > as to secure a tunnel whose encapsulation is not provided > by IPsec tunnel mode. >=20 > --- >=20 From paul.hoffman@vpnc.org Wed Aug 25 14:38:49 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E6203A6B46; Wed, 25 Aug 2010 14:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.049 X-Spam-Level: X-Spam-Status: No, score=-101.049 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h3f7i7yAYL7; Wed, 25 Aug 2010 14:38:33 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 10FAD3A6B36; Wed, 25 Aug 2010 14:37:15 -0700 (PDT) Received: from [75.101.18.87] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7PLZn8J043192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Aug 2010 14:35:51 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C75752F.5020409@isi.edu> References: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> <4C75752F.5020409@isi.edu> Date: Wed, 25 Aug 2010 14:35:47 -0700 To: Joe Touch , Thomas Narten From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG , saag@ietf.org Subject: Re: [IPsec] [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:38:50 -0000 X-List-Received-Date: Wed, 25 Aug 2010 21:38:50 -0000 First off, Thomas gave the wrong pointer. The draft under discussion is draft-ietf-6man-node-req-bis, not draft-ietf-ipv6-node-requirements; the latter became RFC 4294. At 12:55 PM -0700 8/25/10, Joe Touch wrote: >Hi, Tom, > >On 8/25/2010 6:20 AM, Thomas Narten wrote: >>To recap, I presented on the issue of updating the IPsec/IKEv2 text >>at the 6man meeting in Maastricht, as well as at the SAAG meeting. My >>sense of both of those discussions is that there is support for >>changing the general recommendation to a SHOULD. >> >>I got some good feedback in SAAG about the wording (refer to the >>security architecture generally rather than IKEv2, etc.). >> >>New proposed text below. >> >>This text would go into draft-ietf-ipv6-node-requirements, which >>updates RFC 4294. >> >>Comments? > >First, this seems to override Sec 10 of RFC4301, so it would need to update RFC4301 as well. I am quite hesitant to have an Informational RFC update a Proposed Standard RFC. Further, it does not "override" anything: it is suggestions for developers. > >Some other comments below. > >Joe > >>Thomas >> >>10. Security >> >> This section describes the specification for security for IPv6 nodes. >> >> Achieving security in practice is a complex undertaking. Operational >> procedures, protocols, key distribution mechanisms, certificate >> management approaches, etc. are all components that impact the level >> of security actually achieved in practice. More importantly, >> deficiencies or a poor fit in any one individual component can >> significantly reduce the overall effectiveness of a particular >> security approach. >> >> IPsec provides channel security at the Internet layer, making it >> possible to provide secure communication for all (or a subset of) >> communication flows at the IP layer between pairs of internet nodes. >> IPsec provides sufficient flexibility and granularity that individual >> TCP connections can (selectively) be protected, etc. > >IPsec can protect down to the socket pair (src addr/src port/dst addr/dst port) granularity, but there are two important issues. First, this is rarely done; it is more common to protect services (i.e., at least letting the src port of incoming SYNs float). Second, such granularity would reuse an SA for different TCP connections that reuse the port pair. > >I.e., there is no way I am aware of to ensure that IPsec changes SA keys for a socket pair for each TCP connection that reuses that socket. TCP-AO can achieve this, however. > >So it is not individual TCP connections that are protected; it is individual socket pairs (at best), and more likely all connections between two specific endpoints for a given service. > >[FWIW, this might be a good opportunity for the IPsec doc to crossref TCP-AO, and to have at least a short note as to when each is preferred, or to refer to that discussion in the TCP-AO document] I would prefer that this sentence in draft-ietf-6man-node-req-bis be removed and not to confuse IPsec documents with TCP-AO. > >> Although IPsec can be used with manual keying in some cases, such >> usage has limited applicability and is not recommended. >> >> A range of security technologies and approaches proliferate today >> (e.g., IPsec, TLS, SSH, etc.) > >It might be useful to add TCP-AO here. Please don't: it could easily confuse readers into thinking that it does more than authentication. > > > No one approach has emerged as an >> ideal technology for all needs and environments. Moreover, IPsec is >> not viewed as the ideal security technology in all cases and is >> unlikely to displace the others. > >It's important to note, however, that although any of these protects the user data, only IPsec and TCP-AO protect TCP connections from disruption attacks. ...somewhat protect... > >> Previously, IPv6 mandated implementation of IPsec and recommended the >> key management approach of IKE. This document updates that >> recommendation by making support of the IP Security Architecture [RFC >> 4301] a SHOULD for all IPv6 nodes. Note that the IPsec Architecture >> requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both >> manual and automatic key management. Currently the default automated >> key management protocol to implement is IKEv2. >> >> This document recognizes that there exists a range of device types >> and environments where other approaches to security than IPsec can be >> justified. For example, special-purpose devices may support only a >> very limited number or type of applications and an application- >> specific security approach may be sufficient for limited management >> or configuration capabilities. Alternatively, some devices my run on >> extremely constrained hardware (e.g., sensors) where the full IP >> Security Architecture is not justified. >> >>10.1. Requirements >> >> "Security Architecture for the Internet Protocol" [RFC4301] SHOULD be >> supported by all IPv6 nodes. Note that the IPsec Architecture >> requires (e.g., Sec. 4.5 of RFC 4301) the implementation of both >> manual and automatic key management. Currently the default automated >> key management protocol to implement is IKEv2. >> >>10.2. Transforms and Algorithms >> >> The current set of mandatory-to-implement algorithms for the IP >> Security Architcture are defined in 'Cryptographic Algorithm >> Implementation Requirements For ESP and AH' [RFC4835]. IPv6 nodes >> implementing the IP Security Architecture MUST conform to the >> requirements in [RFC4835]. Preferred cryptographic algorithms often >> change more frequently than security protocols. Therefore >> implementations MUST allow for migration into new algorithms, as >> RFC4835 is replaced or updated in the future. > >This might also be a good opportunity to revisit the issue of recommendations for tunnel and transport mode inclusion. During the revision of RFC4301, IMO the recommendations on transport mode were vague with respect to routers (RFC4301, end of section 4.1). > >I feel it is important to indicate the following: > >--- > >Any device that acts like a host (i.e., sources packets with IP addresses assigned to their own interfaces) and implements IPsec MUST implement transport mode. Gateways "source packets with IP addresses assigned to their own interfaces". I would strongly object efforts to reverse the IPsec WG's decision to reduce the demands for transport mode. >All devices (hosts and gateways) that implement IPsec MUST implement tunnel mode. Because gateways always act as hosts for some protocols (as noted in RFC 1812), the conclusion is that all devices that implement IPsec MUST implement both tunnel and transport mode. > > In summary, > > a) A host implementation of IPsec MUST support both transport and > tunnel mode. This is true for native, BITS, and BITW > implementations for hosts. > > b) A security gateway MUST support both transport and tunnel mode. > Transport mode should be used only when the security gateway > is acting as a host, e.g., for network management, or to > provide security between two intermediate systems along a path, > as to secure a tunnel whose encapsulation is not provided > by IPsec tunnel mode. Joe: what has changed since the IPsec WG decided the other way years ago that would require this change? --Paul Hoffman, Director --VPN Consortium From touch@isi.edu Wed Aug 25 15:11:58 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED1B3A6B61; Wed, 25 Aug 2010 15:11:55 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeZSECNA8ecz; Wed, 25 Aug 2010 15:11:30 -0700 (PDT) Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 7A6593A695E; Wed, 25 Aug 2010 15:11:22 -0700 (PDT) Received: from [172.35.1.127] (pc3.shinagawaphvod2-unet.ocn.ne.jp [220.110.141.59]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o7PMBEcZ011586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Aug 2010 15:11:25 -0700 (PDT) Message-ID: <4C7594ED.5000403@isi.edu> Date: Wed, 25 Aug 2010 15:10:53 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Paul Hoffman References: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> <4C75752F.5020409@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-ID: o7PMBEcZ011586 X-ISI-4-69-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Thomas Narten , IPsecme WG , saag@ietf.org Subject: Re: [IPsec] [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 22:11:59 -0000 On 8/25/2010 2:35 PM, Paul Hoffman wrote: > First off, Thomas gave the wrong pointer. The draft under discussion is draft-ietf-6man-node-req-bis, not draft-ietf-ipv6-node-requirements; the latter became RFC 4294. > > At 12:55 PM -0700 8/25/10, Joe Touch wrote: >> Hi, Tom, >> >> On 8/25/2010 6:20 AM, Thomas Narten wrote: >>> To recap, I presented on the issue of updating the IPsec/IKEv2 text >>> at the 6man meeting in Maastricht, as well as at the SAAG meeting. My >>> sense of both of those discussions is that there is support for >>> changing the general recommendation to a SHOULD. >>> >>> I got some good feedback in SAAG about the wording (refer to the >>> security architecture generally rather than IKEv2, etc.). >>> >>> New proposed text below. >>> >>> This text would go into draft-ietf-ipv6-node-requirements, which >>> updates RFC 4294. >>> >>> Comments? >> >> First, this seems to override Sec 10 of RFC4301, so it would need to update RFC4301 as well. > > I am quite hesitant to have an Informational RFC update a Proposed Standard RFC. Further, it does not "override" anything: it is suggestions for developers. An suggestion for developers to ignore a standard (esp. using RFC2119 language) necessarily updates that standard. > >> >> Some other comments below. >> >> Joe >> >>> Thomas >>> >>> 10. Security >>> >>> This section describes the specification for security for IPv6 nodes. >>> >>> Achieving security in practice is a complex undertaking. Operational >>> procedures, protocols, key distribution mechanisms, certificate >>> management approaches, etc. are all components that impact the level >>> of security actually achieved in practice. More importantly, >>> deficiencies or a poor fit in any one individual component can >>> significantly reduce the overall effectiveness of a particular >>> security approach. >>> >>> IPsec provides channel security at the Internet layer, making it >>> possible to provide secure communication for all (or a subset of) >>> communication flows at the IP layer between pairs of internet nodes. >>> IPsec provides sufficient flexibility and granularity that individual >>> TCP connections can (selectively) be protected, etc. >> >> IPsec can protect down to the socket pair (src addr/src port/dst addr/dst port) granularity, but there are two important issues. First, this is rarely done; it is more common to protect services (i.e., at least letting the src port of incoming SYNs float). Second, such granularity would reuse an SA for different TCP connections that reuse the port pair. >> >> I.e., there is no way I am aware of to ensure that IPsec changes SA keys for a socket pair for each TCP connection that reuses that socket. TCP-AO can achieve this, however. >> >> So it is not individual TCP connections that are protected; it is individual socket pairs (at best), and more likely all connections between two specific endpoints for a given service. >> >> [FWIW, this might be a good opportunity for the IPsec doc to crossref TCP-AO, and to have at least a short note as to when each is preferred, or to refer to that discussion in the TCP-AO document] > > I would prefer that this sentence in draft-ietf-6man-node-req-bis be > removed and not to confuse IPsec documents with TCP-AO. If you mean removing the sentence "IPsec provides sufficient flexibility and granularity that individual TCP connections can (selectively) be protected, etc.", that would be fine, however it requires removing the text below too. >>> Although IPsec can be used with manual keying in some cases, such >>> usage has limited applicability and is not recommended. >>> >>> A range of security technologies and approaches proliferate today >>> (e.g., IPsec, TLS, SSH, etc.) >> >> It might be useful to add TCP-AO here. > > Please don't: it could easily confuse readers into thinking that it does more than authentication. In that case, TLS and SSH are inappropriate, as including them might confuse readers into thinking they protect the TCP connection (a common mistake already). If this is similarly removed, then that would make sense. ... >> This might also be a good opportunity to revisit the issue of >> recommendations for tunnel and transport mode inclusion. During the >> revision of RFC4301, IMO the recommendations on transport mode were >> vague with respect to routers (RFC4301, end of section 4.1). ... >> In summary, >> >> a) A host implementation of IPsec MUST support both transport and >> tunnel mode. This is true for native, BITS, and BITW >> implementations for hosts. >> >> b) A security gateway MUST support both transport and tunnel mode. >> Transport mode should be used only when the security gateway >> is acting as a host, e.g., for network management, or to >> provide security between two intermediate systems along a path, >> as to secure a tunnel whose encapsulation is not provided >> by IPsec tunnel mode. > > Joe: what has changed since the IPsec WG decided the other way years > ago that would require this change? Hopefully the appreciatoin of the security community that routers *always* act like hosts for at least some of their traffic ;-) Joe From narten@us.ibm.com Thu Aug 26 06:03:52 2010 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 707793A67E2; Thu, 26 Aug 2010 06:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.316 X-Spam-Level: X-Spam-Status: No, score=-106.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dhYrnKp1juo; Thu, 26 Aug 2010 06:03:50 -0700 (PDT) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 6E6483A6873; Thu, 26 Aug 2010 06:03:50 -0700 (PDT) Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e2.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o7QCo3bZ017144; Thu, 26 Aug 2010 08:50:03 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o7QD4KmF1716294; Thu, 26 Aug 2010 09:04:20 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o7QD4JJr029701; Thu, 26 Aug 2010 10:04:20 -0300 Received: from cichlid.raleigh.ibm.com (sig-9-65-245-223.mts.ibm.com [9.65.245.223]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o7QD4IkB029567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Aug 2010 10:04:19 -0300 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id o7QD4Fs4007247; Thu, 26 Aug 2010 09:04:15 -0400 Message-Id: <201008261304.o7QD4Fs4007247@cichlid.raleigh.ibm.com> To: Paul Hoffman In-reply-to: References: <201008251320.o7PDKvI3030865@cichlid.raleigh.ibm.com> <4C75752F.5020409@isi.edu> Comments: In-reply-to Paul Hoffman message dated "Wed, 25 Aug 2010 14:35:47 -0700." Date: Thu, 26 Aug 2010 09:04:15 -0400 From: Thomas Narten Cc: IPsecme WG , saag@ietf.org, Joe Touch Subject: Re: [IPsec] [saag] IPv6 Node Requirements: Updated IPsec/IKEv2 text X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 13:03:52 -0000 Paul Hoffman writes: > First off, Thomas gave the wrong pointer. The draft under discussion > is draft-ietf-6man-node-req-bis, not > draft-ietf-ipv6-node-requirements; the latter became RFC 4294. Thanks for clarifying... > At 12:55 PM -0700 8/25/10, Joe Touch wrote: > >Hi, Tom, > > > >On 8/25/2010 6:20 AM, Thomas Narten wrote: > >>To recap, I presented on the issue of updating the IPsec/IKEv2 text > >>at the 6man meeting in Maastricht, as well as at the SAAG meeting. My > >>sense of both of those discussions is that there is support for > >>changing the general recommendation to a SHOULD. > >> > >>I got some good feedback in SAAG about the wording (refer to the > >>security architecture generally rather than IKEv2, etc.). > >> > >>New proposed text below. > >> > >>This text would go into draft-ietf-ipv6-node-requirements, which > >>updates RFC 4294. > >> > >>Comments? > > > >First, this seems to override Sec 10 of RFC4301, so it would need > >to update RFC4301 as well. Oddly enough, I did not receive Joe's message, so I'll respond to a followup. Section 10 of RFC 4301 says: > 10. Conformance Requirements > > All IPv4 IPsec implementations MUST comply with all requirements of > this document. All IPv6 implementations MUST comply with all > requirements of this document. Yes, this document is essentially updating that statement. Note, however, that the RFC 4294 already does that, because it says IKEv2 is a SHOULD, which contradicts this statement. Also, I think we are recognizing that the above wording is too strong and needs to be updated. Finally, the node requirements document is essentially an applicability statement. Whether it will be Informational or BCP is a bit of a TBD, but in any case there are plenty of applicability statements that are informational. On Applicability Statements, RFC 2026 says: > An AS identifies the relevant TSs and the specific way in which they > are to be combined, and may also specify particular values or ranges > of TS parameters or subfunctions of a TS protocol that must be > implemented. An AS also specifies the circumstances in which the use > of a particular TS is required, recommended, or elective (see section > 3.3). My conclusion is that an AS can make take individual RFCs and say they are required (or not), etc. And also add (or revoke) some requirements that arguably update the spec. But (IMO) this should be done only at a high level (i.e., requiring certain features or modes or profiles) rather than making actual technical changes to a protocol. So I do not believe there is any issue with having this document override Section 10 of 4301. > >IPsec can protect down to the socket pair (src addr/src port/dst > >addr/dst port) granularity, but there are two important > >issues. First, this is rarely done; it is more common to protect > >services (i.e., at least letting the src port of incoming SYNs > >float). Second, such granularity would reuse an SA for different > >TCP connections that reuse the port pair. The point of my text was just to point out that there are filters that can be applied that determine what (and how) sessions are covered by IPsec. Without getting into a lot of detail. And I certainly don't want to get into differences between what the specs allow and what the common usages are. If someone has better text to propose... > >I.e., there is no way I am aware of to ensure that IPsec changes SA > >keys for a socket pair for each TCP connection that reuses that > >socket. TCP-AO can achieve this, however. > > > >So it is not individual TCP connections that are protected; it is > >individual socket pairs (at best), and more likely all connections > >between two specific endpoints for a given service. > > > >[FWIW, this might be a good opportunity for the IPsec doc to > >crossref TCP-AO, and to have at least a short note as to when each > >is preferred, or to refer to that discussion in the TCP-AO > >document] > I would prefer that this sentence in draft-ietf-6man-node-req-bis be > removed and not to confuse IPsec documents with TCP-AO. Which specific sentence? I don't see how anything in the node-req-bis document can be confused with TCP-A0. > > > >> Although IPsec can be used with manual keying in some cases, such > >> usage has limited applicability and is not recommended. > >> > >> A range of security technologies and approaches proliferate today > >> (e.g., IPsec, TLS, SSH, etc.) > > > >It might be useful to add TCP-AO here. > Please don't: it could easily confuse readers into thinking that it > does more than authentication. I don't believe TCP-AO is relevant to the IPv6 Node Requirements document. > > > > > No one approach has emerged as an > >> ideal technology for all needs and environments. Moreover, IPsec is > >> not viewed as the ideal security technology in all cases and is > >> unlikely to displace the others. > > > >It's important to note, however, that although any of these > >protects the user data, only IPsec and TCP-AO protect TCP > >connections from disruption attacks. > ...somewhat protect... This is presumably covered in the IPSec/TCP-A0 documents, and doesn't need to go into the nod-requirements doc.. > >This might also be a good opportunity to revisit the issue of > >> recommendations for tunnel and transport mode > >> inclusion. During the revision of RFC4301, IMO the > >> recommendations on transport mode were vague with respect to > >> routers (RFC4301, end of section 4.1). > > > >I feel it is important to indicate the following: > > > >--- > > > >Any device that acts like a host (i.e., sources packets with IP > >> addresses assigned to their own interfaces) and implements > >> IPsec MUST implement transport mode. IMO, this is for the IPsecME WG to figure out, not the IPv6 Node Requirements doc. One of the the things node requrirements will now do is just point to the "IP Security Architecture" document and defer to it for all the details. Thomas