From kivinen@iki.fi Thu Apr 1 05:24:23 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 3DCD63A75BC for ; Thu, 1 Apr 2010 05:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 OZ54gC3P70-X for ; Thu, 1 Apr 2010 05:24:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 7EE783A6C71 for ; Thu, 1 Apr 2010 05:11:14 -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 o31CBfTl020268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 15:11:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o31CBd09017102; Thu, 1 Apr 2010 15:11:39 +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: <19380.36219.405774.979743@fireball.kivinen.iki.fi> Date: Thu, 1 Apr 2010 15:11:39 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: IPsecme WG Subject: [IPsec] ikev2bis issue #181: Section 2.4 unclear on Child SA failing 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, 01 Apr 2010 12:24:23 -0000 Paul Hoffman writes: > Section 2.4 says "If Child SAs can fail independently from one > another without the associated IKE SA being able to send a delete > message, then they MUST be negotiated by separate IKE SAs". It is > not clear what this means. Does it apply to implementations? Yes. > If so, how can an implementation know whether or not the first > clause is true? The implementor should know that. I.e. if the IPsec SAs are divided to multiple crypto chips, and those chips can fail independently causing all IPsec SAs on that chip to disappear but leaving IPsec SAs on other chips intact, then those groups of IPsec SAs cannot be negotiated with same IKE SA. > I propose removing the sentence, or greatly clarifying it. For me the current text is very clear, and I do not see how we can clarify greatly. This issue usually only affects implementations where there are multiple subsystems which can fail independently from each other. If the only failure model is that the whole device crashed/rebooted etc then this text does not apply, as all IPsec SAs (and IKE SAs) disappear at the same time. -- kivinen@iki.fi From kivinen@iki.fi Thu Apr 1 05:27: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 6209F3A7824 for ; Thu, 1 Apr 2010 05:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.725 X-Spam-Level: X-Spam-Status: No, score=-0.725 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] 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 JPWPvkqLXw6U for ; Thu, 1 Apr 2010 05:27:15 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id D8B3C3A6BD8 for ; Thu, 1 Apr 2010 05:15:50 -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 o31CG0dJ021159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 15:16:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o31CG07E000209; Thu, 1 Apr 2010 15:16:00 +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: <19380.36480.489212.268603@fireball.kivinen.iki.fi> Date: Thu, 1 Apr 2010 15:16:00 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: IPsecme WG Subject: [IPsec] ikev2bis issue #182: Marking CP() as optional in early sections 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, 01 Apr 2010 12:27:16 -0000 Paul Hoffman writes: > Sean Turner asks: Sec 1.2/2.19: Shouldn't "[CP()]" be in message 3 > and 4 in Section 1.2? I do not think so. The 1.2 section covers basic exchange. The special cases like Cookies (2.6), EAP (2.16), Configuration payloads (2.19), and NAT-T (2.23) have their own sections, and does not need to be covered by the basic exchange. -- kivinen@iki.fi From kivinen@iki.fi Thu Apr 1 05:28:40 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 C91133A6FDF for ; Thu, 1 Apr 2010 05:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.283 X-Spam-Level: X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 n2pqZm3SkwDG for ; Thu, 1 Apr 2010 05:28:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 163AD3A6F05 for ; Thu, 1 Apr 2010 05:18:12 -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 o31CIdu1015378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 15:18:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o31CIcld013560; Thu, 1 Apr 2010 15:18:38 +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: <19380.36638.347452.173025@fireball.kivinen.iki.fi> Date: Thu, 1 Apr 2010 15:18:38 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: IPsecme WG Subject: [IPsec] ikev2bis issue #183: Replace "X.509" with "PKIX" throughout? 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, 01 Apr 2010 12:28:40 -0000 Paul Hoffman writes: > We use "X.509" when we probably mean "PKIX". That is, we only care > about the PKIX profile of X.509, not just the base X.509 spec. > However, X.509 appears in some of the protocol element names. Can we > change it throughout to PKIX, or are we stuck with the old name? Changing the X.509 to PKIX in the protocol elements does not cause any changes to the protocol, only to the RFC and IANA registry. If we want to do this change it is possible. I do not have opinion whether we should do this change or not, I think people reading RFCs, will automatically substitute X.509 with PKIX anyways... -- kivinen@iki.fi From kivinen@iki.fi Thu Apr 1 05:47: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 4BB743A6C79 for ; Thu, 1 Apr 2010 05:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] 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 NsFbqv0z8Eip for ; Thu, 1 Apr 2010 05:47:09 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 0B1293A7010 for ; Thu, 1 Apr 2010 05:32:51 -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 o31CXM77015780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 15:33:22 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o31CXL17008686; Thu, 1 Apr 2010 15:33:21 +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: <19380.37521.240008.160281@fireball.kivinen.iki.fi> Date: Thu, 1 Apr 2010 15:33:21 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 14 min Cc: IPsecme WG Subject: [IPsec] ikev2bis issue #184: Interaction of rekeying of the IKE_SA and windows 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, 01 Apr 2010 12:47:10 -0000 Paul Hoffman writes: > s2.3: Should there be some discussion of the interaction of rekeying > of the IKE_SA and windows? We already have text about that in the section 2.8 and section 2.25 Exchange Collisions. > Presumably a rekey message should not be actioned until all previous > messages have been responded to. Depends about the message. I.e. if peer receives request to create or rekey Child SAs when it is rekeying IKE SA it should reply with TEMPORARY_FAILURE. If it receives requiest to delete child SA, it can go on normally. Note, that rekeying IKE SA does not mean that the old IKE SA is deleted immediately, it can still (and usually will stay) there for a moment, before it is deleted, and will be deleted as separate exchange. > Likewise receiving a Message ID with a sequence number bigger than > that in the rekey message should be very suspect! You mean getting first rekey request and then some other request on the same IKE SA? Yes, that is something that should not happen, but is not explicitly forbidden. It cannot really create or rekey IPsec SAs, as it does not know to which IKE SA those IPsec SAs belong to. Rekeying moves those IPsec SAs from old IKE SA to new IKE SA, and depending when other end processes the rekey message, this move might already happened or it might be still in progress. Deleting IPsec SAs is possible, but not advisable. Other messages like DPD should be processed as normally, and there is no problem there. > Should the INVALID_MESSAGE_ID notification be sent > in this case (and before or after the rekey?) No. The message ID is not invalid, as it is not outside the window, thus this error message cannot be sent. The responder can fail those request with various error messages, like TEMPORARY_FAILURE, CHILD_SA_NOT_FOUND, or NO_PROPOSAL_CHOSEN depending on the request and how the other end processes messages. > There might be some knock on into s2.8 where rekeying is discussed. > And maybe into s2.25? This is mostly covered by 2.25, altough I do not think we explictly say that initiator cannot send any new exchanges after it started IKE SA rekey. It is just assumed that it does not do that... The 2.25 mostly covers cases where the other end starts exchanges after one end has started IKE SA rekey, as this is something that the end starting IKE SA rekey cannot control. -- kivinen@iki.fi From kivinen@iki.fi Thu Apr 1 05:52: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 EBAA63A6BF7 for ; Thu, 1 Apr 2010 05:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.19 X-Spam-Level: X-Spam-Status: No, score=-1.19 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 AVbffEThrbPT for ; Thu, 1 Apr 2010 05:52:22 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 12F213A6BC4 for ; Thu, 1 Apr 2010 05:38:40 -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 o31CdBit016537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 15:39:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o31Cd9Ga027551; Thu, 1 Apr 2010 15:39:09 +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: <19380.37869.895517.613425@fireball.kivinen.iki.fi> Date: Thu, 1 Apr 2010 15:39:09 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Cc: IPsecme WG Subject: [IPsec] ikev2bis issue #186: Generating and accepting which types? 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, 01 Apr 2010 12:52:23 -0000 Paul Hoffman writes: > s3.5, para after ID Field types table: 'Implementations SHOULD be > capable of generating and accepting all of these types.' Does 'all' > here mean the four types in the previous sentence or 'all' the types > in the full table? Isn't this the same as issue #156 which was left as is. -- kivinen@iki.fi From kivinen@iki.fi Thu Apr 1 05:54: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 6A42F3A6D50 for ; Thu, 1 Apr 2010 05:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 Tes+pBUynC70 for ; Thu, 1 Apr 2010 05:54:24 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 52B5E3A6B4B for ; Thu, 1 Apr 2010 05:43:54 -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 o31CiMBn004080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 15:44:22 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o31CiLpg015496; Thu, 1 Apr 2010 15:44:21 +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: <19380.38181.281545.884988@fireball.kivinen.iki.fi> Date: Thu, 1 Apr 2010 15:44:21 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Cc: IPsecme WG Subject: [IPsec] ikev2bis issue #185: What do to if you don't ignore INITIAL_CONTACT 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, 01 Apr 2010 12:54:25 -0000 Paul Hoffman writes: > s2.4, para 2, says "The INITIAL_CONTACT notification, if sent, MUST > be in the first IKE_AUTH request or response, not as a separate > exchange afterwards; receiving parties MAY ignore it in other > messages." > > What should receiving parties do if they *do* receive it and *don't* > ignore it? Since it 'MUST be sent in the first IKE_AUTH' receiving > at any other time is a protocol error and should cause some response > (like dropping the IKE_SA perhaps). They either need to process is it or ignore it. The reason why we say it MUST be sent on first IKE_AUTH request or response, but MAY be ignored in other messages is because the original RFC4306 didn't have any restrictions where the INITIAL_CONTACT notification can be sent, thus to maintain backward compatiblity we still do allow it to be sent on other messages too, but implementations MAY ignore it there (the other option is to act based on it). Failing the IKE SA because the INITIAL_CONTACT notification was sent with other message would be incorrect, as we do not say INITIAL_CONTACT MUST NOT be sent anywhere else. I.e. even when we say it MUST be somewhere, that does not directly mean it would be protocol error to include it in some where else, especially when we indicate that it can be ignored on other messages. -- kivinen@iki.fi From wierbows@us.ibm.com Thu Apr 1 06:28:28 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 968113A6959; Thu, 1 Apr 2010 06:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 G4bbrH8ZxlEK; Thu, 1 Apr 2010 06:28:27 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 789343A688F; Thu, 1 Apr 2010 06:28:16 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o31DDxm3009809; Thu, 1 Apr 2010 09:13:59 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o31DSf1k151264; Thu, 1 Apr 2010 09:28:41 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o31DSfS1032132; Thu, 1 Apr 2010 10:28:41 -0300 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o31DSfha032113; Thu, 1 Apr 2010 10:28:41 -0300 In-Reply-To: <19380.36219.405774.979743@fireball.kivinen.iki.fi> References: <19380.36219.405774.979743@fireball.kivinen.iki.fi> X-KeepSent: AA07B3B6:DC1182C8-852576F8:00482D57; type=4; name=$KeepSent To: Tero Kivinen X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Thu, 1 Apr 2010 09:28:40 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 04/01/2010 09:28:40 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: IPsecme WG , ipsec-bounces@ietf.org Subject: Re: [IPsec] ikev2bis issue #181: Section 2.4 unclear on Child SA failing 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, 01 Apr 2010 13:28:28 -0000 >> I propose removing the sentence, or greatly clarifying it. > > For me the current text is very clear, and I do not see how we can > clarify greatly. This issue usually only affects implementations where > there are multiple subsystems which can fail independently from each > other. If the only failure model is that the whole device > crashed/rebooted etc then this text does not apply, as all IPsec SAs > (and IKE SAs) disappear at the same time. I disagree with the Tero's comment statement that the text is very clear, I've never understood exactly what the statement meant until I read the example that Tero provided. Based on that I would at least recommend changing the text as follows: If sets of Child SAs can fail independently from one another without the associated IKE SA being able to send a delete message, then each set of Child SAs MUST be negotiated by separate IKE SAs. It might even be approbate to add Tero's example: For example if sets of IPsec SAs are associated with different crypto chips, and each chip can fail independently causing all IPsec SAs associated with the chip to disappear then each set of IPsec SAs should be negotiated with a different IKE SA. Dave Wierbowski From wwwrun@core3.amsl.com Mon Apr 5 09:01:07 2010 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7AA5B28C169; Mon, 5 Apr 2010 09:01:07 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100405160107.7AA5B28C169@core3.amsl.com> Date: Mon, 5 Apr 2010 09:01:07 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] Last Call: draft-ietf-ipsecme-aes-ctr-ikev2 (Using Advanced Encryption Standard (AES) Counter Mode with IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 16:01:07 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-04-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18955&rfc_flag=0 From latten@austin.ibm.com Tue Apr 6 09:48:12 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 304BB3A6951 for ; Tue, 6 Apr 2010 09:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 5Rjxkvw+Fd06 for ; Tue, 6 Apr 2010 09:48:11 -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 05F823A6868 for ; Tue, 6 Apr 2010 09:48:10 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o36GkNK3021098 for ; Tue, 6 Apr 2010 10:46:23 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o36Glqe2097394 for ; Tue, 6 Apr 2010 10:47:53 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o36GlqAB002762 for ; Tue, 6 Apr 2010 10:47:52 -0600 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av01.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o36Glp2x002752; Tue, 6 Apr 2010 10:47:51 -0600 Received: from [9.41.41.43] (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id o36GlpHn043600; Tue, 6 Apr 2010 11:47:51 -0500 From: Joy Latten To: "Scott Fluhrer (sfluhrer)" In-Reply-To: References: <1269638701.2838.303.camel@faith.austin.ibm.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 06 Apr 2010 11:26:37 -0500 Message-Id: <1270571197.2838.504.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 8bit Cc: ipsec@ietf.org, avagarwa@redhat.com Subject: Re: [IPsec] Question about RFC 5114 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: latten@austin.ibm.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 16:48:12 -0000 On Fri, 2010-03-26 at 19:48 -0700, Scott Fluhrer (sfluhrer) wrote: > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > > Of Joy Latten > > Sent: Friday, March 26, 2010 5:25 PM > > To: mlepinski@bbn.com; kent@bbn.com > > Cc: ipsec@ietf.org; avagarwa@redhat.com > > Subject: [IPsec] Question about RFC 5114 > > > > Hi, > > > > I am looking to implement modp groups 22, 23, and 24 into IKE but have > > a > > question. > > > > RFC 5114 gives the prime, p, the generator, g and a subgroup, q, with a > > specific size... > > > > Because prior rfcs for modp groups did not specify a "q", I was not > > sure > > if this was a new constant or just stating a size requirement? > > q is the order of the generator. For the previous (traditional) MODP groups (1,2,5,14-18), we have q=(p-1)/2 > > > So I took a look at NIST 800-56A. In particular, > > > > 5.6.1 Private/Public Key Pair Generation > > > > 5.6.1.1 FFC Key Pair Generation > > For the FFC schemes, each static and ephemeral private key and public > > key shall be generated using an Approved method and the selected valid > > domain parameters (p, q, g{, SEED,pgenCounter}) (see Appendix B of FIPS > > 186-3). > > ... > > > > I then took a look at FIPS 186-3, Appendix B, which documents 2 methods > > for finite field cryptography (FFC) key pair generation. > > For example, one method is "Key Pair Generation Using Extra Random > > Bits". It actually states that "q" is an input and it is used to do an > > additional computation to compute "x". > > > > I am somewhat confused, are the modp groups 22, 23 & 24 suppose to use > > one of these new methods and that is why "q" is given in rfc 5114? > > Or am I to ignore this and just continue with existing way > > where "q" is not used and there aren't any additional computations > > to compute x. > > Short answer: it doesn't really matter; the old way is safe (for DH). > > Longer answer: FIPS 186-3 was written about generating values for DSA, not DH. Now, for DSA, there is a known weakness if the exponents you use are biased; these algorithms used in FIPS 186-3 were designed to make sure that the exponents are unbiased (or close enough not to matter). DH doesn't have similar issues, and so these steps aren't required (although they wouldn't hurt either). > > Now, you don’t need to use the same exponent size that you would use for the same size traditional groups; for example, RFC3526 suggests an exponent of between 220-320 bits for group 14; for group 24, there's no point in an exponent greater than 256 bits. This is because the exponent is essentially taken "mod q" by the algorithm, and so making it larger than q gives you more work without giving any benefit. Note that when FIPS 186-3 talks about using "extra random bits", they reduce the larger value so that it is > > On the other hand, NIST SP 800-56A also asks you to validate the peer public value (section 5.6.2.4), and this also uses q as an input. Here's why that really does matter for groups 22-24 (and not so much for groups 1,2,5,14-18): > > - If you reuse DH exponents, and you don't validate the peer's public value, then there is a way for an attacker to determine the value of your exponent modulo r, where r is a small factor of (p-1)/q. > - This attack involves sending illegal peer public values as a part of the IKE exchange, and seeing what keying material the unit comes up with. Because these values are illegal, validating the values foils the attack. > - This takes O(r) time on the attacker's part, which is why r can't be too large. > > For the traditional groups, (p-1)/q == 2, and so r=2 is the only one the attacker can use (hence the attacker would be able to determine the lsbit of your exponent via this attack, but nothing else). It turns out that there's a short cut to test on the peer public value in this case (compute the Legendre symbol), but even if you don't, the attacker gets minimal information. > > For these new groups, (p-1)/q is quite large, and in all three cases, has a number of small factors (now, NIST could have defined groups where (p-1)/q has 2 as the only small factor; they declined to do so). For example, for group 23 (which is the worse of the three), (p-1)/q == 2 * 3 * 3 * 5 * 43 * 73 * 157 * 387493 * 605921 * 5213881177 * 3528910760717 * 83501807020473429349 * C489 (where C489 is a 489 digit composite number with no small factors). The attacker could use this (again, if you don't validate the peer value) to effective cut your exponent size by about 137 bits with using only O(2**42) time); if you used 224 bit exponents, then the attacker would cut the work used to find the rest of the exponent to about O(2**44) time. Obviously, this is not acceptable. > Thanks so much for the detail. It has helped greatly. I did take a look at NIST SP 800-56A section 5.6.2.4 for validating the public value. I am in learning mode, so I found the 2nd step confusing... 1. Verify that 2 <= y <= p - 2 2. Verify that y^q = 1 (mod p) Are the parenthesis around "mod p" correct? This is how it is in the NIST doc. Thanks!! regards, Joy From rbarnes@bbn.com Tue Apr 6 09:54:28 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 AD9493A6964 for ; Tue, 6 Apr 2010 09:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 Mkd8ENWBwJOG for ; Tue, 6 Apr 2010 09:54:28 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id ED8ED3A6958 for ; Tue, 6 Apr 2010 09:54:27 -0700 (PDT) Received: from [192.1.255.171] (port=51270 helo=col-dhcp-192-1-255-171.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NzC2j-000Nbx-3f; Tue, 06 Apr 2010 12:54:25 -0400 Message-Id: <50C9BA8B-3C10-4C7F-93B7-B95E0ECA2CEB@bbn.com> From: Richard Barnes To: latten@austin.ibm.com In-Reply-To: <1270571197.2838.504.camel@faith.austin.ibm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Apr 2010 12:54:23 -0400 References: <1269638701.2838.303.camel@faith.austin.ibm.com> <1270571197.2838.504.camel@faith.austin.ibm.com> X-Mailer: Apple Mail (2.936) Cc: ipsec@ietf.org, avagarwa@redhat.com, "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Question about RFC 5114 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, 06 Apr 2010 16:54:28 -0000 > Thanks so much for the detail. It has helped greatly. > I did take a look at NIST SP 800-56A section 5.6.2.4 for validating > the > public value. I am in learning mode, so I found the 2nd step > confusing... > 1. Verify that 2 <= y <= p - 2 > 2. Verify that y^q = 1 (mod p) > > Are the parenthesis around "mod p" correct? This is how it is in the > NIST doc. Yes, the parens are correct. That's just a more traditional notation for modular equivalence: A = B (mod p) is the same as saying (in C notation) A % p == B % p So in your case you would want to check: y^q % p == 1 Hope this help, --Richard From latten@austin.ibm.com Tue Apr 6 14:40: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 1C06D3A69AA for ; Tue, 6 Apr 2010 14:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=3.300, 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 CW8TZ0ZnqXG5 for ; Tue, 6 Apr 2010 14:40:57 -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 6814C3A699A for ; Tue, 6 Apr 2010 14:40:57 -0700 (PDT) Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o36LTfMg015027 for ; Tue, 6 Apr 2010 17:29:41 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o36LelRS1962082 for ; Tue, 6 Apr 2010 17:40:47 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o36LelbV019336 for ; Tue, 6 Apr 2010 17:40:47 -0400 Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d01av04.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o36LekV1019308; Tue, 6 Apr 2010 17:40:46 -0400 Received: from [9.41.41.43] (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id o36Lekwg044004; Tue, 6 Apr 2010 16:40:46 -0500 From: Joy Latten To: Richard Barnes In-Reply-To: <50C9BA8B-3C10-4C7F-93B7-B95E0ECA2CEB@bbn.com> References: <1269638701.2838.303.camel@faith.austin.ibm.com> <1270571197.2838.504.camel@faith.austin.ibm.com> <50C9BA8B-3C10-4C7F-93B7-B95E0ECA2CEB@bbn.com> Content-Type: text/plain Date: Tue, 06 Apr 2010 16:19:32 -0500 Message-Id: <1270588772.2838.506.camel@faith.austin.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] Question about RFC 5114 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: latten@austin.ibm.com List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 21:40:59 -0000 On Tue, 2010-04-06 at 12:54 -0400, Richard Barnes wrote: > > Thanks so much for the detail. It has helped greatly. > > I did take a look at NIST SP 800-56A section 5.6.2.4 for validating > > the > > public value. I am in learning mode, so I found the 2nd step > > confusing... > > 1. Verify that 2 <= y <= p - 2 > > 2. Verify that y^q = 1 (mod p) > > > > Are the parenthesis around "mod p" correct? This is how it is in the > > NIST doc. > > > Yes, the parens are correct. That's just a more traditional notation > for modular equivalence: > > A = B (mod p) > > is the same as saying (in C notation) > > A % p == B % p > > So in your case you would want to check: > > y^q % p == 1 > Thanks so much!!! This definitely cleared it up for me! :-) regards, Joy From ynir@checkpoint.com Wed Apr 7 22:30: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 2641F3A697F for ; Wed, 7 Apr 2010 22:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, 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 IADvi1sVPw5W for ; Wed, 7 Apr 2010 22:30:28 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 2845D3A6960 for ; Wed, 7 Apr 2010 22:29:59 -0700 (PDT) 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 o385TsPq015052; Thu, 8 Apr 2010 08:29:54 +0300 (IDT) X-CheckPoint: {4BBD77C9-0-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 8 Apr 2010 08:30:15 +0300 From: Yoav Nir To: "ipsec@ietf.org" , "'Paul Hoffman'" Date: Thu, 8 Apr 2010 08:30:14 +0300 Thread-Topic: Another round of IKEv2-bis issues Thread-Index: AcrW3In+ZuLnbO51STmI7uA0oUr90g== Message-ID: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Another round of IKEv2-bis issues 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, 08 Apr 2010 05:30:29 -0000 Hi all=20 Following Sean's review, Paul has opened 7 issues, which we'd like to close= . I think issues #182, #183, #185 and #186 can be closed immediately.=20 I think issues #181, #184 and #187 can also be closed, and I have included = below my suggestions. Please take a look and respond if you object. As before, silence is treated as consent. Yoav Issue #181 - Section 2.4 unclear on Child SA failing =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Section 2.4 says "If Child SAs can fail independently from one another with= out the associated IKE SA being able to send a delete message, then they MU= ST be negotiated by separate IKE SAs". It is not clear what this means. Doe= s it apply to implementations? If so, how can an implementation know whethe= r or not the first clause is true?=20 I propose removing the sentence, or greatly clarifying it. Tero and Dave commented. Dave proposed alternative text, replacing "they" w= ith "each set of Child SAs": If sets of Child SAs can fail independently from one another without the as= sociated IKE SA being able to send a delete message, then each set of Child= SAs MUST be negotiated by separate IKE SAs. But I think this misses Sean's point, that while an implementation might be= able to know whether child SAs fail independently in itself, it has no way= of knowing this about the peer. So I propose we remove it entirely. Issue #182 - Marking CP() as optional in early sections =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Sean Turner asks: Sec 1.2/2.19: Shouldn't "[CP()]" be in message 3 and 4 in= Section 1.2? Tero said that the basic exchange described in section 1.2 does not include= many optional features like EAP, and NAT-T, so it can skip CP as well.=20 I agree with Tero. It is fine as it is. Issue #183 - Replace "X.509" with "PKIX" throughout? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D We use "X.509" when we probably mean "PKIX". That is, we only care about th= e PKIX profile of X.509, not just the base X.509 spec. However, X.509 appea= rs in some of the protocol element names. Can we change it throughout to PK= IX, or are we stuck with the old name? Sean replied to this, saying "Sec 3.5 is where the references to [X.501] an= d [X.509] are. You could just replace them with [PKIX], delete the two inf= ormative references, and be done." So we will make that change. Issue #184 - Interaction of rekeying of the IKE_SA and windows =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D s2.3: Should there be some discussion of the interaction of rekeying of the= IKE_SA and windows? Presumably a rekey message should not be actioned unti= l all previous messages have been responded to. Likewise receiving a Messag= e ID with a sequence number bigger than that in the rekey message should be= very suspect! Should the INVALID_MESSAGE_ID notification be sent in this c= ase (and before or after the rekey?) There might be some knock on into s2.8= where rekeying is discussed. And maybe into s2.25? Tero responded that section 2.25 already deals with these issues. If anyone= thinks differently, please say so NOW. Issue #185 - What do to if you don't ignore INITIAL_CONTACT =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D s2.4, para 2:=20 The INITIAL_CONTACT notification, if sent, MUST be in the first IKE_AUTH request or response, not as a separate exchange afterwards; receiving parties MAY ignore it in other messages.=20 What should receiving parties do if they *do* receive it and *don't* ignore= it? Since it 'MUST be sent in the first IKE_AUTH' receiving at any other t= ime is a protocol error and should cause some response (like dropping the I= KE_SA perhaps). Both Yaron and Tero responded, that because RFC 4306 did not mandate that I= NITIAL_CONTACT be sent only in the IKE_AUTH exchange, older implementations= may send it in other exchanges. Processing, in case they don't ignore it, = should be similar to the regular processing of INITIAL_CONTACT which is spe= cified in the next paragraph (conclude that the other IKE SAs have been era= sed, and silently discard them). So this text stays as it is. Issue #186 - Generating and accepting which types? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D s3.5, para after ID Field types table: 'Implementations SHOULD be capable o= f generating and accepting all of these types.' Does 'all' here mean the fo= ur types in the previous sentence or 'all' the types in the full table? Tero says: "Isn't this the same as issue #156 which was left as is." We really mean the four types from the previous sentence, so let's change "= accepting all of these types" to "accepting these all of these four types" Issue #187 - EAP introduction wording =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The first paragraph of 3.16 now says:=20 The Extensible Authentication Protocol Payload, denoted EAP in this documen= t, allows IKE SAs to be authenticated using the protocol defined in RFC 374= 8 and subsequent extensions to that protocol. The fu= ll set of acceptable values for the payload is defined elsewhere, but a sho= rt summary of RFC 3748 is included here to make this document stand alone i= n the common cases.=20 Where is "defined elsewhere"? We should be specific.=20 Also, we agreed to remove the short list of EAP methods, but we didn't fix = the last phrase above. Suggested wording would be appreciated. =20 Even Tero didn't reply to this, so here's my suggested wording (I just remo= ved the offending sentence: The Extensible Authentication Protocol Payload, denoted EAP in this document, allows IKE SAs to be authenticated using the protocol defined in RFC 3748 [EAP] and subsequent extensions to that protocol. A short summary of the EAP format is included here for clarity. From yaronf.ietf@gmail.com Wed Apr 7 23:02:23 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 56D4C3A6889 for ; Wed, 7 Apr 2010 23:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y21L5OWp9G8R for ; Wed, 7 Apr 2010 23:02:22 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id E52BB3A689C for ; Wed, 7 Apr 2010 23:02:20 -0700 (PDT) Received: by fxm5 with SMTP id 5so1827196fxm.29 for ; Wed, 07 Apr 2010 23:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=bxoA22ZBm8X3RtiI7gRtv9lUs62YRUQdI6kepy/L+cY=; b=AFdVKIS/iN0bBM/94DR0rBUzv7lk/N+w+Q3B3W8f1FKJUPjSlY+x/17PLRDTmjYVzY ZkgOk7zzHb/Do5MvTnqhsl9Dk/vok14EshfYIqhuLJCnULM4rwh3S77Ee/b6WFPMoXV8 4C8GHNvlqcyLxO2Nh/WKYsnqlX3yWfTZ03dHg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=EV4nlTPRctBzxYq/Z/82NBkh8ao2W8POaEuqet6bdGvMGimMXUoOo7XFOH3hq9tA8R MlGmyYKAUrTm6ZcJ0pphrtjvbY8YqtjrD2Jj2Xq3LVNbxGAlRq6O1AytIXsoSXzHO8SG tOorbpoUUZlK+THWgArFFgBMkgn2Od/5LJNt0= Received: by 10.223.17.197 with SMTP id t5mr1407220faa.84.1270706534445; Wed, 07 Apr 2010 23:02:14 -0700 (PDT) Received: from [192.168.2.102] (dslb-094-222-010-225.pools.arcor-ip.net [94.222.10.225]) by mx.google.com with ESMTPS id 14sm10028880fxm.5.2010.04.07.23.02.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 07 Apr 2010 23:02:14 -0700 (PDT) From: Yaron Sheffer To: Yoav Nir In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 08 Apr 2010 08:00:38 +0200 Message-ID: <1270706438.2422.9.camel@yaronf-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , 'Paul Hoffman' Subject: [IPsec] Issue #187, was: Re: Another round of IKEv2-bis issues 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, 08 Apr 2010 06:02:23 -0000 It's kind of weird to introduce EAP while avoiding any mention of EAP methods. So I propose: The Extensible Authentication Protocol Payload, denoted EAP in this document, allows IKE SAs to be authenticated using the protocol defined in RFC 3748 [EAP] and subsequent extensions to that protocol. When using EAP, an appropriate EAP method needs to be selected. Many of these methods have been defined, specifying the protocol's use with various authentication mechanisms. They are listed in [EAP-IANA]. A short summary of the EAP format is included here for clarity. Thanks, Yaron > > > Issue #187 - EAP introduction wording > ===================================== > The first paragraph of 3.16 now says: > > The Extensible Authentication Protocol Payload, denoted EAP in this document, allows IKE SAs to be authenticated using the protocol defined in RFC 3748 and subsequent extensions to that protocol. The full set of acceptable values for the payload is defined elsewhere, but a short summary of RFC 3748 is included here to make this document stand alone in the common cases. > > Where is "defined elsewhere"? We should be specific. > > Also, we agreed to remove the short list of EAP methods, but we didn't fix the last phrase above. Suggested wording would be appreciated. > > > Even Tero didn't reply to this, so here's my suggested wording (I just removed the offending sentence: > The Extensible Authentication Protocol Payload, denoted EAP in this > document, allows IKE SAs to be authenticated using the protocol > defined in RFC 3748 [EAP] and subsequent extensions to that protocol. > A short summary of the EAP format is included here for clarity. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Thu Apr 8 05:35:15 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 A8A553A6A63 for ; Thu, 8 Apr 2010 05:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoCEyT6AsfKw for ; Thu, 8 Apr 2010 05:35:14 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 42C9F3A63C9 for ; Thu, 8 Apr 2010 05:35:13 -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 o38CZ1sW018047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Apr 2010 15:35:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o38CYxLs009621; Thu, 8 Apr 2010 15:34:59 +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: <19389.52595.209726.960078@fireball.kivinen.iki.fi> Date: Thu, 8 Apr 2010 15:34:59 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> References: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 19 min X-Total-Time: 20 min Cc: "ipsec@ietf.org" , 'Paul Hoffman' Subject: [IPsec] Another round of IKEv2-bis issues 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, 08 Apr 2010 12:35:15 -0000 Yoav Nir writes: > Issue #181 - Section 2.4 unclear on Child SA failing > ==================================================== > Section 2.4 says "If Child SAs can fail independently from one > another without the associated IKE SA being able to send a delete > message, then they MUST be negotiated by separate IKE SAs". It is > not clear what this means. Does it apply to implementations? If so, > how can an implementation know whether or not the first clause is > true? > > I propose removing the sentence, or greatly clarifying it. > > Tero and Dave commented. Dave proposed alternative text, replacing > "they" with "each set of Child SAs": > > If sets of Child SAs can fail independently from one another without > the associated IKE SA being able to send a delete message, then each > set of Child SAs MUST be negotiated by separate IKE SAs. > > But I think this misses Sean's point, that while an implementation > might be able to know whether child SAs fail independently in > itself, it has no way of knowing this about the peer. Why should it know it about the peer? If the other end used same IKE SA to negotiate the Child SAs, then those Child SAs cannot fail independently. This case is only for the local implementors, it does not have any protocol implications, except that other end can assume that if Child SA A, and Child SA B are negotiated using same IKE SA C, then if A works, that means that B also works (or the Child SA is deleted using IKE SA C). The current text does not say anything what happens if the host Z tries to create Child SA A and Child SA B using IKE SA C, and host X notices that it cannot guarantee, that they cannot fail independently. Most likely host X will then return error, but most likely it can also make Child SA A and B so that they cannot fail independently, i.e. allocate them from the same security processor. I.e. if we make example where we have host A, having multiple security processors F, G, and H. Each of those security processors is able to run full IPsec, including multiple IKE SAs and Child SAs. Each of those security processors is separate, i.e. SAs are not shared between them, thus each IKE SA and Child SA is on only one of them. Also in this example we assume that one of those security processors can fail independently from others, i.e. even if one of them crashes, or looses state, the others can stay up. The device itself will then of course need some kind of internal "switch" inside, which will "route" IKE and Child SA packets to corresponding security processor. Now when host A is initiating negotiations it needs to make sure that the Child SAs and the corrseponding IKE SA are on the same security processor so if one of them fail, then all of them fail. If this is not true, then host B reciving packets from host A using child SA which happened to be on the other security processor than the IKE SA of that child SA, still thinks the host A is up and running, even when the IKE SA is already dead. This means that host B will never start DPD, as it is seeing valid packets from host A coming in, thus it will never notice that other Child SAs and the IKE SA on the other security processor are dead, and will happily send data to them without trying to recover. As the crash recovery is done on the IKE SA bases, and the crash recovery assumes that if any of the Child SAs on the IKE SA is alive, then the IKE SA is also alive, it is important that Child SAs and IKE SA cannot fail independently. > So I propose we remove it entirely. I do not agree on that. In most cases this is implementation hint that is not needed, as most environments do not have multiple independent security processors, but on those environments where we have those, it is important for correct behavior that implementors implement this correctly. Those who are really working on implementations on systems which have multiple independent security processors should understand what is said in the current text. As those people who do work on such implementaions is extremely small, I do not think there is need to add lots of material explaining the situation (as I did here in this email), but keeping the text in the specification is still needed. -- kivinen@iki.fi From wierbows@us.ibm.com Thu Apr 8 08:27:31 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 AF5B33A6A13; Thu, 8 Apr 2010 08:27:31 -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 alxsiDsd25Su; Thu, 8 Apr 2010 08:27:30 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 5B5D63A6A9A; Thu, 8 Apr 2010 08:27:26 -0700 (PDT) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e6.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o38FOhCc027557; Thu, 8 Apr 2010 11:24:43 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o38FRFVP113160; Thu, 8 Apr 2010 11:27:15 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o38FRFCx015169; Thu, 8 Apr 2010 11:27:15 -0400 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o38FREfe015130; Thu, 8 Apr 2010 11:27:14 -0400 In-Reply-To: <19389.52595.209726.960078@fireball.kivinen.iki.fi> References: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> <19389.52595.209726.960078@fireball.kivinen.iki.fi> X-KeepSent: 6AD2BFF8:4EBFBC83-852576FF:0050D170; type=4; name=$KeepSent To: Tero Kivinen X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Thu, 8 Apr 2010 11:27:10 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 04/08/2010 11:27:13 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Another round of IKEv2-bis issues 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, 08 Apr 2010 15:27:31 -0000 >Yoav Nir writes: >> Issue #181 - Section 2.4 unclear on Child SA failing >> ==================================================== >> Section 2.4 says "If Child SAs can fail independently from one >> another without the associated IKE SA being able to send a delete >> message, then they MUST be negotiated by separate IKE SAs". It is >> not clear what this means. Does it apply to implementations? If so, >> how can an implementation know whether or not the first clause is >> true? >> >> I propose removing the sentence, or greatly clarifying it. >> >> Tero and Dave commented. Dave proposed alternative text, replacing >> "they" with "each set of Child SAs": >> >> If sets of Child SAs can fail independently from one another without >> the associated IKE SA being able to send a delete message, then each >> set of Child SAs MUST be negotiated by separate IKE SAs. >> >> But I think this misses Sean's point, that while an implementation >> might be able to know whether child SAs fail independently in >> itself, it has no way of knowing this about the peer. > >Why should it know it about the peer? If the other end used same IKE >SA to negotiate the Child SAs, then those Child SAs cannot fail >independently. > >This case is only for the local implementors, it does not have any >protocol implications, except that other end can assume that if Child >SA A, and Child SA B are negotiated using same IKE SA C, then if A >works, that means that B also works (or the Child SA is deleted using >IKE SA C). > >The current text does not say anything what happens if the host Z >tries to create Child SA A and Child SA B using IKE SA C, and host X >notices that it cannot guarantee, that they cannot fail independently. >Most likely host X will then return error, but most likely it can also >make Child SA A and B so that they cannot fail independently, i.e. >allocate them from the same security processor. > >I.e. if we make example where we have host A, having multiple security >processors F, G, and H. Each of those security processors is able to >run full IPsec, including multiple IKE SAs and Child SAs. Each of >those security processors is separate, i.e. SAs are not shared between >them, thus each IKE SA and Child SA is on only one of them. Also in >this example we assume that one of those security processors can fail >independently from others, i.e. even if one of them crashes, or looses >state, the others can stay up. The device itself will then of course >need some kind of internal "switch" inside, which will "route" IKE and >Child SA packets to corresponding security processor. > >Now when host A is initiating negotiations it needs to make sure that >the Child SAs and the corrseponding IKE SA are on the same security >processor so if one of them fail, then all of them fail. > >If this is not true, then host B reciving packets from host A using >child SA which happened to be on the other security processor than the >IKE SA of that child SA, still thinks the host A is up and running, >even when the IKE SA is already dead. What is wrong with using a valid child SA? If you are claiming the child SA is not valid because it's IKE SA on host A no longer exists then I'll agree. When host A lost the IKE SA because the security processor failed it should have cleaned up any SAs created by the IKE SA. That does not mean all SAs created by the IKE SA need be on the same security processor. That's just your rule and how you decided to handle the situation. You could have kept knowledge of this relationship outside of the security processor. I see no reason to dictate how to handle this situation in the RFC. >This means that host B will >never start DPD, as it is seeing valid packets from host A coming in, >thus it will never notice that other Child SAs and the IKE SA on the >other security processor are dead, and will happily send data to them >without trying to recover. Well if host A did not properly cleanup up all child SAs I agree this could happen, but so what? Everyone is happy. Data is being exchanged as per the child SA. If host A did kill the child SA then dead peer detection would kick in as desired. It's probably more of an issue if the security processor containing a child SA died while the IKE SA was in another security processor, but I contend that in this scenario an implementation could be smart enough to know what child SAs are associated with each security processor and properly clean up. In this case it would even be able to send a delete. > >As the crash recovery is done on the IKE SA bases, and the crash >recovery assumes that if any of the Child SAs on the IKE SA is alive, >then the IKE SA is also alive, it is important that Child SAs and IKE >SA cannot fail independently. It's all a matter of bookkeeping. If they can fail separately you just need to keep track of what needs to be cleaned up when a failure occurs. The method you suggest is perhaps a good one and the easiest, but it is not the only one. > >> So I propose we remove it entirely. > I'm fine with removing it. >I do not agree on that. In most cases this is implementation hint that >is not needed, as most environments do not have multiple independent >security processors, but on those environments where we have those, it >is important for correct behavior that implementors implement this >correctly. Those who are really working on implementations on systems >which have multiple independent security processors should understand >what is said in the current text. As those people who do work on such >implementaions is extremely small, I do not think there is need to >add lots of material explaining the situation (as I did here in this >email), but keeping the text in the specification is still needed. I do not agree. The rule is simple. If an IKE fails cleanup all Child SAs created by it. In the case of a security processor failure you are guaranteed to have that happen if you keep the child SA on the same security processor, but that does not means that is the only way to do that. You have some distribution logic in place to begin with. That logic can save enough state to perform the proper cleanup. I see no reason to address how this cleanup occurs in this RFC. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Dave Wierbowski From root@core3.amsl.com Thu Apr 8 14:15:02 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 0DDC33A6952; Thu, 8 Apr 2010 14:15: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: <20100408211502.0DDC33A6952@core3.amsl.com> Date: Thu, 8 Apr 2010 14:15:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-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: Thu, 08 Apr 2010 21:15:02 -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 : Internet Key Exchange Protocol: IKEv2 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen Filename : draft-ietf-ipsecme-ikev2bis-09.txt Pages : 130 Date : 2010-4-8 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-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-ikev2bis-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-4-8140936.I-D@ietf.org> --NextPart-- From paul.hoffman@vpnc.org Thu Apr 8 16:11:40 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 2B7A03A6967 for ; Thu, 8 Apr 2010 16:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 iEo7A-fumWuL for ; Thu, 8 Apr 2010 16:11:39 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 00D393A68AD for ; Thu, 8 Apr 2010 16:11:37 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o38NBWpQ020304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Apr 2010 16:11:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 8 Apr 2010 16:11:30 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] One last review: draft-ietf-ipsecme-aes-ctr-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, 08 Apr 2010 23:11:40 -0000 I have revised the IKEv2bis draft with the IETF Last Call comments. It is available at . The diff is at . This is the WG's final chance for review before this is sent to the IESG for their approval. Yaron will ask our new AD, Sean Turner, to send the document to the IESG sometime early next week, so please do a final check NOW to see whether there are any mistakes introduced in the -09. Thanks! --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Thu Apr 8 18:14:11 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 A3E4A3A681C for ; Thu, 8 Apr 2010 18:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.923 X-Spam-Level: X-Spam-Status: No, score=-5.923 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 s+81YGvNFhG0 for ; Thu, 8 Apr 2010 18:14:10 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id ACEF23A67D3 for ; Thu, 8 Apr 2010 18:14: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 balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o391E5Nd024966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Apr 2010 18:14:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 8 Apr 2010 18:14:04 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] CORRECTION: One last review: draft-ietf-ipsecme-ikev2bis 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, 09 Apr 2010 01:14:11 -0000 I have revised the IKEv2bis draft with the IETF Last Call comments. It is available at . The diff is at . This is the WG's final chance for review before this is sent to the IESG for their approval. Yaron will ask our new AD, Sean Turner, to send the document to the IESG sometime early next week, so please do a final check NOW to see whether there are any mistakes introduced in the -09. Thanks! --Paul Hoffman, Director --VPN Consortium From yaronf.ietf@gmail.com Mon Apr 12 08:35:19 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 E12923A6894 for ; Mon, 12 Apr 2010 08:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1qEjPyKaatL for ; Mon, 12 Apr 2010 08:35:18 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id D15093A6781 for ; Mon, 12 Apr 2010 08:35:17 -0700 (PDT) Received: by ewy24 with SMTP id 24so1147709ewy.13 for ; Mon, 12 Apr 2010 08:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=4F81iwmDEZbmIEdjhRGHYqH39SDzcIWI3T5iFPSK3bQ=; b=gwjZu/o718ShFESGMKlYNuVZjaAYb6Xtd6sp7IQJzJbLW4zxOF1kcjcrdb5N4IkE0w KLgLEoZ15kOYVgdpNP2tgjp03OIzJbWWKNQjWvb0u5m5KPRe77ck48nJdMHmSKEAEiNR WzaimOb/Uk6UDwL5b53c/w5vU7F1hnJo6LR0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; b=f/wlh5hzwOBm6rL/TKqddgLoTW7H8nckRL3+5pMVg+NfodSvGVNZw7f21r/aD9/SlP aiji+cC+VUi4yy/01aLY89XkiF0dFNYz+L+0d8CelU3J5/GI1NFT7KOTzUBNs4x3fAV4 2ukfnq2vbZd5D1eq1AcQ+oHvt/eorym4tzJu8= Received: by 10.102.17.2 with SMTP id 2mr2086299muq.130.1271086509145; Mon, 12 Apr 2010 08:35:09 -0700 (PDT) Received: from [10.0.0.4] (bzq-109-65-24-251.red.bezeqint.net [109.65.24.251]) by mx.google.com with ESMTPS id 7sm17759177mup.33.2010.04.12.08.35.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 12 Apr 2010 08:35:08 -0700 (PDT) From: Yaron Sheffer To: ipsec@ietf.org In-Reply-To: <1271063569.21796.13.camel@yaronf-linux> References: <1271063569.21796.13.camel@yaronf-linux> Content-Type: text/plain; charset="UTF-8" Date: Mon, 12 Apr 2010 18:34:58 +0300 Message-ID: <1271086498.24999.0.camel@yaronf-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: [IPsec] #188: Explicit list of allowed EAP methods] 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, 12 Apr 2010 15:35:19 -0000 Hi, there was some off-line discussion on whether the mutual-EAP auth draft should explicitly list the EAP methods that work, securely, with this extension. I now tend to say no, and to remove this list (and IANA registry) from the next document rev. This issue summarizes the discussion. Thanks, Yaron #188: Explicit list of allowed EAP methods -----------------------------------+---------------------------------------- Reporter: yaronf.ietf@… | Owner: yaronf.ietf@… Type: defect | Status: new Priority: normal | Milestone: Component: eap-mutual | Severity: Active WG Document Keywords: | -----------------------------------+---------------------------------------- Rev -00 has a list of allowed methods, as a document section and a future IANA registry. Pros: * Vendors do not have to decide which methods are suitable - which may be error prone. * Some methods may be suitable only under certain conditions (e.g. only one variant of EAP-POTP is suitable, incidentally this happens to be the variant actually implemented). This is a place to document these restrictions. Cons: * EAP is a major interface into the AAA. Limiting the number of methods restricts this interface. * EAP methods (in particular tunnel methods) are used to convey additional info, e.g. posture. So even though some of them look weird in this context, because they might require server certs, they might make sense all the same. * Security can eventually depend on tunnel-internal EAP methods, which we will probably not document here. * Extra bureaucracy implied by the IANA registry. From paul.hoffman@vpnc.org Mon Apr 12 08:42:18 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 410073A69C3 for ; Mon, 12 Apr 2010 08:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.679 X-Spam-Level: X-Spam-Status: No, score=-4.679 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, 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 j8zcXcht-FTe for ; Mon, 12 Apr 2010 08:42:17 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 152563A68F3 for ; Mon, 12 Apr 2010 08:42:16 -0700 (PDT) Received: from [10.20.30.163] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o3CFg7YS087615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Apr 2010 08:42:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1271086498.24999.0.camel@yaronf-linux> References: <1271063569.21796.13.camel@yaronf-linux> <1271086498.24999.0.camel@yaronf-linux> Date: Mon, 12 Apr 2010 08:42:05 -0700 To: Yaron Sheffer , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] #188: Explicit list of allowed EAP methods] 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, 12 Apr 2010 15:42:18 -0000 At 6:34 PM +0300 4/12/10, Yaron Sheffer wrote: >there was some off-line discussion on whether the mutual-EAP auth draft >should explicitly list the EAP methods that work, securely, with this >extension. I now tend to say no, and to remove this list (and IANA >registry) from the next document rev. The list is not just "methods we like" but also "methods that are known to have the properties that are required to be safe here, because some other methods don't have those properties". A different proposal would be to leave the list in as "the authors think that these methods (and likely others) should be considered as safe", but not to have the IANA registry, letting developers pick what to include (including known-unsafe ones). --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Tue Apr 13 01:49: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 272B73A6805 for ; Tue, 13 Apr 2010 01:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.617 X-Spam-Level: X-Spam-Status: No, score=-1.617 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_50=0.001, 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 XrCtQfGwO1Sl for ; Tue, 13 Apr 2010 01:49:24 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 120283A691C for ; Tue, 13 Apr 2010 01:49:14 -0700 (PDT) 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 o3D8n8ph019367 for ; Tue, 13 Apr 2010 11:49:08 +0300 (IDT) X-CheckPoint: {4BC43DB4-2-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 13 Apr 2010 11:49:34 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Tue, 13 Apr 2010 11:49:07 +0300 Thread-Topic: Issue #177 Thread-Index: Acra5j3YZ66np9HlTaSJh/5S7FJmmQ== Message-ID: <5168444B-8DBF-4638-B2E5-BDFD5F1F6BB8@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] Issue #177 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, 13 Apr 2010 08:49:25 -0000 Hi all. As the previous discussion on this topic showed, the WG would like a more t= horough taxonomy in section 2 of the HA/LS draft. Here's what I have come u= p with so far. Please send comments to the list. 2. Terminology "Single Gateway" is an implementation of IKE and IPsec enforcing a certain policy, as described in [RFC4301]. "Cluster" is a set of two or more gateways, implementing the same security policy, and protecting the same domain. Clusters exist to provide both high availability through redundancy, and scalability through load sharing. "Member" is one gateway in a cluster. "High Availability" is a condition of a system, not a configuration type. A system is said to have high availability if its expected down time is low. High availability can be achieved in various ways, one of which is clustering. All the clusters described in this document achieve high availability. "Fault Tolerance" is a condition related to high availability, where a system maintains service availability, even when a specified set of fault conditions occur. In clusters, we expect the system to maintain service availability, when one of the cluster members fails. "Completely Transparent Cluster" is a cluster where the occurence of a fault is never visible to the peers. "Partially Transparent Cluster" is a cluster where the occurence of a fault may be visible to the peers. "Hot Standby Cluster", or "HS Cluster" is a cluster where only one of the members is active at any one time. This member is also referred to as the the "active", whereas the others are referred to as "stand- bys". [VRRP] is one method of building such a cluster. "Load Sharing Cluster", or "LS Cluster" is a cluster where more than one of the members may be active at the same time. The term "load balancing" is also common, but it implies that the load is actually balanced between the members, and we don't want to even imply that this is a requirement. "Failover" is the event where a one member takes over some load from some other member. In a hot standby cluster, this hapens when a standby memeber becomes active due to a failure of the former active member, or because of an administrator command. In a load sharing cluster this usually happens because of a failure of one of the members, but certain load-balancing technologies may allow a particular load (an SA) to move from one member to another to even out the load, even without any failures. "Tight Cluster" is a cluster where all the members share an IP address. This could be accomplished using configured interfaces with specialized protocols or hardware, such as VRRP, or through the use of multicast addresses, but in any case, peers need only be configured with one IP address in the PAD. "Loose Cluster" is a cluster where each member has a different IP address. Peers find the correct member using some method such as DNS queries or [REDIRECT]. "Synch Channel" is a communications channel among the cluster members, used to transfer state information. The synch channel may or may not be IP based, may or may not be encrypted, and may work over short or long distances. The security and physical characteristics of this channel are out of scope for this document, but it is a requirement that its use be minimized for scalability. From yaronf.ietf@gmail.com Tue Apr 13 02:33: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 E17263A6A0D for ; Tue, 13 Apr 2010 02:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPWqjNqXnyJx for ; Tue, 13 Apr 2010 02:33:12 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 5486C28C0E9 for ; Tue, 13 Apr 2010 02:30:31 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so1326943fge.13 for ; Tue, 13 Apr 2010 02:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=ekwKJ+9vEPtItsskEPYuLJ8j60joZpxFwrbCTMr01GM=; b=fIAOqmd3A7MkrryY9iuawyp9aM6PQylGdd46LXVm7lygCOCqVks/gHhdA3RIIvh48A ZG/F6p2cobmZeLuQFthSpaz76iZkbxFrwEw3rf1psGEbLcR2uGA5TmSkV4DTielMPsPe uiDs+/6plyslw6e41q1bRDdHG2FDeVyhP2d04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; b=m676R/Qu5pVjpoCkpagpTm8+gb05I5LlJIY5Bon3IUc8Vh31zSOA/vVrCJ84Ad1r3I qgo/CQCWKs1Duor88cHLxzonQJyQiH2mAngHAnDdyqmN3ejgavgtkkJr+7U/2gW3Sz46 VbhFX+nHAIVW1tNf/k39I6sUwmCpnO6qIQxR0= Received: by 10.223.64.205 with SMTP id f13mr3210238fai.98.1271151022536; Tue, 13 Apr 2010 02:30:22 -0700 (PDT) Received: from [10.0.0.4] ([109.67.14.147]) by mx.google.com with ESMTPS id g28sm10345189fkg.28.2010.04.13.02.30.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Apr 2010 02:30:22 -0700 (PDT) From: Yaron Sheffer To: ipsec@ietf.org In-Reply-To: <1271148367.3977.2.camel@yaronf-linux> References: <1271148367.3977.2.camel@yaronf-linux> Content-Type: text/plain; charset="UTF-8" Date: Tue, 13 Apr 2010 12:30:19 +0300 Message-ID: <1271151019.8244.1.camel@yaronf-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 8bit Subject: [IPsec] Draft IETF-77 minutes for your comments 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, 13 Apr 2010 09:33:14 -0000 Please send me any comments on-list or off-, before we submit the minutes into the proceedings. Thanks, Yaron IPsecME minutes: IETF 77 Monday, March 22, 2010 0900-1130 - Morning Session I Co-chairs: Yaron Sheffer, Paul Hoffman Minute takers: Shawn Emery and Richard Graveman (but all errors introduced by chairs). Paul Hoffman (PH): Yaron Sheffer via webex PH: "note well" not in IETF packet, implicit statement that you have read the "note well" PH: the group was initially chartered with a set of work items, going to recharter as these have been completed PH: agenda: IPsec HA, EAP-only , failure detection, PAKE authentication PH: new RFCs: 5658, 5723, 5739, Traffic Visibility in editor's queue, Heuristics in IESG review PH: Pasi Eronen stepping down as Security AD, stepping up Sean Turner PH: roadmap: new draft after Pasi's input. Will go to IETF LC soon PH: aes-ctr-ikev2 will go to IETF LC soon PH: ikev2bis will make changes and will submit to IESG review PH: ipsec-ha and eap-mutual, active work items The Jabber log is at http://www.ietf.org/jabber/logs/ipsecme/2010-03-22.txt. presentation on IPsec High Availability by Yoav Nir (YN) _________________ [slides presented] YN: ipsec-ha at -00. A problem statement (PS) and requirements will be written. Mixed vendor clusters and protocols between cluster members are out of scope. YN: map out as many challenges as possible with multiple vendors YN: similar to ipscha-ps-00 YN: load sharing is also applicable to ha YN: state change data: message identifiers in IKE and replay counters in IPsec YN: must not miss any IKE messages YN: peers do not require modification, but heavily uses synch channel PH: looking for contributors David McGrew asked about including crypto synch, e.g., for counter mode. See draft-ietf-msec-ipsec-group-counter-modes-05. Rodney van Meter: HA vs load sharing, two characteristics, cluster may not have either or both YN: what would you suggest. Rod: definition is incorrect, you can have HA that does or does not do load sharing. Stephen Kent (SK): state that needs to be synched, if you don't have syn on the receiving side you don't have replay YN: attacker can not cause fail-over and send replay attack SK: should separate send and receive sides to make this clear Rod: terminology: hot stand-by or dual-active. Cluster is ha, tolerant of failure Terry Davis: vendor to vendor interoperability is most important. Aviation industry has heterogeneous environment Terry: definitions of fields are most important, not as much as terminology presentation eap-mutual-00 by Yaron Sheffer (YS) ______________________ [slides presented] YS: channel binding not yet discussed in -00 Dan Harkins asked how the IKEv2 gateway obtains an identity. YS asked how this differs for “plain old IKEv2.” DH agreed it does not. Pasi Eronen (PE) said it works the same as in “plain old IKEv2.” PH: way forward? YS identified items for a -01 draft. SK asked about reliance on the AAA server to identify the security gateway. PE referred to the Charter - this needs to be fixed in the draft. Presentation: secure failure detection overview by PH Hoffman _____________________________________ [slides presented] The problem space will be discussed before the solution. Two different solutions drafts exist. Gregory Lebowitz (GL) asked whether liveness checks may be sent in other cases. Tero Kivinen (TK) explained how the lack of liveness replies can be used together with INVALID_SPI notifications. GL added an explanation of how counters can be used as well. PH acknowledged that these methods may be combined. (The goal is to distinguish failures from DoS attacks.) The two proposals are called QCD (draft-nir-ike-qcd) and SIR (draft-detienne-ikev2-recovery), which make different assumptions about on-path attackers. QCD maintains a token across reboots. SIR does not—it notes that an on-path attacker can cause rekeying in any event. The tradeoff involves security and resource usage tradeoffs. TK argued for additional security against killing the SA using an old idea of “birth certificates,” in effect, a reboot count. He offered to be a co-author. Fred Detienne asked about selection criteria. Would the computational overhead prohibit using birth certificates? PH asked for discussion on the ML. Presentation on PAKE process by Paul Hoffman ______________________ [slides presented] PH: will discuss the criteria, Yaron will not be talking about his proposed solution PH: clarity of what different criteria people have PH: also want to know which criteria is important PH: discuss criteria for two weeks PH: wants CFRG to get more involved, though they don't know much about IPR PH: asked NIST to take a look at PAKE Presentation on password authenticated key exchange selection criteria by Yaron Sheffer _______________________________________________________ [slides presented] See draft-sheffer-ipsecme-pake-criteria-01. Some discussion on the ML has already occurred. Both security and IPR are considered. Many proposals and options have been published. Discussion: Sean Turner (ST): asked about the scope and applicability of criteria. He asked about PW encoding—UTF-8? YS: This should be part of every solution, however this is a requirement, not a selection criterion. David Black (DB): In IP Storage, generation of strong shared secrets from human-memorable ones was an issue. Update of these values (password management) was another issue. Dan Harkins (DH): argued against too much focus on possibly speculative IPR discussion. PE added that factual statements need to be made carefully. Stephen Kent (SK): added some clarification about patent filings. PE: The coverage of a patent may not be clear. SK: pointed out that linking “future scalability: elliptic curves” is a misnomer, but cited the use of existing groups as a criterion. Seongham Shin asked about applicability to different modes. DB: A false consensus about IPR may be dangerous. David McGrew: We should consider on-line as well as off-line dictionary attacks against weak secrets. The use of passwords needs to be minimized. YS said that using passwords was an assumption, and he distinguished criteria from requirements. He also stated that expert opinions would be needed to clarify IPR issues, in addition to mere “factual statements”. DH: People are going to do what is easy anyway. We need to make it safe in spite of that. SK: Shutting down after bad password guesses has DoS implications. TK: It must be possible to implement simply, or it will not get used. Rene Struik asked about forward security. Unscheduled discussions ____________________ Suresh: will still would like some guidance from the working group on the roadmap draft Suresh: two weeks for feedback Sheila: including requirement levels in the doc Sheila: view it as value added, requirements in the roadmap mapping to RFCs is helpful PE: requirements on algorithms, we already have an RFC that does it. Two places need to be updated for these changes. PE: roadmap will be incomplete after a couple of years in any case, but should not become incorrect. PH: put a note that this roadmap will not be updated. PE: roadmap has options, not requirements Sheila: only recently included algorithms, adding verbiage in the draft is fine. Suresh: Tero originally requested. David McGrew: documenting existing status, how do we want to update the algorithms? David Quigley: reworking labeled IPsec draft, looking for input from working group Rod: 00 draft quantum keys, still pursuing individual submission From yaronf.ietf@gmail.com Tue Apr 13 03:17: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 15B7C3A6A29 for ; Tue, 13 Apr 2010 03:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFsmKoftlkvy for ; Tue, 13 Apr 2010 03:17:41 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id D14EE3A691F for ; Tue, 13 Apr 2010 03:17:19 -0700 (PDT) Received: by bwz9 with SMTP id 9so5560927bwz.29 for ; Tue, 13 Apr 2010 03:17:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=frbAAH0B2WnKSwoFoEidGqlqgJU6lbGCGBb2HYfiZtc=; b=goaY9pEaY7+d4tsg9RH8BOeEcdxHlYWcFfD2ehPHkfNy3EY1LMywMt972JKwrLWcdD 2fPxY6G8wNP5sZ4dccs8hlNqz2wqXgCCtbEUkluwIFsgzGQ/Si37gnAXeRUhUK7hewqh NYoEQNjTCg32MAVYQ4bUUHScfakUymYpjEfrU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=dBQTqMwvxxl2TVNoQqeNcvuN7luydYYZhhtBr0qOvlE0RxT8KHIfoh0kQS/ealGs00 +E2laLJ0A3pk667YxfL2YrL7gkEpOyJQi9eS8E6QqpVusPBCF61w+61Scc1DYqNuOxR+ dPJtAxxDojHowRK4bNEneI7VzyUndEWhPuxGk= Received: by 10.87.71.21 with SMTP id y21mr4824688fgk.69.1271153830427; Tue, 13 Apr 2010 03:17:10 -0700 (PDT) Received: from [10.0.0.4] ([109.67.14.147]) by mx.google.com with ESMTPS id 28sm10505575fkx.6.2010.04.13.03.17.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Apr 2010 03:17:10 -0700 (PDT) From: Yaron Sheffer To: Yoav Nir In-Reply-To: <1271150696.3977.11.camel@yaronf-linux> References: <5168444B-8DBF-4638-B2E5-BDFD5F1F6BB8@checkpoint.com> <1271150696.3977.11.camel@yaronf-linux> Content-Type: text/plain; charset="UTF-8" Date: Tue, 13 Apr 2010 13:17:07 +0300 Message-ID: <1271153827.2090.0.camel@yaronf-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Issue #177 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, 13 Apr 2010 10:17:45 -0000 Looks good. A few comments down below. Yaron On Tue, 2010-04-13 at 11:49 +0300, Yoav Nir wrote: > Hi all. > > As the previous discussion on this topic showed, the WG would like a more thorough taxonomy in section 2 of the HA/LS draft. Here's what I have come up with so far. Please send comments to the list. > > 2. Terminology > > "Single Gateway" is an implementation of IKE and IPsec enforcing a > certain policy, as described in [RFC4301]. > > "Cluster" is a set of two or more gateways, implementing the same > security policy, and protecting the same domain. Clusters exist to > provide both high availability through redundancy, and scalability > through load sharing. > > "Member" is one gateway in a cluster. > > "High Availability" is a condition of a system, not a configuration > type. A system is said to have high availability if its expected > down time is low. High availability can be achieved in various ways, > one of which is clustering. All the clusters described in this > document achieve high availability. > > "Fault Tolerance" is a condition related to high availability, where > a system maintains service availability, even when a specified set of > fault conditions occur. In clusters, we expect the system to > maintain service availability, when one of the cluster members fails. one or more > > "Completely Transparent Cluster" is a cluster where the occurence of > a fault is never visible to the peers. > > "Partially Transparent Cluster" is a cluster where the occurence of a > fault may be visible to the peers. > > "Hot Standby Cluster", or "HS Cluster" is a cluster where only one of > the members is active at any one time. This member is also referred > to as the the "active", whereas the others are referred to as "stand- > bys". [VRRP] is one method of building such a cluster. [Please ignore if you're sick and tired of terminology discussions:] I look at the term "hot standby" as contrasted with "warm/cold standby" (see http://www.webopedia.com/TERM/H/hot_standby.html). This is not what we mean here. Can we use "active-standby" instead? > > "Load Sharing Cluster", or "LS Cluster" is a cluster where more than > one of the members may be active at the same time. The term "load > balancing" is also common, but it implies that the load is actually > balanced between the members, and we don't want to even imply that > this is a requirement. > > "Failover" is the event where a one member takes over some load from > some other member. In a hot standby cluster, this hapens when a > standby memeber becomes active due to a failure of the former active > member, or because of an administrator command. In a load sharing > cluster this usually happens because of a failure of one of the > members, but certain load-balancing technologies may allow a > particular load (an SA) to move from one member to another to even > out the load, even without any failures. The parenthetical "an SA" implies that SAs are never shared between members. I suggest that the initial definition of "cluster" mention whether we expect IKE and IPsec SAs to be shared between members. > > "Tight Cluster" is a cluster where all the members share an IP > address. This could be accomplished using configured interfaces with > specialized protocols or hardware, such as VRRP, or through the use > of multicast addresses, but in any case, peers need only be > configured with one IP address in the PAD. > > "Loose Cluster" is a cluster where each member has a different IP > address. Peers find the correct member using some method such as DNS > queries or [REDIRECT]. Upon failure, members' IP addresses are reallocated to other members. > > "Synch Channel" is a communications channel among the cluster > members, used to transfer state information. The synch channel may > or may not be IP based, may or may not be encrypted, and may work > over short or long distances. The security and physical > characteristics of this channel are out of scope for this document, > but it is a requirement that its use be minimized for scalability. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Tue Apr 13 04:53:02 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 91EC328C0EC for ; Tue, 13 Apr 2010 04:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.763 X-Spam-Level: X-Spam-Status: No, score=-2.763 tagged_above=-999 required=5 tests=[AWL=0.836, 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 8eATKntbl560 for ; Tue, 13 Apr 2010 04:53:01 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id CF6193A6AF4 for ; Tue, 13 Apr 2010 04:52:55 -0700 (PDT) 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 o3DBqlph015142; Tue, 13 Apr 2010 14:52:47 +0300 (IDT) X-CheckPoint: {4BC468BE-0-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 13 Apr 2010 14:53:14 +0300 From: Yoav Nir To: Yaron Sheffer Date: Tue, 13 Apr 2010 14:52:46 +0300 Thread-Topic: [IPsec] Issue #177 Thread-Index: Acra/+WjU+0NtJx/Ra2m7Q0bxj3CwA== Message-ID: References: <5168444B-8DBF-4638-B2E5-BDFD5F1F6BB8@checkpoint.com> <1271150696.3977.11.camel@yaronf-linux> <1271153827.2090.0.camel@yaronf-linux> In-Reply-To: <1271153827.2090.0.camel@yaronf-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Issue #177 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, 13 Apr 2010 11:53:02 -0000 On Apr 13, 2010, at 1:17 PM, Yaron Sheffer wrote: > Looks good. A few comments down below. >=20 > Yaron >=20 > On Tue, 2010-04-13 at 11:49 +0300, Yoav Nir wrote: >>=20 >> "Fault Tolerance" is a condition related to high availability, where >> a system maintains service availability, even when a specified set of >> fault conditions occur. In clusters, we expect the system to >> maintain service availability, when one of the cluster members fails. >=20 > one or more Agreed. Fixed. >>=20 >> "Hot Standby Cluster", or "HS Cluster" is a cluster where only one of >> the members is active at any one time. This member is also referred >> to as the the "active", whereas the others are referred to as "stand- >> bys". [VRRP] is one method of building such a cluster. >=20 > [Please ignore if you're sick and tired of terminology discussions:] I > look at the term "hot standby" as contrasted with "warm/cold > standby" (see http://www.webopedia.com/TERM/H/hot_standby.html). This is > not what we mean here. Can we use "active-standby" instead? I can live with that. What do other think? >> "Failover" is the event where a one member takes over some load from >> some other member. In a hot standby cluster, this hapens when a >> standby memeber becomes active due to a failure of the former active >> member, or because of an administrator command. In a load sharing >> cluster this usually happens because of a failure of one of the >> members, but certain load-balancing technologies may allow a >> particular load (an SA) to move from one member to another to even >> out the load, even without any failures. >=20 > The parenthetical "an SA" implies that SAs are never shared between > members. I suggest that the initial definition of "cluster" mention > whether we expect IKE and IPsec SAs to be shared between members. That is not part of terminology. It's mentioned in section 3. How about I c= hange the parenthetical remark to "such as all the flows associated with a = particular SA" ? >> "Loose Cluster" is a cluster where each member has a different IP >> address. Peers find the correct member using some method such as DNS >> queries or [REDIRECT]. >=20 > Upon failure, members' IP addresses are reallocated to other members. They are? From yaronf.ietf@gmail.com Tue Apr 13 06:43: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 ED4063A6964 for ; Tue, 13 Apr 2010 06:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VepoD0Tsxh37 for ; Tue, 13 Apr 2010 06:43:16 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by core3.amsl.com (Postfix) with ESMTP id 075503A69C5 for ; Tue, 13 Apr 2010 06:43:09 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so1398821fge.13 for ; Tue, 13 Apr 2010 06:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=CYXOubckoijQWz0MvCnogwRHMtHLNBKZ12XtCvPCZqs=; b=vcGJ2Mk2Hx44jUYJe4L+bWJvoKmTqF+SZW1w5/W0GglQ/N8Uavh5RjKwV922FMYJ4F UK6LDca3DKmB8+g4hlRclZ3mst0DN+orIQmHv+iwmQrmJvNcrIbgyzA0eUf+ig7MOQpa DnjtkhyLTWAUOjqkdSJ0fOjLtWqczTDUUOGdk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=cday+hv0Buz/Ds8pe65jRFAL5pZ1hyEOBUfqLWDXsx5cjStfUDYmd4bydazk3Mmtym q3m9Y5yfFRYGebLE+frr3hpE1kJ41V6MJ4SZEOyc+LBBNtobIXD+7qGWiet6yrsVWxmi aPp5Z9n7SKLfaF1IH4ThqcytGug9xbWDfPZ5Q= Received: by 10.223.98.19 with SMTP id o19mr36732fan.80.1271166180950; Tue, 13 Apr 2010 06:43:00 -0700 (PDT) Received: from [10.0.0.4] ([109.67.14.147]) by mx.google.com with ESMTPS id z10sm10991465fka.31.2010.04.13.06.43.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Apr 2010 06:43:00 -0700 (PDT) From: Yaron Sheffer To: Yoav Nir In-Reply-To: References: <5168444B-8DBF-4638-B2E5-BDFD5F1F6BB8@checkpoint.com> <1271150696.3977.11.camel@yaronf-linux> <1271153827.2090.0.camel@yaronf-linux> Content-Type: text/plain; charset="UTF-8" Date: Tue, 13 Apr 2010 16:42:57 +0300 Message-ID: <1271166177.5481.10.camel@yaronf-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Issue #177 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, 13 Apr 2010 13:43:17 -0000 [snip] > >> "Failover" is the event where a one member takes over some load from > >> some other member. In a hot standby cluster, this hapens when a > >> standby memeber becomes active due to a failure of the former active > >> member, or because of an administrator command. In a load sharing > >> cluster this usually happens because of a failure of one of the > >> members, but certain load-balancing technologies may allow a > >> particular load (an SA) to move from one member to another to even > >> out the load, even without any failures. > > > > The parenthetical "an SA" implies that SAs are never shared between > > members. I suggest that the initial definition of "cluster" mention > > whether we expect IKE and IPsec SAs to be shared between members. > > That is not part of terminology. It's mentioned in section 3. How about I change the parenthetical remark to "such as all the flows associated with a particular SA" ? OK, with a nit: "such as all the flows associated with a particular IKE SA". > > >> "Loose Cluster" is a cluster where each member has a different IP > >> address. Peers find the correct member using some method such as DNS > >> queries or [REDIRECT]. > > > > Upon failure, members' IP addresses are reallocated to other members. > > They are? > > OK, not necessarily (but it's one reasonable way to reduce the fail-over time): Upon failure, members' IP addresses may be reallocated to other members. From ynir@checkpoint.com Tue Apr 13 07:21: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 01CE428C0E2 for ; Tue, 13 Apr 2010 07:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[AWL=0.669, 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 40FqDUNKtwRl for ; Tue, 13 Apr 2010 07:21:08 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 1AE643A69E7 for ; Tue, 13 Apr 2010 07:20:33 -0700 (PDT) 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 o3DEKJph009370; Tue, 13 Apr 2010 17:20:19 +0300 (IDT) X-CheckPoint: {4BC48B50-0-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 13 Apr 2010 17:20:46 +0300 From: Yoav Nir To: Yaron Sheffer Date: Tue, 13 Apr 2010 17:20:16 +0300 Thread-Topic: [IPsec] Issue #177 Thread-Index: AcrbFIEk91anfOn1Q3uNbDp+3DQ4JQ== Message-ID: References: <5168444B-8DBF-4638-B2E5-BDFD5F1F6BB8@checkpoint.com> <1271150696.3977.11.camel@yaronf-linux> <1271153827.2090.0.camel@yaronf-linux> <1271166177.5481.10.camel@yaronf-linux> In-Reply-To: <1271166177.5481.10.camel@yaronf-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Issue #177 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, 13 Apr 2010 14:21:10 -0000 On Apr 13, 2010, at 4:42 PM, Yaron Sheffer wrote: > [snip] >>>> "Failover" is the event where a one member takes over some load from >>>> some other member. In a hot standby cluster, this hapens when a >>>> standby memeber becomes active due to a failure of the former active >>>> member, or because of an administrator command. In a load sharing >>>> cluster this usually happens because of a failure of one of the >>>> members, but certain load-balancing technologies may allow a >>>> particular load (an SA) to move from one member to another to even >>>> out the load, even without any failures. >>>=20 >>> The parenthetical "an SA" implies that SAs are never shared between >>> members. I suggest that the initial definition of "cluster" mention >>> whether we expect IKE and IPsec SAs to be shared between members. >>=20 >> That is not part of terminology. It's mentioned in section 3. How about = I change the parenthetical remark to "such as all the flows associated with= a particular SA" ? >=20 > OK, with a nit: "such as all the flows associated with a particular IKE > SA". >=20 I was thinking of an IPsec SA. But it's just an example (or a "such as") anyway.= From thamil@cisco.com Tue Apr 13 01:36: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 6CBE23A68E3 for ; Tue, 13 Apr 2010 01:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.188 X-Spam-Level: X-Spam-Status: No, score=-8.188 tagged_above=-999 required=5 tests=[AWL=2.410, 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 8fSyrkyGwj3Y for ; Tue, 13 Apr 2010 01:36:31 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0CBDA3A69F2 for ; Tue, 13 Apr 2010 01:36:29 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtkGAFHKw0tAaHte/2dsb2JhbACBPo4oi11xoXqZeIUMBIMl X-IronPort-AV: E=Sophos;i="4.52,196,1270425600"; d="scan'208,217";a="114373442" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 13 Apr 2010 08:36:20 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3D8ZWZ0000168 for ; Tue, 13 Apr 2010 08:36:20 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 13 Apr 2010 14:06:12 +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_01CADAE4.5F6792B8" Date: Tue, 13 Apr 2010 14:06:10 +0530 Message-ID: <0D25A594A60CDD45A1A00FCD1F88E7F8026126F9@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 Address resolution on IPsec node Thread-Index: Acra5F6oeXiZnXNFQDWo7weKYF8tRg== From: "Thamilarasu Kandasamy (thamil)" To: X-OriginalArrivalTime: 13 Apr 2010 08:36:12.0204 (UTC) FILETIME=[5F6FC6C0:01CADAE4] X-Mailman-Approved-At: Tue, 13 Apr 2010 08:32:45 -0700 Subject: [IPsec] IPv6 Address resolution on IPsec node 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, 13 Apr 2010 08:36:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CADAE4.5F6792B8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPv6 nodes use Neighbor Discovery messages for address resolution as defined in RFC 4861. However on an IPv6 node having IPsec implementation, if there is an SPD entry with a selector that covers all IP traffic, Neighbor Discovery messages could potentially be discarded (especially during system reload) and IKE negotiation be initiated. But this would eventually fail as the node haven't yet determined the link-layer address for the given IPv6 address. The RFC 4301 is not explicit about according any 'special' treatment to Neighbor Discovery messages. Like in case of IKE messages, we shall make provisions for ND messages to bypass IPsec protection? Would appreciate feedback/comments from the working group! =20 Thanks Thamil ------_=_NextPart_001_01CADAE4.5F6792B8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IPv6 nodes use Neighbor Discovery messages for = address resolution as defined in RFC 4861.  However on an IPv6 node having = IPsec implementation, if there is an SPD entry = with a selector that covers all IP traffic, Neighbor Discovery messages could potentially be discarded (especially during system reload) and IKE = negotiation be initiated.  But this would eventually fail as the node = haven’t yet determined the link-layer address for the given IPv6 address.  The = RFC 4301 is not explicit about  according any ‘special’ = treatment to Neighbor Discovery messages.  Like in case of IKE messages, we = shall make provisions for ND messages to bypass IPsec protection?  Would appreciate feedback/comments from the working = group!

 

Thanks

Thamil

------_=_NextPart_001_01CADAE4.5F6792B8-- From yaronf.ietf@gmail.com Tue Apr 13 08:36: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 D3E703A694C for ; Tue, 13 Apr 2010 08:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 6B4HpHcvhEaI for ; Tue, 13 Apr 2010 08:36:41 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id 8E3003A67B3 for ; Tue, 13 Apr 2010 08:36:41 -0700 (PDT) Received: by bwz9 with SMTP id 9so5934927bwz.29 for ; Tue, 13 Apr 2010 08:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer; bh=+5Tj/4YcahshTMPPMX+DQT/h9Z5NBJWaP81niVW5R9E=; b=IPJT0wtjMAmGSF0CZUo86whWZNCZH2DnmZsgXhJB6RlXo1vy8zO0nBfPVe4etI3ume zVRh7aYlQCxp/yFLqaeM0HVrBvltUUAr5dDmOoY0ZUTjYEEiVY96AmXkZsgbDVfh13xA anDQ5TnLxptbr19QcXpRtQvfBIc0mEk2ChHoA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer; b=VXAcBFv0U4zuxBJM5RXge7k8O2p/rp2Ja07iac5wPwbcyJGXH5Htn3EKJz+YEmcx8d teS4Mhx4cTOGnRyZLh2CEFHvLqDvNHrP59JPIaA3YGbADZfxFq4gCUmDMcso3RIzHmtk orRTL6sTtCm8V6g7v5WqoBiYIDnlaos9YjCQg= Received: by 10.204.138.79 with SMTP id z15mr6598363bkt.59.1271172991774; Tue, 13 Apr 2010 08:36:31 -0700 (PDT) Received: from [10.0.0.4] ([109.67.14.147]) by mx.google.com with ESMTPS id 14sm2438661bwz.2.2010.04.13.08.36.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Apr 2010 08:36:31 -0700 (PDT) From: Yaron Sheffer To: ipsec@ietf.org Content-Type: multipart/alternative; boundary="=-ZTTP/JxnIRT9R1R4JWP5" Date: Tue, 13 Apr 2010 18:36:27 +0300 Message-ID: <1271172988.4237.74.camel@yaronf-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Subject: [IPsec] IKEv2-bis -09 (review of "diffs") 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, 13 Apr 2010 15:36:42 -0000 --=-ZTTP/JxnIRT9R1R4JWP5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Here's a quick review of the numerous changes between -08 and -09. Let's get these things resolved and move the doc to the IESG. * I'm a bit uneasy with the use of "Notify error message" instead of the simpler (and admittedly a bit vague) "notification". After all, these are not messages! * 2.4: For the sake of editing you eliminated a MUST NOT, I suggest to put it back. The original text had: "An implementation MUST NOT continue sending on any SA if some failure prevents it from receiving on all the associated SAs". * "Two expected attacks", but then "this attack" in the following sentence. I think -08 had it right, and this should be singular. Also, the word "if" slipped from the 2nd sentence. * "The preferred key size MUST be used as the length of SK_d, SK_pi, and SK_pr" - this is a new MUST, are we all happy with it? * 2.21.2: "Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer has been shown to understand them using the Vendor ID payload." The VID payload is one possibility, but there may be others (e.g. an earlier status notification). So I suggest to add "e.g. using the Vendor ID payload". * This text was removed from 2.23: "IKE MUST respond to the IP address and port from which packets arrived". Is this requirement covered elsewhere? * If you insist on changing NATs to NAT's in 2.23.1, you should make it NATs'. * In Sec. 4, I don't think we want to say "these are some of the features that can be omitted", implying that there are more. Why not "these are features"? Thanks, Yaron --=-ZTTP/JxnIRT9R1R4JWP5 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Here's a quick review of the numerous changes between -08 and -09. Let's get these things resolved  and move the doc to the IESG.

  • I'm a bit uneasy with the use of "Notify error message" instead of the simpler (and admittedly a bit vague) "notification". After all, these are not messages!
  • 2.4: For the sake of editing you eliminated a MUST NOT, I suggest to put it back. The original text had: "An implementation MUST NOT continue sending on any SA if some failure prevents it from receiving on all the associated SAs".
  • "Two expected attacks", but then "this attack" in the following sentence. I think -08 had it right, and this should be singular. Also, the word "if" slipped from the 2nd sentence.
  • "The preferred key size MUST be used as the length of SK_d, SK_pi, and SK_pr" - this is a new MUST, are we all happy with it?
  • 2.21.2: "Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer has been shown to understand them using the Vendor ID payload." The VID payload is one possibility, but there may be others (e.g. an earlier status notification). So I suggest to add "e.g. using the Vendor ID payload".
  • This text was removed from 2.23: "IKE MUST respond to the IP address and port from which packets arrived". Is this requirement covered elsewhere?
  • If you insist on changing NATs to NAT's in 2.23.1, you should make it NATs'.
  • In Sec. 4, I don't think we want to say "these are some of the features that can be omitted", implying that there are more. Why not "these are features"?

Thanks,
    Yaron

--=-ZTTP/JxnIRT9R1R4JWP5-- From paul.hoffman@vpnc.org Tue Apr 13 10:12:17 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 C0D6D3A6A5A for ; Tue, 13 Apr 2010 10:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 YKzOKhmt9mLg for ; Tue, 13 Apr 2010 10:12:15 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 5B9F43A6A4A for ; Tue, 13 Apr 2010 10:12:15 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o3DHC5dT073055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 10:12:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1271172988.4237.74.camel@yaronf-linux> References: <1271172988.4237.74.camel@yaronf-linux> Date: Tue, 13 Apr 2010 10:12:03 -0700 To: Yaron Sheffer , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] IKEv2-bis -09 (review of "diffs") 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, 13 Apr 2010 17:12:17 -0000 At 6:36 PM +0300 4/13/10, Yaron Sheffer wrote: >Here's a quick review of the numerous changes between -08 and -09. Let's get these things resolved and move the doc to the IESG. > >I'm a bit uneasy with the use of "Notify error message" instead of the simpler (and admittedly a bit vague) "notification". After all, these are not messages! They are notifications that have meaning. The meaning makes them a message to the implementation. I think the new wording is better than just "notification", particularly because there are two types of Notify payloads. >2.4: For the sake of editing you eliminated a MUST NOT, I suggest to put it back. The original text had: "An implementation MUST NOT continue sending on any SA if some failure prevents it from receiving on all the associated SAs". As Tero pointed out, this 2119 language only applied to a teeny subset of implementers, and even then I do not think it is actionable by itself. The replacement language is better. >"Two expected attacks", but then "this attack" in the following sentence. I think -08 had it right, and this should be singular. Also, the word "if" slipped from the 2nd sentence. Good catch; fixed in the editorial-only -10. >"The preferred key size MUST be used as the length of SK_d, SK_pi, and SK_pr" - this is a new MUST, are we all happy with it? It was strongly implied before. >2.21.2: "Extension documents may define new error notifications with these semantics, but MUST NOT use them unless the peer has been shown to understand them using the Vendor ID payload." The VID payload is one possibility, but there may be others (e.g. an earlier status notification). So I suggest to add "e.g. using the Vendor ID payload". Agree. >This text was removed from 2.23: "IKE MUST respond to the IP address and port from which packets arrived". Is this requirement covered elsewhere? Yes, many places. >If you insist on changing NATs to NAT's in 2.23.1, you should make it NATs'. Agree. >In Sec. 4, I don't think we want to say "these are some of the features that can be omitted", implying that there are more. Why not "these are features"? Agree. --Paul Hoffman, Director --VPN Consortium From turners@ieca.com Tue Apr 13 10:38: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 6DDEC28C121 for ; Tue, 13 Apr 2010 10:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, 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 74ogFB0M39fE for ; Tue, 13 Apr 2010 10:38:24 -0700 (PDT) Received: from smtp113.biz.mail.re2.yahoo.com (smtp113.biz.mail.re2.yahoo.com [66.196.116.98]) by core3.amsl.com (Postfix) with SMTP id 5439528C10F for ; Tue, 13 Apr 2010 10:38:24 -0700 (PDT) Received: (qmail 70274 invoked from network); 13 Apr 2010 17:38:16 -0000 Received: from thunderfish.local (turners@96.231.120.140 with plain) by smtp113.biz.mail.re2.yahoo.com with SMTP; 13 Apr 2010 10:38:15 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: hXy3Et8VM1njFZY7djArqoejBwNCu4TlSjsvMJCSiW0_.g28JAciqkWvEdRqsDzYBY4SEOejeESjlFWGkMfgIjGLdsIzlUJqWA5wbm83bzt2VEz4kHADDoWWhGuMSQD0Npw8c6U1EjZUnoADmJK1YWvXWpvyI2POzz4TYWCkjiJAwhlB9TOiqm6KseMVk.FBcvdVRFypwHsij6j0tJJTQfJZNYpboELam2DSZWvIlDfcjPOWrbW0Tsp_ORtZ_6pikH3W8izXb.fCys9KFbrG.myESSiE19NeRPkKicZD9bK_WxqrDrmpJuVJ4d1UonZAm.LeAfUq.LVGYfvTBgMdlkqifMMAUs4lWJEAgs_p0RACCcEzvdqCW1BXwXbESab4Zt7J7nlF5mjWiLmMY7YXn8nasfWeOAhuEYjbv6RGbNGCIGeRy7ILpwFuI74QI3TXn71gTh8C7qZjimzjID0- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BC4AC07.2070107@ieca.com> Date: Tue, 13 Apr 2010 13:38:15 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Paul Hoffman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] CORRECTION: One last review: draft-ietf-ipsecme-ikev2bis 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, 13 Apr 2010 17:38:25 -0000 One nit, I missed earlier: Section 6, there's a reference to [RFC4306] but the reference section uses [IKEv2]. spt Paul Hoffman wrote: > I have revised the IKEv2bis draft with the IETF Last Call comments. It is available at . The diff is at . > > This is the WG's final chance for review before this is sent to the IESG for their approval. Yaron will ask our new AD, Sean Turner, to send the document to the IESG sometime early next week, so please do a final check NOW to see whether there are any mistakes introduced in the -09. Thanks! > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From paul.hoffman@vpnc.org Tue Apr 13 11:26: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 83BAE3A6A7A for ; Tue, 13 Apr 2010 11:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.818 X-Spam-Level: X-Spam-Status: No, score=-5.818 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 1XKT-au1zY+v for ; Tue, 13 Apr 2010 11:26:04 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 84F7B3A6A6A for ; Tue, 13 Apr 2010 11:26:04 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o3DIPtof077851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Apr 2010 11:25:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4BC4AC07.2070107@ieca.com> References: <4BC4AC07.2070107@ieca.com> Date: Tue, 13 Apr 2010 11:25:54 -0700 To: Sean Turner From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] CORRECTION: One last review: draft-ietf-ipsecme-ikev2bis 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, 13 Apr 2010 18:26:05 -0000 At 1:38 PM -0400 4/13/10, Sean Turner wrote: >One nit, I missed earlier: > >Section 6, there's a reference to [RFC4306] but the reference section uses [IKEv2]. Good catch! Fixed in -10. --Paul Hoffman, Director --VPN Consortium From alper.yegin@yegin.org Tue Apr 13 23:48: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 826D83A6BAD for ; Tue, 13 Apr 2010 23:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] 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 hDlVh6qlLRom for ; Tue, 13 Apr 2010 23:48:48 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id A5D9E3A6BAB for ; Tue, 13 Apr 2010 23:48:48 -0700 (PDT) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Me9Ic-1NqLXR1XWY-00PSWs; Wed, 14 Apr 2010 02:48:39 -0400 From: "Alper Yegin" To: "'Paul Hoffman'" , "'Yaron Sheffer'" , References: <1271063569.21796.13.camel@yaronf-linux> <1271086498.24999.0.camel@yaronf-linux> In-Reply-To: Date: Wed, 14 Apr 2010 09:48:27 +0300 Message-ID: <02f201cadb9e$803086a0$809193e0$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcraVrrU0/l1O8P5RxO+WORXfpo+eQBR6BFQ Content-Language: en-us X-Provags-ID: V01U2FsdGVkX1/Xqu/k6kYHl1/g2sB0bqq6vjCDaHt7Br5zdAa xUYE9uGkkcxxBofoDGplJReuDOkU26NuJ9S1u4k86Qd1I5gH0y YG8LEUPmbz6Ymzsg/T0VwOF4+n4qJSU Subject: Re: [IPsec] #188: Explicit list of allowed EAP methods] 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, 14 Apr 2010 06:48:49 -0000 > At 6:34 PM +0300 4/12/10, Yaron Sheffer wrote: > >there was some off-line discussion on whether the mutual-EAP auth > draft > >should explicitly list the EAP methods that work, securely, with this > >extension. I now tend to say no, and to remove this list (and IANA > >registry) from the next document rev. > > The list is not just "methods we like" but also "methods that are known > to have the properties that are required to be safe here, because some > other methods don't have those properties". > > A different proposal would be to leave the list in as "the authors > think that these methods (and likely others) should be considered as > safe", but not to have the IANA registry, letting developers pick what > to include (including known-unsafe ones). Or, just list the required "properties", and name some methods as examples. Alper > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Wed Apr 14 07:25: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 5FA963A67D4 for ; Wed, 14 Apr 2010 07:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0xdq14vdq5P for ; Wed, 14 Apr 2010 07:25:41 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BD0B528C27F for ; Wed, 14 Apr 2010 07:25:02 -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 o3EEOqne022885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Apr 2010 17:24:52 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3EEOpMc001267; Wed, 14 Apr 2010 17:24:51 +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: <19397.53299.236897.928822@fireball.kivinen.iki.fi> Date: Wed, 14 Apr 2010 17:24:51 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 76 min Cc: IPsecme WG Subject: [IPsec] CORRECTION: One last review: draft-ietf-ipsecme-ikev2bis 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, 14 Apr 2010 14:25:42 -0000 Paul Hoffman writes: > I have revised the IKEv2bis draft with the IETF Last Call comments. > It is available at > . The > diff is at > . > > This is the WG's final chance for review before this is sent to the > IESG for their approval. Yaron will ask our new AD, Sean Turner, to > send the document to the IESG sometime early next week, so please do > a final check NOW to see whether there are any mistakes introduced > in the -09. Thanks! In the section 1.2 the text The recipients of messages 3 and 4 MUST verify that all signatures and MACs are computed correctly. was changed to Both parties in the IKE_SA_INIT exchange MUST verify that all signatures and MACs are computed correctly. which is wrong, as IKE_SA_INIT is messages 1 and 2, IKE_AUTH is the messages 3 and 4. IKE_SA_INIT messages do not have signatures or MACs. ---------------------------------------------------------------------- In the section 2.23 the following text was removed: "UDP encapsulation MUST NOT be done on port 500." I think that text should still be there. Also you removed mandatory requirement for listening port 4500 if NAT-T is supported. So I would add the first bullet back. I do not understand why it this was removed: o IKE MUST listen on port 4500 as well as port 500. IKE MUST respond to the IP address and port from which packets arrived. Yes, the last part is explained multiple time, but it is especially important for NAT-T case, which makes it worth of repeating in this requirement list. ---------------------------------------------------------------------- In section 2.25 there is typo: s/REYEY_SA/REKEY_SA/ ---------------------------------------------------------------------- In section 3.3.1 the -09 version says: "the SPI is obtained from the outer IP header." which is completely wrong. IP header does not have SPI field, the IKE header has SPI field. Remove the offending "IP" which was added in last version. -- kivinen@iki.fi From kivinen@iki.fi Wed Apr 14 08:02:02 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 6D66A28C266 for ; Wed, 14 Apr 2010 08:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfs03cWSQ+qC for ; Wed, 14 Apr 2010 08:02:01 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9B81228C28F for ; Wed, 14 Apr 2010 08:01:46 -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 o3EF0mNM025801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Apr 2010 18:00:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3EF0m6L022910; Wed, 14 Apr 2010 18:00:48 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19397.55456.596478.752413@fireball.kivinen.iki.fi> Date: Wed, 14 Apr 2010 18:00:48 +0300 From: Tero Kivinen To: "Thamilarasu Kandasamy (thamil)" In-Reply-To: <0D25A594A60CDD45A1A00FCD1F88E7F8026126F9@XMB-BGL-414.cisco.com> References: <0D25A594A60CDD45A1A00FCD1F88E7F8026126F9@XMB-BGL-414.cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 8 min Cc: ipsec@ietf.org Subject: [IPsec] IPv6 Address resolution on IPsec node 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, 14 Apr 2010 15:02:02 -0000 Thamilarasu Kandasamy (thamil) writes: > IPv6 nodes use Neighbor Discovery messages for address resolution as > defined in RFC 4861. However on an IPv6 node having IPsec > implementation, if there is an SPD entry with a selector that covers all > IP traffic, Neighbor Discovery messages could potentially be discarded > (especially during system reload) and IKE negotiation be initiated. But > this would eventually fail as the node haven't yet determined the > link-layer address for the given IPv6 address. The RFC 4301 is not > explicit about according any 'special' treatment to Neighbor Discovery > messages. Like in case of IKE messages, we shall make provisions for ND > messages to bypass IPsec protection? Would appreciate feedback/comments > from the working group! RFC4301 says that all kind traffic goes through SPD, including management traffic , which includes also IPsec management traffic such as IKE. This means that your SPD needs to explictly have passby rules for local management traffic, i.e. things like dhcp, neighbor discovery, router advertisement, router solication, IKE (both IPv4, and IPv6, and both normal IKE, and NAT-T IKE port). So all of those rules should be like just normal IPsec SPD rules, they should not be hardwired to the system (you can of course provide easy way to add all of those, for example if you do not turn "no default management rules" option on, then all of those rules are added automatically when you start your IPsec service). -- kivinen@iki.fi From paul.hoffman@vpnc.org Wed Apr 14 09:48: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 CA9EC28C288 for ; Wed, 14 Apr 2010 09:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 nhAk+O+UBq6S for ; Wed, 14 Apr 2010 09:48:25 -0700 (PDT) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2FF6528C2A9 for ; Wed, 14 Apr 2010 09:48:24 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o3EGmGAs095627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Apr 2010 09:48:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <19397.53299.236897.928822@fireball.kivinen.iki.fi> References: <19397.53299.236897.928822@fireball.kivinen.iki.fi> Date: Wed, 14 Apr 2010 09:48:14 -0700 To: Tero Kivinen From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: IPsecme WG Subject: Re: [IPsec] CORRECTION: One last review: draft-ietf-ipsecme-ikev2bis 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, 14 Apr 2010 16:48:25 -0000 At 5:24 PM +0300 4/14/10, Tero Kivinen wrote: >In the section 1.2 the text > > The recipients of messages 3 and 4 MUST verify that all signatures > and MACs are computed correctly. > >was changed to > > Both parties in the IKE_SA_INIT exchange MUST verify that all > signatures and MACs are computed correctly. > >which is wrong, as IKE_SA_INIT is messages 1 and 2, IKE_AUTH is the >messages 3 and 4. IKE_SA_INIT messages do not have signatures or MACs. Good catch: fixed in -10. >---------------------------------------------------------------------- >In the section 2.23 the following text was removed: > >"UDP encapsulation MUST NOT be done on port 500." > >I think that text should still be there. Agree. > >Also you removed mandatory requirement for listening port 4500 if >NAT-T is supported. So I would add the first bullet back. I do not >understand why it this was removed: > > o IKE MUST listen on port 4500 as well as port 500. IKE MUST > respond to the IP address and port from which packets arrived. > >Yes, the last part is explained multiple time, but it is especially >important for NAT-T case, which makes it worth of repeating in this >requirement list. This was removed because it appears in a list that is preceded with "In this section only, requirements listed as MUST apply only to implementations supporting NAT traversal." As you say, it also applies even if NAT traversal is not supported. >---------------------------------------------------------------------- >In section 2.25 there is typo: > >s/REYEY_SA/REKEY_SA/ Done. >---------------------------------------------------------------------- >In section 3.3.1 the -09 version says: > >"the SPI is obtained from the outer IP header." > >which is completely wrong. IP header does not have SPI field, the IKE >header has SPI field. Remove the offending "IP" which was added in >last version. Done. --Paul Hoffman, Director --VPN Consortium From ynir@checkpoint.com Wed Apr 14 10:27: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 A56B13A6944 for ; Wed, 14 Apr 2010 10:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.042 X-Spam-Level: X-Spam-Status: No, score=-3.042 tagged_above=-999 required=5 tests=[AWL=0.558, 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 ljovdqItwlMK for ; Wed, 14 Apr 2010 10:27:42 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 5E08B3A67FF for ; Wed, 14 Apr 2010 10:27:42 -0700 (PDT) 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 o3EHRZph012951 for ; Wed, 14 Apr 2010 20:27:35 +0300 (IDT) X-CheckPoint: {4BC608A5-0-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 14 Apr 2010 20:28:02 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Wed, 14 Apr 2010 20:27:33 +0300 Thread-Topic: New Version Notification for draft-ietf-ipsecme-ipsec-ha-01 Thread-Index: Acrb99V9SZh0Qx5SSteJGrk2rm+/dg== Message-ID: References: <20100414172114.34BF73A6A72@core3.amsl.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 Subject: [IPsec] Fwd: New Version Notification for draft-ietf-ipsecme-ipsec-ha-01 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, 14 Apr 2010 17:27:43 -0000 Begin forwarded message: > From: IETF I-D Submission Tool > Date: April 14, 2010 8:21:14 PM GMT+03:00 > To: Yoav Nir > Subject: New Version Notification for draft-ietf-ipsecme-ipsec-ha-01=20 >=20 >=20 > A new version of I-D, draft-ietf-ipsecme-ipsec-ha-01.txt has been success= fully submitted by Yoav Nir and posted to the IETF repository. >=20 > Filename: draft-ietf-ipsecme-ipsec-ha > Revision: 01 > Title: IPsec High Availability and Load Sharing Problem Statement > Creation_date: 2010-04-14 > WG ID: ipsecme > Number_of_pages: 11 >=20 > Abstract: > This document describes a requirement from IKE and IPsec to allow for > more scalable and available deployments for VPNs. It defines >=20 >=20 >=20 > The IETF Secretariat. >=20 From root@core3.amsl.com Wed Apr 14 10:30:02 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 70BC13A6359; Wed, 14 Apr 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: <20100414173002.70BC13A6359@core3.amsl.com> Date: Wed, 14 Apr 2010 10:30:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsec-ha-01.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: Wed, 14 Apr 2010 17:30:02 -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 : IPsec High Availability and Load Sharing Problem Statement Author(s) : Y. Nir Filename : draft-ietf-ipsecme-ipsec-ha-01.txt Pages : 11 Date : 2010-04-14 This document describes a requirement from IKE and IPsec to allow for more scalable and available deployments for VPNs. It defines A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsec-ha-01.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-ipsec-ha-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-14102113.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Apr 14 15:15:06 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 0E8D23A6ABA; Wed, 14 Apr 2010 15: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: <20100414221506.0E8D23A6ABA@core3.amsl.com> Date: Wed, 14 Apr 2010 15:15:04 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-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: Wed, 14 Apr 2010 22:15: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 : Internet Key Exchange Protocol: IKEv2 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen Filename : draft-ietf-ipsecme-ikev2bis-10.txt Pages : 130 Date : 2010-4-14 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-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-ikev2bis-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-4-14151045.I-D@ietf.org> --NextPart-- From turners@ieca.com Wed Apr 14 16:57: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 9478F3A6A2C for ; Wed, 14 Apr 2010 16:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, 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 645ZO9J3eUFC for ; Wed, 14 Apr 2010 16:57:46 -0700 (PDT) Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id BC7FC3A67AD for ; Wed, 14 Apr 2010 16:57:46 -0700 (PDT) Received: (qmail 96814 invoked from network); 14 Apr 2010 23:57:38 -0000 Received: from thunderfish.local (turners@71.191.4.64 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 14 Apr 2010 16:57:37 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: jMbnF14VM1nPF7kHsFHp.LOXwdLZeygUTUtDBLnZsI1GA.YWZcXDal2jfeHZnMJ4p_DcIxfPdt9abTgv4y527Rb7j8vP2GAAtYYixuP7HEbMNwU5wg1oM3hoGaJkCAYxgE_KNVyzLNN_UGQC4Yc70p1aj7WyTaRwM3do3J7bsWdaIUpO8FCKAXzSqJ6Nyd9zoLOMf5LfsT4dY5UAya2i9F5oSqxA8t.Ai_4i4xxErXIvm1ct44suZvjuiJ.6LdvMx4LDnbRwtVbXYOySeZbpY9PAQfFaoJ_mNi_rrjeDRIx19yMVkyARZICXvvK1knAvOev444XbngvnYB.9Nw1fjHuP06THwhgQsCvF9YBtsf1wfahgGMw4r04rnnFc3ekUwlYNX4z.91hFdXkM1p3yLr2qd4DvJJlBsOEWnVLPi9R3NAjjzbNARh0.f43tfJW9Mk5y2IqT2Y4- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BC65671.5000109@ieca.com> Date: Wed, 14 Apr 2010 19:57:37 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: ipsec@ietf.org References: <20100414221506.0E8D23A6ABA@core3.amsl.com> In-Reply-To: <20100414221506.0E8D23A6ABA@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-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: Wed, 14 Apr 2010 23:57:47 -0000 Internet-Drafts@ietf.org wrote: > 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 : Internet Key Exchange Protocol: IKEv2 > Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen > Filename : draft-ietf-ipsecme-ikev2bis-10.txt > Pages : 130 > Date : 2010-4-14 > > This document describes version 2 of the Internet Key Exchange (IKE) > protocol. IKE is a component of IPsec used for performing mutual > authentication and establishing and maintaining security associations > (SAs). This document replaces and updates RFC 4306, and includes all > of the clarifications from RFC 4718. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-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. I added this ID to the May 6th IESG telechat. I would have added it to the 4/22 agenda, but there are already 20+ documents on the agenda. spt From root@core3.amsl.com Wed Apr 14 22:45:14 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 F30D13A6816; Wed, 14 Apr 2010 22:45:04 -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: <20100415054506.F30D13A6816@core3.amsl.com> Date: Wed, 14 Apr 2010 22:45:04 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsec-ha-02.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: Thu, 15 Apr 2010 05:45:14 -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 : IPsec High Availability and Load Sharing Problem Statement Author(s) : Y. Nir Filename : draft-ietf-ipsecme-ipsec-ha-02.txt Pages : 11 Date : 2010-04-14 This document describes a requirement from IKE and IPsec to allow for more scalable and available deployments for VPNs. It defines A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsec-ha-02.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-ipsec-ha-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-14223754.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Apr 15 00:45:02 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 9DD793A688D; Thu, 15 Apr 2010 00:45:02 -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: <20100415074502.9DD793A688D@core3.amsl.com> Date: Thu, 15 Apr 2010 00:45:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-eap-mutual-01.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: Thu, 15 Apr 2010 07:45:02 -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 : An Extension for EAP-Only Authentication in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-ietf-ipsecme-eap-mutual-01.txt Pages : 14 Date : 2010-04-15 IKEv2 specifies that EAP authentication must be used together with public key signature based responder authentication. This is necessary with old EAP methods that provide only unilateral authentication using, e.g., one-time passwords or token cards. This document specifies how EAP methods that provide mutual authentication and key agreement can be used to provide extensible responder authentication for IKEv2 based on methods other than public key signatures. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-eap-mutual-01.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-eap-mutual-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-04-15003126.I-D@ietf.org> --NextPart-- From kivinen@iki.fi Fri Apr 16 06:28:32 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 B6B9D28C17C; Fri, 16 Apr 2010 06:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-1.068, 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 izPT8nBiksF5; Fri, 16 Apr 2010 06:28:31 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id C62B928C17A; Fri, 16 Apr 2010 06:18:47 -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 o3GDIZgD026587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Apr 2010 16:18:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3GDIYcS020716; Fri, 16 Apr 2010 16:18:34 +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: <19400.25514.92364.300616@fireball.kivinen.iki.fi> Date: Fri, 16 Apr 2010 16:18:34 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> <19389.52595.209726.960078@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 18 min Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Another round of IKEv2-bis issues 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, 16 Apr 2010 13:28:32 -0000 David Wierbowski writes: > What is wrong with using a valid child SA? If you are claiming > the child SA is not valid because it's IKE SA on host A no longer > exists then I'll agree. Yes. The Child SAs are tied up to the IKE SA and if IKE SA dies, all Child SAs needs to be deleted also. > When host A lost the IKE SA because the > security processor failed it should have cleaned up any SAs created > by the IKE SA. If the information that this Child SA belongs to that IKE SA was on the same security processor which had IKE SA then it cannot, and if this is the case, then the implementation is broken. If the Child SA on separate security processor still knows how to tie itself to the IKE SA, and can clean up the state, then the implementation is correct. The text there said that you should not create such implementation where the Child SA does not get deleted when IKE SA is deleted. Instead you needs to make sure that you can clean up all Child SAs when the IKE SA disappears. > That does not mean all SAs created by the IKE SA need > be on the same security processor. True. The text does not require that. It does require that you can maintain the connection between IKE SAs and Child SAs, and if you cannot, because of the setup, then you need to use separate IKE SAs. > That's just your rule and how you > decided to handle the situation. You could have kept knowledge of > this relationship outside of the security processor. I see no reason > to dictate how to handle this situation in the RFC. The RFC does not dicate solution, it dictates, that you need to solve the problem and make sure that the IKE SA and Child SA connection stays intact regardless of failures. And if you cannot ensure that then you need to use separate IKE SAs. > > >This means that host B will > >never start DPD, as it is seeing valid packets from host A coming in, > >thus it will never notice that other Child SAs and the IKE SA on the > >other security processor are dead, and will happily send data to them > >without trying to recover. > > Well if host A did not properly cleanup up all child SAs I agree this > could happen, but so what? Everyone is happy. Data is being > exchanged as per the child SA. If host A did kill the child SA then > dead peer detection would kick in as desired. Data is exchanged over one SA, but there might be others on other security processors, and from the Host B point of view those work too (as IKEv2 assumes that either all Child SAs and IKE SA fail, or all of them work). So Host B will send traffic to those SAs too, and that will cause black hole, as those SAs did get destroyed when the failure happened. > It's all a matter of bookkeeping. If they can fail separately you just > need to keep track of what needs to be cleaned up when a failure > occurs. If you keep that bookkeeping, then they do not fail separately, so this text does not apply. > >I do not agree on that. In most cases this is implementation hint that > >is not needed, as most environments do not have multiple independent > >security processors, but on those environments where we have those, it > >is important for correct behavior that implementors implement this > >correctly. Those who are really working on implementations on systems > >which have multiple independent security processors should understand > >what is said in the current text. As those people who do work on such > >implementaions is extremely small, I do not think there is need to > >add lots of material explaining the situation (as I did here in this > >email), but keeping the text in the specification is still needed. > > I do not agree. The rule is simple. If an IKE fails cleanup all Child > SAs created by it. In the case of a security processor failure you are > guaranteed to have that happen if you keep the child SA on the same > security processor, but that does not means that is the only way to > do that. You have some distribution logic in place to begin with. That > logic can save enough state to perform the proper cleanup. I see no > reason to address how this cleanup occurs in this RFC. I think we need to mandate that logic you explained there to the RFC. The text there does that. It says that you need to keep Child SAs and IKE SAs connected, and either all of them work, or none of them work (or you might also get delete notifications for those which failed, provided the IKE SA stays up). What is not allowed that some of the Child SAs stay up, but the IKE SA does not (i.e. no delete notifications). And this from the remote point of view, i.e. if you maintain internal bookeeping and destroy the Child SA when one security processor fails, that is fine, and from the remote point of view all Child SAs and IKE SA got destroyed. -- kivinen@iki.fi From turners@ieca.com Mon Apr 19 09:31:07 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 A088928C1A5 for ; Mon, 19 Apr 2010 09:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.412, BAYES_00=-2.599, 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 Y6OgRK6g3HKq for ; Mon, 19 Apr 2010 09:31:02 -0700 (PDT) Received: from smtp114.biz.mail.re2.yahoo.com (smtp114.biz.mail.re2.yahoo.com [66.196.116.99]) by core3.amsl.com (Postfix) with SMTP id 4CD883A6AC4 for ; Mon, 19 Apr 2010 09:07:41 -0700 (PDT) Received: (qmail 68060 invoked from network); 19 Apr 2010 16:07:30 -0000 Received: from thunderfish.local (turners@71.191.11.39 with plain) by smtp114.biz.mail.re2.yahoo.com with SMTP; 19 Apr 2010 09:07:30 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: sCb2pAcVM1k8H1XCS0eSrR1mm1NJLoRlWxfZjxBwmXVj1tQeWLXEs.Fm555ZwfzBLFTltsJGE5v_OfgfUd6afah5l1bQP4DMS1w34mCVfMC9K1iRE5inQRdvVStlNg9tI8vmT1_Aruy6uJVHJiSe3BuZkyj1d3PrXdjTejAwy1FcdX7p9oi..0I_ZW_wDmmtcHCVVLRNGc3Ujfu2QMgxRzIuLuK.uOM.oFlGaG._o.KZs26n0LVy5bYzY4_WkMRXFj94Gj_E0u78MOqspHkTIRQAiykWZLFihyfcebnn5VYvQ.fk86F_kO3VUGhvYJy1P6lpWjmLkDQNRDeqR2Ty_KRQ2Hh_vXu9w4gQr4DXPFJTnhaDvl3p2TbbGxdz0z9KempSN5vVS6pIwoL2dZzDu3RyssCw5xy5v4bAqS0f5qog_zahpuS2KSWRFhDn0CsMrEMGaeeiU85pQA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BCC7FC0.8080100@ieca.com> Date: Mon, 19 Apr 2010 12:07:28 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: IPsecme WG References: <20100401030002.3E5F63A6811@core3.amsl.com> In-Reply-To: <20100401030002.3E5F63A6811@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-aes-ctr-ikev2-07.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: Mon, 19 Apr 2010 16:31:07 -0000 Internet-Drafts@ietf.org wrote: > 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 : Using Advanced Encryption Standard (AES) Counter Mode with IKEv2 > Author(s) : S. Shen, et al. > Filename : draft-ietf-ipsecme-aes-ctr-ikev2-07.txt > Pages : 10 > Date : 2010-03-31 > > This document describes the usage of Advanced Encryption Standard > Counter Mode (AES-CTR), with an explicit initialization vector, by > IKEv2 for encrypting the IKEv2 exchanges that follow the IKE_SA_INIT > exchange. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-aes-ctr-ikev2-07.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > I added this ID to the May 6th IESG telechat. spt From wwwrun@rfc-editor.org Tue Apr 20 16:58:08 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 4032F3A6BA4; Tue, 20 Apr 2010 16:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.413 X-Spam-Level: X-Spam-Status: No, score=-1.413 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_93=0.6] 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 0PpH45nbKAE9; Tue, 20 Apr 2010 16:58:07 -0700 (PDT) Received: from rfc-editor.org (rfcpa [64.170.98.47]) by core3.amsl.com (Postfix) with ESMTP id 2AD9A3A6B98; Tue, 20 Apr 2010 16:58:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7CD79E07EB; Tue, 20 Apr 2010 16:57:58 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20100420235758.7CD79E07EB@rfc-editor.org> Date: Tue, 20 Apr 2010 16:57:58 -0700 (PDT) Cc: ipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 5840 on Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility 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, 20 Apr 2010 23:58:08 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5840 Title: Wrapped Encapsulating Security Payload (ESP) for Traffic Visibility Author: K. Grewal, G. Montenegro, M. Bhatia Status: Standards Track Stream: IETF Date: April 2010 Mailbox: ken.grewal@intel.com, gabriel.montenegro@microsoft.com, manav.bhatia@alcatel-lucent.com Pages: 15 Characters: 34733 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-traffic-visibility-12.txt URL: http://www.rfc-editor.org/rfc/rfc5840.txt This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on the Encapsulating Security Payload (ESP) RFC 4303 and is designed to allow intermediate devices to (1) ascertain if data confidentiality is being employed within ESP, and if not, (2) inspect the IPsec packets for network monitoring and access control functions. Currently, in the IPsec ESP standard, there is no deterministic way to differentiate between encrypted and unencrypted payloads by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate integrity-only ESP from ESP-encrypted packets, without compromising on the security provided by ESP. [STANDARDS TRACK] This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From ynir@checkpoint.com Wed Apr 21 01:47:57 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 1BEEA3A6835 for ; Wed, 21 Apr 2010 01:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_50=0.001, 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 ZYdL-I6PaHAt for ; Wed, 21 Apr 2010 01:47:56 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 419133A6358 for ; Wed, 21 Apr 2010 01:47:47 -0700 (PDT) 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 o3L8lJpi004090; Wed, 21 Apr 2010 11:47:19 +0300 (IDT) X-CheckPoint: {4BCEC8DB-0-1211DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 21 Apr 2010 11:47:47 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Wed, 21 Apr 2010 11:47:18 +0300 Thread-Topic: Issue #179 (was: Terminology issue (minor)) Thread-Index: AcrhL1CpdBdUu6RAQgiCKEV6llA/fw== Message-ID: References: <2f9f601123df0c8467eab4a5e9fed14b.squirrel@webmail.arsc.edu> In-Reply-To: <2f9f601123df0c8467eab4a5e9fed14b.squirrel@webmail.arsc.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 Cc: "shore@arsc.edu>" Subject: [IPsec] Issue #179 (was: Terminology issue (minor)) 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, 21 Apr 2010 08:47:57 -0000 On Mar 22, 2010, at 6:44 PM, wrote: > This is probably a small thing, but in general the term "cluster" > implies at least some degree of shared state among cluster members. > I understand that there's some suggestion of that in saying that > a cluster protects the same domain but there's really quite a bit > more to it than that - it's going to things like the SADB or a subset > of the SADB. It needn't be in real-time or near real-time, but it > has to be there for it to be considered a cluster (rather than, say, > multi-homing). >=20 > I don't think including that in the definition requires that the > wg take on state synchronization among cluster members. >=20 > Melinda The current definition in the draft is as follows: "Cluster" is a set of two or more gateways, implementing the same security policy, and protecting the same domain. Clusters exist to provide both high availability through redundancy, and scalability through load sharing. There are some cases to be made for a cluster with no shared state. For exa= mple a "cold standby" configuration has the standby member coming "alive" w= hen the "active" fails, but it's similar to crash recovery -- all the SAs n= eed to be recreated from scratch (or through session resumption). In that c= ase the SPD and the session encryption key are all that needs to be synchro= nized, and this may be done manually. Would changing the definition as foll= ows be acceptable to everyone? "Cluster" is a set of two or more gateways, implementing the same security policy, and protecting the same domain. Clusters exist to provide both high availability through redundancy, and scalability through load sharing. Clusters typically have some state that is shared among members, either manually or through a Synch channel=20 (see below). From yaronf.ietf@gmail.com Wed Apr 21 09:15:57 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 3E43F28C32F for ; Wed, 21 Apr 2010 09:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9SiuZtVUPpQ for ; Wed, 21 Apr 2010 09:15:50 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 5089D3A6B6F for ; Wed, 21 Apr 2010 08:49:54 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 22so2329510fge.13 for ; Wed, 21 Apr 2010 08:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=KIjWW1ral3A1Pr4l6/PL2h21kTaVZiUm1ayBx3d1FPE=; b=L0EslzBuwV+7UwVQRv/bTnPpe0YEo5c2FBU7VfKgM5RwWl2HTo+sWhuO0HUZG9fq99 T/YMrzkBychdePIkv7q44gjqVWqkHWrpAnYFR9NnkiD2YHbeZpZCe5+Y4riv9elgho75 JDJj2lP6NuB/GBPdWJxz+K31Mex4ThWJq/3Mw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=rPumWUZUAd/5ys6j9Q/48RhiJolhRJHOjSUKxp5Yod098P0gcqB2rnZIf5bPXdprU4 CVT1zSLFGvQ2IPyWZDHf9LKchX+aHJ15/dyUT+1wgb2sSmdQ4x3B82G+6aCcVNI+/YHT u3DFuCqnKvwNXh1K1TBU3P/1twrz4EHZo72CI= Received: by 10.223.18.154 with SMTP id w26mr270037faa.39.1271864826989; Wed, 21 Apr 2010 08:47:06 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-181-18-85.red.bezeqint.net [79.181.18.85]) by mx.google.com with ESMTPS id 18sm5274210fkq.34.2010.04.21.08.47.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 21 Apr 2010 08:47:06 -0700 (PDT) From: Yaron Sheffer To: ipsec Content-Type: text/plain; charset="UTF-8" Date: Wed, 21 Apr 2010 18:47:01 +0300 Message-ID: <1271864821.6636.55.camel@yaronf-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: [IPsec] IPsec HA draft 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, 21 Apr 2010 16:15:57 -0000 Hi, we've had a useful discussion on HA terminology, and Yoav published a new version of the draft: http://tools.ietf.org/html/draft-ietf-ipsecme-ipsec-ha-02. We'd like to move it forward ASAP so we can get into the fun protocol stuff. So, before we go into WG LC, I'd like to have the group's inputs on the completeness of the draft: are we missing anything that'll come back to bite us as we discuss the protocol? Thanks, Yaron From paul.hoffman@vpnc.org Wed Apr 21 14:39: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 25A5F3A68DB for ; Wed, 21 Apr 2010 14:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-2.230, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] 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 la0sr0h9DdK5 for ; Wed, 21 Apr 2010 14:39:33 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3D8893A683E for ; Wed, 21 Apr 2010 14:39:33 -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 o3LLdMiE078721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Apr 2010 14:39:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 21 Apr 2010 14:39:21 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Start of WG Last Call on draft-ietf-ipsecme-eap-mutual (EAP-Only Authentication) 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, 21 Apr 2010 21:39:34 -0000 Greetings again. We have kicked around draft-ietf-ipsecme-eap-mutual and its predecessor for a long time, and it seems like there have been few substantial comments lately. Thus, this starts the two-week WG Last Call on "An Extension for EAP-Only Authentication in IKEv2", . Please send any comments on the document to the mailing list. Support, criticism, and suggestions for additions or changes are all appropriate. At a minimum, I would like to see a handful of people say "I have read the draft". --Paul Hoffman, Director --VPN Consortium From B22245@freescale.com Wed Apr 21 23:59: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 D49663A6805 for ; Wed, 21 Apr 2010 23:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gigRD1XPWtds for ; Wed, 21 Apr 2010 23:59:37 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id CB90E3A6A38 for ; Wed, 21 Apr 2010 23:59:26 -0700 (PDT) Received: from de01smr02.am.mot.com (de01smr02.freescale.net [10.208.0.151]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id o3M6x0ni014665 for ; Wed, 21 Apr 2010 23:59:06 -0700 (MST) Received: from zin33exm29.fsl.freescale.net (zin33exm29.ap.freescale.net [10.232.192.28]) by de01smr02.am.mot.com (8.13.1/8.13.0) with ESMTP id o3M78rGT001319 for ; Thu, 22 Apr 2010 02:08:55 -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, 22 Apr 2010 12:28:46 +0530 Message-ID: <402621A7D69DDA458D0E12F070D1E55F7D4853@zin33exm29.fsl.freescale.net> In-Reply-To: <20100414221506.0E8D23A6ABA@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-10.txt Thread-Index: AcrcIBervC4h4EmXQdWFoRqBMKB5nQEVGy4g References: <20100414221506.0E8D23A6ABA@core3.amsl.com> From: "V Jyothi-B22245" To: Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-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: Thu, 22 Apr 2010 06:59:37 -0000 Hi, In section 2.9. Traffic Selector Negotiation, The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA request is unacceptable because its sender is only willing to accept traffic selectors specifying a single pair of addresses. The requestor is expected to respond by requesting an SA for only the specific traffic it is trying to forward. Above paragraph gives the clarity of what action to take when SINGLE_PAIR_REQUIRED notify type received in case of CREATE_CHILD_SA exchanges. Suppose if the SINGLE_PAIR_REQUIRED notify type is received in AUTH response, how initiator should act upon it? Can initiator resend AUTH request with different TSi and TSr payloads or it should establish IKE SA and then start CREATE_CHILD_SA exchange? Thanks Jyothi =20 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Thursday, April 15, 2010 3:45 AM To: i-d-announce@ietf.org Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-10.txt 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 : Internet Key Exchange Protocol: IKEv2 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen Filename : draft-ietf-ipsecme-ikev2bis-10.txt Pages : 130 Date : 2010-4-14 =09 This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations (SAs). This document replaces and updates RFC 4306, and includes all of the clarifications from RFC 4718. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2bis-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. From kivinen@iki.fi Thu Apr 22 04:09: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 03B0A3A6A42 for ; Thu, 22 Apr 2010 04:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=0.592, 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 CKvofppDMl-U for ; Thu, 22 Apr 2010 04:09:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B943C3A6A3C for ; Thu, 22 Apr 2010 04:09:27 -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 o3MB9CF1002585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2010 14:09:12 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3MB9C0D023988; Thu, 22 Apr 2010 14:09:12 +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: <19408.11864.296682.634981@fireball.kivinen.iki.fi> Date: Thu, 22 Apr 2010 14:09:12 +0300 From: Tero Kivinen To: "V Jyothi-B22245" In-Reply-To: <402621A7D69DDA458D0E12F070D1E55F7D4853@zin33exm29.fsl.freescale.net> References: <20100414221506.0E8D23A6ABA@core3.amsl.com> <402621A7D69DDA458D0E12F070D1E55F7D4853@zin33exm29.fsl.freescale.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-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: Thu, 22 Apr 2010 11:09:29 -0000 V Jyothi-B22245 writes: > Hi, > > In section 2.9. Traffic Selector Negotiation, > > The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA > request is unacceptable because its sender is only willing to accept > traffic selectors specifying a single pair of addresses. The > requestor is expected to respond by requesting an SA for only the > specific traffic it is trying to forward. > > Above paragraph gives the clarity of what action to take when > SINGLE_PAIR_REQUIRED notify type received in case of CREATE_CHILD_SA > exchanges. > > Suppose if the SINGLE_PAIR_REQUIRED notify type is received in AUTH > response, how initiator should act upon it? > Can initiator resend AUTH request with different TSi and TSr payloads or > it should establish IKE SA and then start CREATE_CHILD_SA exchange? It will establish IKE SA even when the Child SA creation failed. What it does next depends on the implementation. Normal implementation will simply do CREATE_CHILD_SA with better traffic selectors, and create Child SA that way. Some implementation might simply mark the specific rule so that it requires exact traffic selectors, and wait for next packet hitting that rule before starting CREATE_CHILD_SA (this is needed if the first Child SA creation in the IKE_AUTH was done because of auto-start rule, i.e. there is no traffic yet, thus the initiator does not know the exact traffic selectors). -- kivinen@iki.fi From B22245@freescale.com Thu Apr 22 05:42:57 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 8C99F3A69EC for ; Thu, 22 Apr 2010 05:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os4M2SLzWq+m for ; Thu, 22 Apr 2010 05:42:56 -0700 (PDT) Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id BA4D43A6807 for ; Thu, 22 Apr 2010 05:42:56 -0700 (PDT) Received: from de01smr02.am.mot.com (de01smr02.freescale.net [10.208.0.151]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id o3MCgV3g008450 for ; Thu, 22 Apr 2010 05:42:36 -0700 (MST) Received: from zin33exm29.fsl.freescale.net (zin33exm29.ap.freescale.net [10.232.192.28]) by de01smr02.am.mot.com (8.13.1/8.13.0) with ESMTP id o3MCqPUb015926 for ; Thu, 22 Apr 2010 07:52:26 -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, 22 Apr 2010 18:12:27 +0530 Message-ID: <402621A7D69DDA458D0E12F070D1E55F7D4883@zin33exm29.fsl.freescale.net> In-Reply-To: <19408.11864.296682.634981@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-10.txt Thread-Index: AcriDEZyKUZFMXEIQ3KJvXagvXDaHgACqTDQ References: <20100414221506.0E8D23A6ABA@core3.amsl.com><402621A7D69DDA458D0E12F070D1E55F7D4853@zin33exm29.fsl.freescale.net> <19408.11864.296682.634981@fireball.kivinen.iki.fi> From: "V Jyothi-B22245" To: "Tero Kivinen" Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-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: Thu, 22 Apr 2010 12:42:57 -0000 Hi, I find an issue in case of minimal implementations. Minimal implementations may not support CREATE_CHILD_SA exchanges, CHILD SA gets created as part of AUTH exchange. In this case, if the responder sends SINGLE_PAIR_REQUIRED, minimal implementations cannot start CREATE_CHILD_SA exchange and minimal implementation should not establish IKE SA because CHILD SA is not yet established and it may not be right solution to maintain the SINGLE_PAIR_REQUIRED notify reception information to use it in new IKEv2 exchange. Instead initiator can try sending AUTH request with single traffic selectors. Thanks Jyothi -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: Thursday, April 22, 2010 4:39 PM To: V Jyothi-B22245 Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-10.txt V Jyothi-B22245 writes: > Hi, >=20 > In section 2.9. Traffic Selector Negotiation, >=20 > The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA > request is unacceptable because its sender is only willing to accept > traffic selectors specifying a single pair of addresses. The > requestor is expected to respond by requesting an SA for only the > specific traffic it is trying to forward. >=20 > Above paragraph gives the clarity of what action to take when=20 > SINGLE_PAIR_REQUIRED notify type received in case of CREATE_CHILD_SA=20 > exchanges. >=20 > Suppose if the SINGLE_PAIR_REQUIRED notify type is received in AUTH=20 > response, how initiator should act upon it? > Can initiator resend AUTH request with different TSi and TSr payloads=20 > or it should establish IKE SA and then start CREATE_CHILD_SA exchange? It will establish IKE SA even when the Child SA creation failed. What it does next depends on the implementation. Normal implementation will simply do CREATE_CHILD_SA with better traffic selectors, and create Child SA that way. Some implementation might simply mark the specific rule so that it requires exact traffic selectors, and wait for next packet hitting that rule before starting CREATE_CHILD_SA (this is needed if the first Child SA creation in the IKE_AUTH was done because of auto-start rule, i.e. there is no traffic yet, thus the initiator does not know the exact traffic selectors). -- kivinen@iki.fi From ynir@checkpoint.com Thu Apr 22 06:01:50 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 D8DC53A6ABB for ; Thu, 22 Apr 2010 06:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.683, 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 W3qEBnPTvIif for ; Thu, 22 Apr 2010 06:01:49 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 26DF33A686A for ; Thu, 22 Apr 2010 06:01:22 -0700 (PDT) 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 o3MD19ph022865; Thu, 22 Apr 2010 16:01:09 +0300 (IDT) X-CheckPoint: {4BD0567B-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 22 Apr 2010 16:01:37 +0300 From: Yoav Nir To: V Jyothi-B22245 Date: Thu, 22 Apr 2010 16:01:09 +0300 Thread-Topic: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-10.txt Thread-Index: AcriG/EMiscZKmZaTQmJ9xaC6TXhyA== Message-ID: References: <20100414221506.0E8D23A6ABA@core3.amsl.com><402621A7D69DDA458D0E12F070D1E55F7D4853@zin33exm29.fsl.freescale.net> <19408.11864.296682.634981@fireball.kivinen.iki.fi> <402621A7D69DDA458D0E12F070D1E55F7D4883@zin33exm29.fsl.freescale.net> In-Reply-To: <402621A7D69DDA458D0E12F070D1E55F7D4883@zin33exm29.fsl.freescale.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-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: Thu, 22 Apr 2010 13:01:50 -0000 Hi. It's true that the standard is more geared to full implementations than tho= se minimal implementations, but in this case there really is no solution. The minimal implementation can delete the IKE SA that was created and start= fresh with a single pair. But since the responder is also not fully-functi= onal - it cannot handle complex selectors - there is no way that you can ge= t to a state where you cover all the selectors in the initiator's policy. T= he responder requires multiple SAs, while the initiator requires just one f= or the same policy. On Apr 22, 2010, at 3:42 PM, V Jyothi-B22245 wrote: > Hi, >=20 > I find an issue in case of minimal implementations. > Minimal implementations may not support CREATE_CHILD_SA exchanges, CHILD > SA gets created as part of AUTH exchange. >=20 > In this case, if the responder sends SINGLE_PAIR_REQUIRED, minimal > implementations cannot start CREATE_CHILD_SA exchange and minimal > implementation should not establish IKE SA because CHILD SA is not yet > established and it may not be right solution to maintain the > SINGLE_PAIR_REQUIRED notify reception information to use it in new IKEv2 > exchange. > Instead initiator can try sending AUTH request with single traffic > selectors. >=20 > Thanks > Jyothi >=20 >=20 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi]=20 > Sent: Thursday, April 22, 2010 4:39 PM > To: V Jyothi-B22245 > Cc: ipsec@ietf.org > Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-10.txt >=20 > V Jyothi-B22245 writes: >> Hi, >>=20 >> In section 2.9. Traffic Selector Negotiation, >>=20 >> The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA >> request is unacceptable because its sender is only willing to > accept >> traffic selectors specifying a single pair of addresses. The >> requestor is expected to respond by requesting an SA for only the >> specific traffic it is trying to forward. >>=20 >> Above paragraph gives the clarity of what action to take when=20 >> SINGLE_PAIR_REQUIRED notify type received in case of CREATE_CHILD_SA=20 >> exchanges. >>=20 >> Suppose if the SINGLE_PAIR_REQUIRED notify type is received in AUTH=20 >> response, how initiator should act upon it? >> Can initiator resend AUTH request with different TSi and TSr payloads=20 >> or it should establish IKE SA and then start CREATE_CHILD_SA exchange? >=20 > It will establish IKE SA even when the Child SA creation failed. >=20 > What it does next depends on the implementation. Normal implementation > will simply do CREATE_CHILD_SA with better traffic selectors, and create > Child SA that way. Some implementation might simply mark the specific > rule so that it requires exact traffic selectors, and wait for next > packet hitting that rule before starting CREATE_CHILD_SA (this is needed > if the first Child SA creation in the IKE_AUTH was done because of > auto-start rule, i.e. there is no traffic yet, thus the initiator does > not know the exact traffic selectors). > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Thu Apr 22 06:16: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 6E1943A69F3 for ; Thu, 22 Apr 2010 06:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, 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 XHCt2OZRWxE4 for ; Thu, 22 Apr 2010 06:16:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 47D1828C136 for ; Thu, 22 Apr 2010 06:15:40 -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 o3MDFK7l015670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2010 16:15:20 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3MDFJLr011426; Thu, 22 Apr 2010 16:15:19 +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: <19408.19431.354722.531641@fireball.kivinen.iki.fi> Date: Thu, 22 Apr 2010 16:15:19 +0300 From: Tero Kivinen To: "V Jyothi-B22245" In-Reply-To: <402621A7D69DDA458D0E12F070D1E55F7D4883@zin33exm29.fsl.freescale.net> References: <20100414221506.0E8D23A6ABA@core3.amsl.com> <402621A7D69DDA458D0E12F070D1E55F7D4853@zin33exm29.fsl.freescale.net> <19408.11864.296682.634981@fireball.kivinen.iki.fi> <402621A7D69DDA458D0E12F070D1E55F7D4883@zin33exm29.fsl.freescale.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 20 min Cc: ipsec@ietf.org Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-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: Thu, 22 Apr 2010 13:16:22 -0000 V Jyothi-B22245 writes: > I find an issue in case of minimal implementations. > Minimal implementations may not support CREATE_CHILD_SA exchanges, CHILD > SA gets created as part of AUTH exchange. Minimal implementation most likely do not understand SINGLE_PAIR_REQUIRED either, so it will most likely simply get the IKE SA up, and then delete it as it does not have any useful things to do with it. > In this case, if the responder sends SINGLE_PAIR_REQUIRED, minimal > implementations cannot start CREATE_CHILD_SA exchange and minimal > implementation should not establish IKE SA because CHILD SA is not yet > established and it may not be right solution to maintain the > SINGLE_PAIR_REQUIRED notify reception information to use it in new IKEv2 > exchange. Even the minimal implementation is required to set up the IKE SA even when the Child SA exchange in the IKE_AUTH failed: ---------------------------------------------------------------------- 1.2. The Initial Exchanges ... If creating the Child SA during the IKE_AUTH exchange fails for some reason, the IKE SA is still created as usual. ---------------------------------------------------------------------- So the IKE SA is up, but the next question is what the minimal implementation can do next. If it does not support CREATE_CHILD_SA and it does not have Child SA up, it will most likely tear down the IKE SA by sending delete notification. If it is really minimal implementation, then it most likely does not have any special handling for SINGLE_PAIR_REQUIRED, and it might not even support such traffic selectors (or they might not be allowed by policy), so most likely some kind of policy change is required before it can connect to the server. In this case the IKEv2 does not always fix mismatched policy situations automatically, and policy needs to be changed manually. I do not consider this a problem. > Instead initiator can try sending AUTH request with single traffic > selectors. If it does that, it needs to start from the beginning i.e. from IKE_SA_INIT as the previous IKE SA is already up and running, and it cannot have any more IKE_AUTH exchanges, as one of them is already finished. -- kivinen@iki.fi From sheila.frankel@nist.gov Thu Apr 22 06:53:38 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 8D50228C12D; Thu, 22 Apr 2010 06:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 BcECi3J11sWV; Thu, 22 Apr 2010 06:53:37 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 664D328C145; Thu, 22 Apr 2010 06:52:19 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o3MDnpjx011064; Thu, 22 Apr 2010 09:49:51 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 21 Apr 2010 08:46:04 -0400 From: "Frankel, Sheila E." To: "ipsec@ietf.org" , "ipv6@ietf.org" Date: Wed, 21 Apr 2010 08:45:34 -0400 Thread-Topic: Announcing the USGv6 Testing Meeting at NIST Thread-Index: Acrgnico98ik2GHIRGmPrMP7EVsXWAAsi+sg 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 Subject: [IPsec] Announcing the USGv6 Testing Meeting at NIST 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, 22 Apr 2010 13:53:38 -0000 Announcing the USGv6 Testing Meeting at NIST. To be held on Thursday May 20th 2010 in the AML Conference Room, Building 215 Room C103, from 9am till 5pm. Following publication of the USG Profile NIST has established a testing program to determine products' compliance to USGv6 capabilities. There are at present 2 accreditors and 2 accredited test laboratories enrolled in the program, with more test laboratories in consideration. July 2010 marks the date when USG Federal Agencies begin to make IT acquisitions using the USGv6 profile version 1.0. We wanted to host a public meeting to give: - a review of how the testing program is operating. - an opportunity for feedback from Stakeholders, including test laboratories, product vendors and USG Agencies. Accordingly we seek discussion inputs to include: - statements from accredited and prospective test laboratories. - statements/questions and issues from Agencies and users. - statements, questions and issues from USGv6 product vendors. Issues are expected to include: - testing operations and interlaboratory comparisons. - USGv6 capabilities and requirements. - Suppliers Declaration of Conformity. There will also be some discussion of the forthcoming USGv6 profile version 2. A full Agenda will be posted to signed up attendees closer to the day of the meeting. Due to room size limitations there can be a maximum of about 70 participants at this meeting, and attendance from any one company may need to be limited. Reply to usgv6-project@antd.nist.gov if you wish to participate, giving full name, company affiliation, title, contact details and whether you are a U.S. citizen. Please also let us know if you have issues you wish to present, with a maximum of 2 or 3 slides, and speaking time limited depending on the response. For further information, please contact Stephen Nightingale (night@nist.gov) From terry.l.davis@boeing.com Thu Apr 22 09:06: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 385103A6A14; Thu, 22 Apr 2010 09:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.998 X-Spam-Level: X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[AWL=-1.601, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, 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 IY0dG8F9KKf3; Thu, 22 Apr 2010 09:06:35 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id 9241D3A6972; Thu, 22 Apr 2010 09:06:35 -0700 (PDT) Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o3MG61aI005225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 22 Apr 2010 09:06:04 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o3MG61sP001526; Thu, 22 Apr 2010 09:06:01 -0700 (PDT) Received: from XCH-NWHT-01.nw.nos.boeing.com (xch-nwht-01.nw.nos.boeing.com [130.247.70.222]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o3MG60JV001515 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 22 Apr 2010 09:06:01 -0700 (PDT) Received: from XCH-NW-05V.nw.nos.boeing.com ([130.247.25.217]) by XCH-NWHT-01.nw.nos.boeing.com ([130.247.70.222]) with mapi; Thu, 22 Apr 2010 09:06:00 -0700 From: "Davis, Terry L" To: "'Latif LADID (\"The New Internet based on IPv6\")'" , "'Frankel, Sheila E.'" , "ipsec@ietf.org" , "ipv6@ietf.org" Date: Thu, 22 Apr 2010 09:05:59 -0700 Thread-Topic: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST Thread-Index: Acrgnico98ik2GHIRGmPrMP7EVsXWAAsi+sgADTzSyAAArx+YA== Message-ID: <0267B5481DCC474D8088BF4A25C7F1DF5516235A2A@XCH-NW-05V.nw.nos.boeing.com> References: <020601cae224$9ab391c0$d01ab540$@lu> In-Reply-To: <020601cae224$9ab391c0$d01ab540$@lu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_0267B5481DCC474D8088BF4A25C7F1DF5516235A2AXCHNW05Vnwnos_" MIME-Version: 1.0 Cc: "Whitlock, Stephen" , "ipv6ready-tech@ipv6ready.org" , "nav6tf@ipv6forum.com" , "'tim.polk@nist.gov'" Subject: Re: [IPsec] [Nav6tf] Announcing the USGv6 Testing Meeting at NIST 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, 22 Apr 2010 16:06:43 -0000 --_000_0267B5481DCC474D8088BF4A25C7F1DF5516235A2AXCHNW05Vnwnos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sheila Like Latif said, THANK YOU! As you know from the Seattle meeting with aviation industry representatives= and the vendor community last fall, the Internet security protocols' inter= operability is a key lynchpin in being able to ensure that the next generat= ion of Internet enabled aircraft can establish secure communications in the= global aviation environment. Aviation continues to be concerned that curr= ent IPv4 versions of IPsec, IKE, and IKEv2 still have vendor-to-vendor com= patibility issues that would be difficult for us to overcome in a fully het= erogeneous global environment. In our environment, an aircraft is continua= lly making and breaking security associations between different service pro= viders and air traffic management entities as it transverses from country t= o country and continent to continent. Thus our environment requires a very= high degree of confidence in the ability of our systems to dynamically re-= establish secure links with these new entities. We would encourage that interoperability testing fully include versions of = IPSec, IKE, and IKEv2 to ensure these issues do not continue with IPv6 on w= hich the next generations of global air traffic management will reply on (I= CAO Document 9896). The testing ideally should demonstrate a vendor's syst= em's ability to establish links with other vendors systems with minimal tim= e and effort for setup and link customization as the ease-of-use and ease-o= f-deployment will be critical for a global aviation infrastructure. Unfortunately I will be unable to attend as I will in ICAO meetings that we= ek, part of which will focus on these same issues. Take care Terry L Davis, P.E Boeing Technical Fellow Aircraft Network and Security, Architecture & Strategy Engineering Core - Avionics Boeing Commercial Airplanes Phone: 206-280-3716 Email: Terry.L.Davis@Boeing.com PS: It would also seem likely that the other CI sectors would have similar= IPv6 security interoperability needs. > -----Original Message----- > From: nav6tf-bounces@ipv6forum.com > [mailto:nav6tf-bounces@ipv6forum.com] On Behalf Of Latif > LADID ("The New Internet based on IPv6") > Sent: Thursday, April 22, 2010 7:04 AM > To: 'Frankel, Sheila E.'; IPSec@ietf.org; ipv6@ietf.org > Cc: ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com > Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST > > Thanks Sheila! Good to see you working on IPv6 so vigorously > recalling our > days of work on IPsec back in 99. > > I have Copied the North American v6 Task Force members and > the IPv6 Ready > logo program team. > > Cheers > Latif > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of > Frankel, Sheila E. > Sent: 21 April 2010 14:46 > To: ipsec@ietf.org; ipv6@ietf.org > Subject: Announcing the USGv6 Testing Meeting at NIST > > Announcing the USGv6 Testing Meeting at NIST. > > To be held on Thursday May 20th 2010 in the AML Conference Room, > Building 215 Room C103, from 9am till 5pm. > > Following publication of the USG Profile NIST has established > a testing > program to determine products' compliance to USGv6 > capabilities. There > are at present 2 accreditors and 2 accredited test > laboratories enrolled > in the program, with more test laboratories in consideration. > July 2010 > marks the date when USG Federal Agencies begin to make IT > acquisitions > using the USGv6 profile version 1.0. We wanted to host a > public meeting > to give: > - a review of how the testing program is operating. > - an opportunity for feedback from Stakeholders, including test > laboratories, product vendors and USG Agencies. > > Accordingly we seek discussion inputs to include: > - statements from accredited and prospective test laboratories. > - statements/questions and issues from Agencies and users. > - statements, questions and issues from USGv6 product vendors. > > Issues are expected to include: > - testing operations and interlaboratory comparisons. > - USGv6 capabilities and requirements. > - Suppliers Declaration of Conformity. > > There will also be some discussion of the forthcoming USGv6 profile > version 2. A full Agenda will be posted to signed up > attendees closer > to the day of the meeting. Due to room size limitations > there can be a > maximum of about 70 participants at this meeting, and attendance from > any one company may need to be limited. Reply to > usgv6-project@antd.nist.gov if you wish to participate, giving full > name, company affiliation, title, contact details and whether > you are a > U.S. citizen. Please also let us know if you have issues you wish to > present, with a maximum of 2 or 3 slides, and speaking time limited > depending on the response. > > For further information, please contact Stephen Nightingale > (night@nist.gov) > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > _______________________________________________ > Nav6tf mailing list > Nav6tf@ipv6forum.com > http://lists.ipv6forum.com/mailman/listinfo/nav6tf > --_000_0267B5481DCC474D8088BF4A25C7F1DF5516235A2AXCHNW05Vnwnos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sheila

Like Latif said, THANK YOU!<= BR>
As=20 you know from the Seattle meeting with aviation industry representatives an= d the=20 vendor community last fall, the Internet security protocols' interoperabili= ty is=20 a key lynchpin in being able to ensure that the next generation of Internet= =20 enabled aircraft can establish secure communications in the global aviation= =20 environment.  Aviation continues to be concerned that current IPv4 ver= sions=20 of IPsec, IKE, and IKEv2 still have  vendor-to-vendor compatibility is= sues=20 that would be difficult for us to overcome in a fully heterogeneous global= =20 environment.  In our environment, an aircraft is continually maki= ng=20 and breaking security associations between different service providers and = air=20 traffic management entities as it transverses from country to country and=20 continent to continent.  Thus our environment requires a very hig= h=20 degree of confidence in the ability of our systems to dynamically re-establ= ish=20 secure links with these new entities.

We would encourage that=20 interoperability testing fully include versions of IPSec, IKE, and IKEv2 to= =20 ensure these issues do not continue with IPv6 on which the next generations= of=20 global air traffic management will reply on (ICAO Document 9896).  The= =20 testing ideally should demonstrate a vendor's system's ability to establish= =20 links with other vendors systems with minimal time and effort for setup and= link=20 customization as the ease-of-use and ease-of-deployment will be critical fo= r a=20 global aviation infrastructure.

Unfortunately I will be unable to attend a= s I=20 will in ICAO meetings that week, part of which will focus on these sam= e=20 issues.

Take=20 care

Terry L Davis= ,=20 P.E
Boeing Technical Fellow <= /P>

Aircraft Netw= ork and=20 Security, Architecture & Strategy
Engineering Core –=20 Avionics
Boeing Commercial Airplanes

Phone: = =20 206-280-3716
Email:  =20 Terry.L.Davis@Boeing.com

PS:  It wo= uld also=20 seem likely that the other CI sectors would have similar IPv6 security=20 interoperability needs.




> -----Original=20 Message-----
> From: nav6tf-bounces@ipv6forum.com
> [mailto:nav6tf-bounces@ipv6foru= m.com]=20 On Behalf Of Latif
> LADID ("The New Internet based on IPv6")
>= =20 Sent: Thursday, April 22, 2010 7:04 AM
> To: 'Frankel, Sheila E.';=20 IPSec@ietf.org; ipv6@ietf.org
> Cc: ipv6ready-tech@ipv6ready.o= rg;=20 nav6tf@ipv6forum.com
> Subject: Re: [Nav6tf] Announcing the USGv6 Tes= ting=20 Meeting at NIST
>
> Thanks Sheila! Good to see you working on I= Pv6=20 so vigorously
> recalling our
> days of work on IPsec back in=20 99.
>
> I have Copied the North American v6 Task Force members= =20 and
> the IPv6 Ready
> logo program team.
>
>=20 Cheers
> Latif
>
> -----Original Message-----
> Fro= m:=20 ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On<= BR>>=20 Behalf Of
> Frankel, Sheila E.
> Sent: 21 April 2010 14:46
&= gt;=20 To: ipsec@ietf.org; ipv6@ietf.org
> Subject: Announcing the USGv6 Tes= ting=20 Meeting at NIST
>
> Announcing the USGv6 Testing Meeting at=20 NIST.
>
> To be held on Thursday May 20th 2010 in the AML Confe= rence=20 Room,
> Building 215 Room C103, from 9am till 5pm.
>
>=20 Following publication of the USG Profile NIST has established
> a=20 testing
> program to determine products' compliance to USGv6
>= =20 capabilities. There
> are at present 2 accreditors and 2 accredited=20 test
> laboratories enrolled
> in the program, with more test=20 laboratories in consideration.
>  July 2010
> marks the da= te=20 when USG Federal Agencies begin to make IT
> acquisitions
> usi= ng=20 the USGv6 profile version 1.0.  We wanted to host a
> public=20 meeting
> to give:
>     - a review of how = the=20 testing program is operating.
>     - an opportun= ity=20 for feedback from Stakeholders, including test
> laboratories, produc= t=20 vendors and USG Agencies.
>
> Accordingly we seek discussion in= puts=20 to include:
>     - statements from accredited an= d=20 prospective test laboratories.
>     -=20 statements/questions and issues from Agencies and=20 users.
>     - statements, questions and issues f= rom=20 USGv6 product vendors.
>
> Issues are expected to=20 include:
>     - testing operations and=20 interlaboratory comparisons.
>     - USGv6=20 capabilities and requirements.
>     - Suppliers= =20 Declaration of Conformity.
>
> There will also be some discussi= on of=20 the forthcoming USGv6 profile
> version 2.  A full Agenda will b= e=20 posted to signed up
> attendees closer
> to the day of the=20 meeting.  Due to room size limitations
> there can be a
>= =20 maximum of about 70 participants at this meeting, and attendance from
&g= t;=20 any one company may need to be limited. Reply to
>=20 usgv6-project@antd.nist.gov if you wish to participate, giving full
>= =20 name, company affiliation, title, contact details and whether
> you a= re=20 a
> U.S. citizen. Please also let us know if you have issues you wish= =20 to
> present, with a maximum of 2 or 3 slides, and speaking time=20 limited
> depending on the response.
>
> For further=20 information, please contact Stephen Nightingale
>=20 (night@nist.gov)
>
>
>=20 --------------------------------------------------------------------
>= ;=20 IETF IPv6 working group mailing list
> ipv6@ietf.org
>=20 Administrative Requests: https://www.ietf.org/ma= ilman/listinfo/ipv6
>=20 --------------------------------------------------------------------
>= ;
>=20 _______________________________________________
> Nav6tf mailing=20 list
> Nav6tf@ipv6forum.com
> http://lists.ip= v6forum.com/mailman/listinfo/nav6tf
>=20

--_000_0267B5481DCC474D8088BF4A25C7F1DF5516235A2AXCHNW05Vnwnos_-- From latif@ladid.lu Thu Apr 22 09:42:07 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 8CDC628C0EE; Thu, 22 Apr 2010 09:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.046 X-Spam-Level: X-Spam-Status: No, score=0.046 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6] 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 MLCX4h2HPEqP; Thu, 22 Apr 2010 09:42:01 -0700 (PDT) Received: from mailout4.pt.lu (mailout4.pt.lu [195.46.255.246]) by core3.amsl.com (Postfix) with ESMTP id 90D383A6900; Thu, 22 Apr 2010 09:41:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAHwZ0EvCmsBU/2dsb2JhbACBP492inJxiCK4NQKCc4IaBIZP X-IronPort-AV: E=Sophos;i="4.52,257,1270418400"; d="scan'208,217";a="51445838" Received: from webhost1.pt.lu ([194.154.192.84]) by smtp.pt.lu with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2010 18:41:47 +0200 Received: from IPv6ForumPC (ip-88-207-169-205.dyn.luxdsl.pt.lu [88.207.169.205] (may be forged)) (authenticated bits=0) by webhost1.pt.lu with ESMTP id o3MGfgFc007686; Thu, 22 Apr 2010 18:41:45 +0200 From: "Latif LADID \(\"The New Internet based on IPv6\"\)" To: "'Davis, Terry L'" , "'Frankel, Sheila E.'" , , References: <020601cae224$9ab391c0$d01ab540$@lu> <0267B5481DCC474D8088BF4A25C7F1DF5516235A2A@XCH-NW-05V.nw.nos.boeing.com> In-Reply-To: <0267B5481DCC474D8088BF4A25C7F1DF5516235A2A@XCH-NW-05V.nw.nos.boeing.com> Date: Thu, 22 Apr 2010 18:41:39 +0200 Message-ID: <027301cae23a$b1592370$140b6a50$@lu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0274_01CAE24B.74E1F370" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrgnico98ik2GHIRGmPrMP7EVsXWAAsi+sgADTzSyAAArx+YAACgoxg Content-Language: en-gb X-Seen-By: scanner3.pt.lu X-Mailman-Approved-At: Thu, 22 Apr 2010 09:59:25 -0700 Cc: "'Whitlock, Stephen'" , ipv6ready-tech@ipv6ready.org, nav6tf@ipv6forum.com, members@ipv6forum.com, tim.polk@nist.gov Subject: Re: [IPsec] [Nav6tf] Announcing the USGv6 Testing Meeting at NIST 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, 22 Apr 2010 16:42:07 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0274_01CAE24B.74E1F370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Terry, You touch a core issue of the he IPv6 Ready Logo program. The v6RL Phase II (Logo) includes IPsec interop testing. Though we have stayed away at this staged from mandating IPsec per RFC to give industry the time to put its arms around IPv6 issues first, there a dozen of products that tested IPsec succesfully: http://cf.v6pc.jp/logo_db/approved_list_ph2.php We have not yet defined Phase III which could include IPsec mandated. Now, we need to carefully define the test profiles. This needs a serious discussion before moving forward. Cheers Latif From: nav6tf-bounces@ipv6forum.com [mailto:nav6tf-bounces@ipv6forum.com] On Behalf Of Davis, Terry L Sent: 22 April 2010 18:06 To: 'Latif LADID ("The New Internet based on IPv6")'; 'Frankel, Sheila E.'; ipsec@ietf.org; ipv6@ietf.org Cc: Whitlock, Stephen; ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com; 'tim.polk@nist.gov' Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST Sheila Like Latif said, THANK YOU! As you know from the Seattle meeting with aviation industry representatives and the vendor community last fall, the Internet security protocols' interoperability is a key lynchpin in being able to ensure that the next generation of Internet enabled aircraft can establish secure communications in the global aviation environment. Aviation continues to be concerned that current IPv4 versions of IPsec, IKE, and IKEv2 still have vendor-to-vendor compatibility issues that would be difficult for us to overcome in a fully heterogeneous global environment. In our environment, an aircraft is continually making and breaking security associations between different service providers and air traffic management entities as it transverses from country to country and continent to continent. Thus our environment requires a very high degree of confidence in the ability of our systems to dynamically re-establish secure links with these new entities. We would encourage that interoperability testing fully include versions of IPSec, IKE, and IKEv2 to ensure these issues do not continue with IPv6 on which the next generations of global air traffic management will reply on (ICAO Document 9896). The testing ideally should demonstrate a vendor's system's ability to establish links with other vendors systems with minimal time and effort for setup and link customization as the ease-of-use and ease-of-deployment will be critical for a global aviation infrastructure. Unfortunately I will be unable to attend as I will in ICAO meetings that week, part of which will focus on these same issues. Take care Terry L Davis, P.E Boeing Technical Fellow Aircraft Network and Security, Architecture & Strategy Engineering Core - Avionics Boeing Commercial Airplanes Phone: 206-280-3716 Email: Terry.L.Davis@Boeing.com PS: It would also seem likely that the other CI sectors would have similar IPv6 security interoperability needs. > -----Original Message----- > From: nav6tf-bounces@ipv6forum.com > [mailto:nav6tf-bounces@ipv6forum.com] On Behalf Of Latif > LADID ("The New Internet based on IPv6") > Sent: Thursday, April 22, 2010 7:04 AM > To: 'Frankel, Sheila E.'; IPSec@ietf.org; ipv6@ietf.org > Cc: ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com > Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST > > Thanks Sheila! Good to see you working on IPv6 so vigorously > recalling our > days of work on IPsec back in 99. > > I have Copied the North American v6 Task Force members and > the IPv6 Ready > logo program team. > > Cheers > Latif > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of > Frankel, Sheila E. > Sent: 21 April 2010 14:46 > To: ipsec@ietf.org; ipv6@ietf.org > Subject: Announcing the USGv6 Testing Meeting at NIST > > Announcing the USGv6 Testing Meeting at NIST. > > To be held on Thursday May 20th 2010 in the AML Conference Room, > Building 215 Room C103, from 9am till 5pm. > > Following publication of the USG Profile NIST has established > a testing > program to determine products' compliance to USGv6 > capabilities. There > are at present 2 accreditors and 2 accredited test > laboratories enrolled > in the program, with more test laboratories in consideration. > July 2010 > marks the date when USG Federal Agencies begin to make IT > acquisitions > using the USGv6 profile version 1.0. We wanted to host a > public meeting > to give: > - a review of how the testing program is operating. > - an opportunity for feedback from Stakeholders, including test > laboratories, product vendors and USG Agencies. > > Accordingly we seek discussion inputs to include: > - statements from accredited and prospective test laboratories. > - statements/questions and issues from Agencies and users. > - statements, questions and issues from USGv6 product vendors. > > Issues are expected to include: > - testing operations and interlaboratory comparisons. > - USGv6 capabilities and requirements. > - Suppliers Declaration of Conformity. > > There will also be some discussion of the forthcoming USGv6 profile > version 2. A full Agenda will be posted to signed up > attendees closer > to the day of the meeting. Due to room size limitations > there can be a > maximum of about 70 participants at this meeting, and attendance from > any one company may need to be limited. Reply to > usgv6-project@antd.nist.gov if you wish to participate, giving full > name, company affiliation, title, contact details and whether > you are a > U.S. citizen. Please also let us know if you have issues you wish to > present, with a maximum of 2 or 3 slides, and speaking time limited > depending on the response. > > For further information, please contact Stephen Nightingale > (night@nist.gov) > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > _______________________________________________ > Nav6tf mailing list > Nav6tf@ipv6forum.com > http://lists.ipv6forum.com/mailman/listinfo/nav6tf > ------=_NextPart_000_0274_01CAE24B.74E1F370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Terry,

 

You touch a core issue of the he IPv6 Ready Logo = program.

 

The v6RL Phase II (Logo) includes IPsec interop = testing.

 

Though we have stayed away at this staged from mandating = IPsec per RFC to give industry the time to put its arms around IPv6 issues = first,

there a dozen of products that tested IPsec succesfully: =

 

http://cf.v6pc.j= p/logo_db/approved_list_ph2.php

 

We have not yet defined Phase III which could include = IPsec mandated. Now, we need to carefully define the test = profiles.

 

This needs a serious discussion before moving = forward.

 

Cheers

Latif

 

 

From: nav6tf-bounces@ipv6forum.com [mailto:nav6tf-bounces@ipv6forum.com] On Behalf Of Davis, Terry = L
Sent: 22 April 2010 18:06
To: 'Latif LADID ("The New Internet based on IPv6")'; 'Frankel, Sheila E.'; ipsec@ietf.org; ipv6@ietf.org
Cc: Whitlock, Stephen; ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com; 'tim.polk@nist.gov'
Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at = NIST

 

Sheila

Like Latif said, THANK YOU!

As you know from the Seattle meeting with aviation industry = representatives and the vendor community last fall, the Internet security protocols' interoperability is a key lynchpin in being able to ensure that the next generation of Internet enabled aircraft can establish secure = communications in the global aviation environment.  Aviation continues to be = concerned that current IPv4 versions of IPsec, IKE, and IKEv2 still have  vendor-to-vendor compatibility issues that would be difficult for us to overcome in a fully heterogeneous global environment.  In our environment, an aircraft is continually making and breaking = security associations between different service providers and air traffic management entities = as it transverses from country to country and continent to continent.  Thus our environment requires a very high degree of confidence in = the ability of our systems to dynamically re-establish secure links = with these new entities.

We would encourage that interoperability testing fully include versions = of IPSec, IKE, and IKEv2 to ensure these issues do not continue with IPv6 = on which the next generations of global air traffic management will reply on = (ICAO Document 9896).  The testing ideally should demonstrate a vendor's system's ability to establish links with other vendors systems with = minimal time and effort for setup and link customization as the ease-of-use and ease-of-deployment will be critical for a global aviation = infrastructure.

Unfortunately I will be unable to attend as I will in ICAO = meetings that week, part of which will focus on these same issues.

Take care

Terry L Davis, P.E
Boeing Technical Fellow

Aircraft Network and Security, Architecture & Strategy
Engineering Core – Avionics =
Boeing Commercial Airplanes

Phone:  206-280-3716
Email:   Terry.L.Davis@Boeing.com

PS:  It would also seem likely that the other CI sectors would = have similar IPv6 security interoperability needs.




> -----Original Message-----
> From: nav6tf-bounces@ipv6forum.com
> [mailto:nav6tf-bounces@ipv6fo= rum.com] On Behalf Of Latif
> LADID ("The New Internet based on IPv6")
> Sent: Thursday, April 22, 2010 7:04 AM
> To: 'Frankel, Sheila E.'; IPSec@ietf.org; ipv6@ietf.org
> Cc: ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com
> Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at = NIST
>
> Thanks Sheila! Good to see you working on IPv6 so vigorously
> recalling our
> days of work on IPsec back in 99.
>
> I have Copied the North American v6 Task Force members and
> the IPv6 Ready
> logo program team.
>
> Cheers
> Latif
>
> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On
> Behalf Of
> Frankel, Sheila E.
> Sent: 21 April 2010 14:46
> To: ipsec@ietf.org; ipv6@ietf.org
> Subject: Announcing the USGv6 Testing Meeting at NIST
>
> Announcing the USGv6 Testing Meeting at NIST.
>
> To be held on Thursday May 20th 2010 in the AML Conference = Room,
> Building 215 Room C103, from 9am till 5pm.
>
> Following publication of the USG Profile NIST has established
> a testing
> program to determine products' compliance to USGv6
> capabilities. There
> are at present 2 accreditors and 2 accredited test
> laboratories enrolled
> in the program, with more test laboratories in consideration.
>  July 2010
> marks the date when USG Federal Agencies begin to make IT
> acquisitions
> using the USGv6 profile version 1.0.  We wanted to host a
> public meeting
> to give:
>     - a review of how the testing program is operating.
>     - an opportunity for feedback from = Stakeholders, including test
> laboratories, product vendors and USG Agencies.
>
> Accordingly we seek discussion inputs to include:
>     - statements from accredited and = prospective test laboratories.
>     - statements/questions and issues from = Agencies and users.
>     - statements, questions and issues from = USGv6 product vendors.
>
> Issues are expected to include:
>     - testing operations and interlaboratory comparisons.
>     - USGv6 capabilities and requirements.
>     - Suppliers Declaration of Conformity.
>
> There will also be some discussion of the forthcoming USGv6 = profile
> version 2.  A full Agenda will be posted to signed up
> attendees closer
> to the day of the meeting.  Due to room size limitations
> there can be a
> maximum of about 70 participants at this meeting, and attendance = from
> any one company may need to be limited. Reply to
> usgv6-project@antd.nist.gov if you wish to participate, giving = full
> name, company affiliation, title, contact details and whether
> you are a
> U.S. citizen. Please also let us know if you have issues you wish = to
> present, with a maximum of 2 or 3 slides, and speaking time = limited
> depending on the response.
>
> For further information, please contact Stephen Nightingale
> (night@nist.gov)
>
>
> = --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/= mailman/listinfo/ipv6
> = --------------------------------------------------------------------
>
> _______________________________________________
> Nav6tf mailing list
> Nav6tf@ipv6forum.com
> http://lists.= ipv6forum.com/mailman/listinfo/nav6tf
>

------=_NextPart_000_0274_01CAE24B.74E1F370-- From wierbows@us.ibm.com Thu Apr 22 14:33: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 44B293A68F1; Thu, 22 Apr 2010 14:33:56 -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_40=-0.185, 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 p-2G0BVqxfsj; Thu, 22 Apr 2010 14:33:55 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id DDDFA3A6856; Thu, 22 Apr 2010 14:33:53 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3MLSYcL009131; Thu, 22 Apr 2010 17:28:34 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3MLXbmA173232; Thu, 22 Apr 2010 17:33:37 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3MLXaYC000509; Thu, 22 Apr 2010 18:33:36 -0300 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o3MLXaBj000500; Thu, 22 Apr 2010 18:33:36 -0300 In-Reply-To: <19400.25514.92364.300616@fireball.kivinen.iki.fi> References: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> <19389.52595.209726.960078@fireball.kivinen.iki.fi> <19400.25514.92364.300616@fireball.kivinen.iki.fi> X-KeepSent: 07C3799E:286E8226-8525770D:00754FB1; type=4; name=$KeepSent To: Tero Kivinen X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Thu, 22 Apr 2010 17:33:35 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 04/22/2010 17:33:36 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Another round of IKEv2-bis issues 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, 22 Apr 2010 21:33:56 -0000 >I think we need to mandate that logic you explained there to the RFC. >The text there does that. It says that you need to keep Child SAs and >IKE SAs connected, and either all of them work, or none of them work >(or you might also get delete notifications for those which failed, >provided the IKE SA stays up). > >What is not allowed that some of the Child SAs stay up, but the IKE SA >does not (i.e. no delete notifications). And this from the remote >point of view, i.e. if you maintain internal bookeeping and destroy >the Child SA when one security processor fails, that is fine, and from >the remote point of view all Child SAs and IKE SA got destroyed. I don't think we need to mandate how a particular situation should be handled. That is up to the implementer. The implementer just needs to know that there is a rule that states the it is not for some child SAs stay up when the IKE_SA disappears. I think the existing text could be deleted. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 From arnab.bakshi@gmail.com Thu Apr 22 22:02:23 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 7546F3A6937 for ; Thu, 22 Apr 2010 22:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RAZOR2_CHECK=0.5] 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 qb2HwnijK+bu for ; Thu, 22 Apr 2010 22:02:22 -0700 (PDT) Received: from mail-iw0-f110.google.com (mail-iw0-f110.google.com [209.85.223.110]) by core3.amsl.com (Postfix) with ESMTP id 8DCB63A6931 for ; Thu, 22 Apr 2010 22:02:22 -0700 (PDT) Received: by iwn8 with SMTP id 8so43941iwn.18 for ; Thu, 22 Apr 2010 22:02:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=IgJ8eBrdQgSkzhWOJymunfDgZyRD6yIDamcsW90gl8E=; b=Cpck6vTJREGkV8IPSc+OaI6kU4k7d62BGbsK9HX1xDDyt1qGs92z1GmzFlTgtwPprA G0IUs+B8trLS1HB0dLoTkdyd4KiFU9t33LgOoUK/3saSgWe56yRD3a+c9Z6wGo2DB4vQ cjrnl6DrkSaJ5fbQ/gwmo9qr0VqggGsHZ/fa4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=rmLw7Va0bLjENci5SkG/Tfo/XBMaT0WzaZvFPZu00W5mPsHsJ+h1i4tSq3vrnVHUG+ dhaWdHvaS3Gki0/Sfs/OgAM6Se+ix0WfpuVuqB4KUt1bH7wYOs0A5Ld27Ad2yChEaPZE BduwLNSHp9RdE8CHA1mebbxRx4B8Ecy2G0B0A= MIME-Version: 1.0 Received: by 10.231.42.163 with HTTP; Thu, 22 Apr 2010 22:02:08 -0700 (PDT) Date: Fri, 23 Apr 2010 10:32:08 +0530 Received: by 10.231.167.139 with SMTP id q11mr1053830iby.63.1271998928286; Thu, 22 Apr 2010 22:02:08 -0700 (PDT) Message-ID: From: Arnab Bakshi To: info@daffodilgroup.com, info@hrudayalaya.com, info@nimhans.kar.nic.in, info@snowvalleyresorts.com, ipsec@ietf.org, jayanandan.k@people-one.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [IPsec] kevin kin 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, 23 Apr 2010 05:02:23 -0000 http://promodelsind.com/home/index.php From kivinen@iki.fi Fri Apr 23 06:06:12 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 DE2023A6AB2 for ; Fri, 23 Apr 2010 06:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=0.474, 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 xSRUbzw8H013 for ; Fri, 23 Apr 2010 06:06:12 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id DEE8C3A6852 for ; Fri, 23 Apr 2010 05:50:02 -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 o3NCnmMO000637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Apr 2010 15:49:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3NCnk67025530; Fri, 23 Apr 2010 15:49:46 +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: <19409.38762.719146.5305@fireball.kivinen.iki.fi> Date: Fri, 23 Apr 2010 15:49:46 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> <19389.52595.209726.960078@fireball.kivinen.iki.fi> <19400.25514.92364.300616@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Another round of IKEv2-bis issues 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, 23 Apr 2010 13:06:13 -0000 David Wierbowski writes: > I don't think we need to mandate how a particular situation should be > handled. That is up to the implementer. The implementer just needs to > know that there is a rule that states the it is not for some child SAs > stay up when the IKE_SA disappears. I think the existing text could be > deleted. But the existing text is the text which gives this rule or at least try to. I.e. it tries to say that if implementation cannot guarantee that all Child SAs and IKE SAs stay up together, then you cannot negotiate all those Child SAs using the same IKE SA. This same can partially be seen from the: Receipt of a fresh cryptographically protected message on an IKE SA or any of its Child SAs ensures liveness of the IKE SA and all of its Child SAs. text, but some people might be missing the point that ALL Child SAs and corresponding IKE SAs must stay up together. -- kivinen@iki.fi From wierbows@us.ibm.com Fri Apr 23 07:14:53 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 DF6BB3A6928; Fri, 23 Apr 2010 07:14:52 -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 jOA3PtuSXO9G; Fri, 23 Apr 2010 07:14:51 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 6F5723A691B; Fri, 23 Apr 2010 07:14:34 -0700 (PDT) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3NE2Dcq004558; Fri, 23 Apr 2010 10:02:13 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3NEEHkk157810; Fri, 23 Apr 2010 10:14:17 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3NEEGCv010376; Fri, 23 Apr 2010 11:14:16 -0300 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av02.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o3NEEGsI010357; Fri, 23 Apr 2010 11:14:16 -0300 In-Reply-To: <19409.38762.719146.5305@fireball.kivinen.iki.fi> References: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> <19389.52595.209726.960078@fireball.kivinen.iki.fi> <19400.25514.92364.300616@fireball.kivinen.iki.fi> <19409.38762.719146.5305@fireball.kivinen.iki.fi> X-KeepSent: 2C6B98B2:0772F8F1-0025770E:004890F9; type=4; name=$KeepSent To: Tero Kivinen X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Fri, 23 Apr 2010 10:14:15 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 04/23/2010 10:14:15 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Another round of IKEv2-bis issues 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, 23 Apr 2010 14:14:53 -0000 >> I don't think we need to mandate how a particular situation should be >> handled. That is up to the implementer. The implementer just needs to >> know that there is a rule that states the it is not for some child SAs >> stay up when the IKE_SA disappears. I think the existing text could be >> deleted. > >But the existing text is the text which gives this rule or at least >try to. I.e. it tries to say that if implementation cannot guarantee >that all Child SAs and IKE SAs stay up together, then you cannot >negotiate all those Child SAs using the same IKE SA. > >This same can partially be seen from the: > > Receipt of a fresh cryptographically protected message on an IKE SA > or any of its Child SAs ensures liveness of the IKE SA and all of > its Child SAs. > >text, but some people might be missing the point that ALL Child SAs >and corresponding IKE SAs must stay up together. What I do not like about the text is that it is a rule related to the life of the Child SAs. I think it would be clearer to tie the rule to the termination of the IKE SA. For example I think replacing the text with some thing like the following is more straight forward: If an IKE SA fails without being able to send a delete message, then all Child SAs created by the IKE SA MUST be silently deleted. On the other hand I am not saying the existing text must be removed. I'm just saying that I think it could be removed. Dave Wierbowski z/OS Comm Server Developer Phone: Tie line: 620-4055 External: 607-429-4055 From arnab.bakshi@gmail.com Thu Apr 22 23:04:12 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 DAD563A68F9 for ; Thu, 22 Apr 2010 23:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.249, 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 V2L3DHcLGVfZ for ; Thu, 22 Apr 2010 23:04:12 -0700 (PDT) Received: from mail-iw0-f194.google.com (mail-iw0-f194.google.com [209.85.223.194]) by core3.amsl.com (Postfix) with ESMTP id 0AD8B3A6850 for ; Thu, 22 Apr 2010 23:04:11 -0700 (PDT) Received: by iwn32 with SMTP id 32so6092040iwn.18 for ; Thu, 22 Apr 2010 23:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:received :message-id:subject:to:content-type; bh=nOrPpqzfE7tI4kEqNrL6XUzufAyJm3aP5zyMi61A6GA=; b=u6BOHKnk/g8NSrrj9j3I3fKHsg5MEKp83+qdX0rHA6pUeA2WC74jlP5hECWct4qJqF 911VpI3J7jTQUshXTxfsBJOUwqjtTD2dXsy3dfRNF5nhWK9oWxy6h/ux+3MhBLNjVa+R Lq7UsM70LgoFTe/LcCWgtmI6mV4rKBR08SPBM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=fSAIp4NKoE9iNjrxE34ergxvj5Si+6B8nfpKyL5k4fQIohp2IWyq56isLglAlcUbFl n2IMV928lLz4HmWU1SOi0By4pmis/9d8tI1IrxOcssFqxK5BDpXL9fJIdUwlOsefmUXo kT67j8npeP6/xVdYPs+YF121gyIWvvswJTJMY= MIME-Version: 1.0 Received: by 10.231.42.163 with HTTP; Thu, 22 Apr 2010 23:03:31 -0700 (PDT) From: Arnab Bakshi Date: Fri, 23 Apr 2010 11:33:31 +0530 Received: by 10.231.161.132 with SMTP id r4mr754009ibx.48.1272002631144; Thu, 22 Apr 2010 23:03:51 -0700 (PDT) Message-ID: To: arnab.bakshi@gmail.com Content-Type: multipart/alternative; boundary=001636e1e8defb9d970484e13077 X-Mailman-Approved-At: Fri, 23 Apr 2010 08:26:18 -0700 Subject: [IPsec] Regarding spoofing email 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, 23 Apr 2010 06:04:13 -0000 --001636e1e8defb9d970484e13077 Content-Type: text/plain; charset=ISO-8859-1 Hi, Looks like my email address was/is used for spoofing of some disturbing/SPAM emails. I am trying to work out something for stopping this. So kindly ignore any email from me which contains any unusual subject/body which is usually present in spam mails. Thanks and Regards Arnab Bakshi --001636e1e8defb9d970484e13077 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
=A0=A0=A0 Looks like=A0my email address=A0was/is used=A0for spoofing o= f some disturbing/SPAM emails. I am trying to work out something for stoppi= ng this.
=A0
=A0=A0=A0 So kindly ignore any email from me=A0which contains any unus= ual subject/body which=A0is usually present=A0in spam mails.
=A0
Thanks and Regards
Arnab Bakshi
--001636e1e8defb9d970484e13077-- From latif@ladid.lu Thu Apr 22 10:32: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 3FC2E28C1E7; Thu, 22 Apr 2010 10:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.531 X-Spam-Level: X-Spam-Status: No, score=0.531 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6] 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 FTZkjSOAXKuj; Thu, 22 Apr 2010 10:32:27 -0700 (PDT) Received: from mailout3.pt.lu (mailout3.pt.lu [195.46.255.245]) by core3.amsl.com (Postfix) with ESMTP id 32B0A3A6886; Thu, 22 Apr 2010 10:27:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAEsj0EvCmsBU/2dsb2JhbACBP4FXjiCKcnGIIqZmkV4CgnOBLW0Ehk8 X-IronPort-AV: E=Sophos;i="4.52,258,1270418400"; d="scan'208,217";a="56253223" Received: from webhost1.pt.lu ([194.154.192.84]) by smtp.pt.lu with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Apr 2010 19:24:37 +0200 Received: from IPv6ForumPC (ip-88-207-169-205.dyn.luxdsl.pt.lu [88.207.169.205] (may be forged)) (authenticated bits=0) by webhost1.pt.lu with ESMTP id o3MHOUWS024021; Thu, 22 Apr 2010 19:24:34 +0200 From: "Latif LADID \(\"The New Internet based on IPv6\"\)" To: "'Tseronis, Peter'" , , , , References: In-Reply-To: Date: Thu, 22 Apr 2010 19:24:27 +0200 Message-ID: <02b701cae240$ac1397f0$043ac7d0$@lu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B8_01CAE251.6F9C67F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrgnico98ik2GHIRGmPrMP7EVsXWAAsi+sgADTzSyAAArx+YAACgoxgAACPvgUAAK2R8A== Content-Language: en-gb X-Seen-By: scanner3.pt.lu X-Mailman-Approved-At: Fri, 23 Apr 2010 08:26:51 -0700 Cc: stephen.whitlock@boeing.com, ipv6ready-tech@ipv6ready.org, nav6tf@ipv6forum.com, members@ipv6forum.com, tim.polk@nist.gov Subject: Re: [IPsec] [Members] [Nav6tf] Announcing the USGv6 Testing Meeting at NIST 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, 22 Apr 2010 17:32:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02B8_01CAE251.6F9C67F0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Pete, =20 This meeting is very crucial especially for vendors and to a certain = extent to ISPs, so John could publish this event (most probably already = done so) to his ARIN constituency as it=E2=80=99s Sheila=E2=80=99s = desire to get a good representation from all stakeholders. =20 It would be good to time Yanick for this meeting as she oversees all v6 = Ready & Enabled programs together with Hiroshis, Erica, Timothy, etc, = all power designers of these very technical and complex Interop = programs. =20 We have Germany coming pretty strong as well with a great event (IPv6 = Congress) May 20: http://www.heise.de/events/2010/ipv6-kongress/ =20 In terms of v6 prefix ranking the US has shot thru the roof with 450 v6 = Prefixes visible among 1230 allocated, making the US by far the largest = v6 world. I guess ARIN=E2=80=99s aggressive campaign is collecting its = fruits. Congrats. =20 Cheers Latif=20 =20 =20 From: Tseronis, Peter [mailto:Peter.Tseronis@hq.doe.gov]=20 Sent: 22 April 2010 18:47 To: 'latif@ladid.lu'; 'terry.l.davis@boeing.com'; = 'sheila.frankel@nist.gov'; 'ipsec@ietf.org'; 'ipv6@ietf.org' Cc: 'stephen.whitlock@boeing.com'; 'ipv6ready-tech@ipv6ready.org'; = 'nav6tf@ipv6forum.com'; 'members@ipv6forum.com'; 'tim.polk@nist.gov' Subject: Re: [Members] [Nav6tf] Announcing the USGv6 Testing Meeting at = NIST =20 Latif, Will you be in town for this? I will be there for sure. Yanick and I are getting together ahead of the meeting. Also, Junaid Islam, John Curran, and I are meeting on Monday. Pete=20 Peter J. Tseronis=20 Senior Advisor=20 U.S. Department of Energy=20 301-903-8262 (office)=20 202-841-5335 (mobile) =20 _____ =20 From: members-bounces@ipv6forum.com =20 To: 'Davis, Terry L' ; 'Frankel, Sheila E.' = ; ipsec@ietf.org ; = ipv6@ietf.org =20 Cc: 'Whitlock, Stephen' ; = ipv6ready-tech@ipv6ready.org ; = nav6tf@ipv6forum.com ; members@ipv6forum.com = ; tim.polk@nist.gov =20 Sent: Thu Apr 22 12:41:39 2010 Subject: Re: [Members] [Nav6tf] Announcing the USGv6 Testing Meeting at = NIST=20 Terry, =20 You touch a core issue of the he IPv6 Ready Logo program. =20 The v6RL Phase II (Logo) includes IPsec interop testing. =20 Though we have stayed away at this staged from mandating IPsec per RFC = to give industry the time to put its arms around IPv6 issues first, there a dozen of products that tested IPsec succesfully:=20 =20 http://cf.v6pc.jp/logo_db/approved_list_ph2.php =20 We have not yet defined Phase III which could include IPsec mandated. = Now, we need to carefully define the test profiles. =20 This needs a serious discussion before moving forward. =20 Cheers Latif=20 =20 =20 From: nav6tf-bounces@ipv6forum.com [mailto:nav6tf-bounces@ipv6forum.com] = On Behalf Of Davis, Terry L Sent: 22 April 2010 18:06 To: 'Latif LADID ("The New Internet based on IPv6")'; 'Frankel, Sheila = E.'; ipsec@ietf.org; ipv6@ietf.org Cc: Whitlock, Stephen; ipv6ready-tech@ipv6ready.org; = nav6tf@ipv6forum.com; 'tim.polk@nist.gov' Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST =20 Sheila Like Latif said, THANK YOU! As you know from the Seattle meeting with aviation industry = representatives and the vendor community last fall, the Internet = security protocols' interoperability is a key lynchpin in being able to = ensure that the next generation of Internet enabled aircraft can = establish secure communications in the global aviation environment. = Aviation continues to be concerned that current IPv4 versions of IPsec, = IKE, and IKEv2 still have vendor-to-vendor compatibility issues that = would be difficult for us to overcome in a fully heterogeneous global = environment. In our environment, an aircraft is continually making and = breaking security associations between different service providers and = air traffic management entities as it transverses from country to = country and continent to continent. Thus our environment requires a = very high degree of confidence in the ability of our systems to = dynamically re-establish secure links with these new entities. We would encourage that interoperability testing fully include versions = of IPSec, IKE, and IKEv2 to ensure these issues do not continue with = IPv6 on which the next generations of global air traffic management will = reply on (ICAO Document 9896). The testing ideally should demonstrate a = vendor's system's ability to establish links with other vendors systems = with minimal time and effort for setup and link customization as the = ease-of-use and ease-of-deployment will be critical for a global = aviation infrastructure. Unfortunately I will be unable to attend as I will in ICAO meetings that = week, part of which will focus on these same issues. Take care Terry L Davis, P.E=20 Boeing Technical Fellow=20 Aircraft Network and Security, Architecture & Strategy=20 Engineering Core =E2=80=93 Avionics=20 Boeing Commercial Airplanes=20 Phone: 206-280-3716=20 Email: Terry.L.Davis@Boeing.com=20 PS: It would also seem likely that the other CI sectors would have = similar IPv6 security interoperability needs. > -----Original Message----- > From: nav6tf-bounces@ipv6forum.com > [mailto:nav6tf-bounces@ipv6forum.com] On Behalf Of Latif > LADID ("The New Internet based on IPv6") > Sent: Thursday, April 22, 2010 7:04 AM > To: 'Frankel, Sheila E.'; IPSec@ietf.org; ipv6@ietf.org > Cc: ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com > Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at NIST > > Thanks Sheila! Good to see you working on IPv6 so vigorously > recalling our > days of work on IPsec back in 99. > > I have Copied the North American v6 Task Force members and > the IPv6 Ready > logo program team. > > Cheers > Latif > > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On > Behalf Of > Frankel, Sheila E. > Sent: 21 April 2010 14:46 > To: ipsec@ietf.org; ipv6@ietf.org > Subject: Announcing the USGv6 Testing Meeting at NIST > > Announcing the USGv6 Testing Meeting at NIST. > > To be held on Thursday May 20th 2010 in the AML Conference Room, > Building 215 Room C103, from 9am till 5pm. > > Following publication of the USG Profile NIST has established > a testing > program to determine products' compliance to USGv6 > capabilities. There > are at present 2 accreditors and 2 accredited test > laboratories enrolled > in the program, with more test laboratories in consideration. > July 2010 > marks the date when USG Federal Agencies begin to make IT > acquisitions > using the USGv6 profile version 1.0. We wanted to host a > public meeting > to give: > - a review of how the testing program is operating. > - an opportunity for feedback from Stakeholders, including test > laboratories, product vendors and USG Agencies. > > Accordingly we seek discussion inputs to include: > - statements from accredited and prospective test laboratories. > - statements/questions and issues from Agencies and users. > - statements, questions and issues from USGv6 product vendors. > > Issues are expected to include: > - testing operations and interlaboratory comparisons. > - USGv6 capabilities and requirements. > - Suppliers Declaration of Conformity. > > There will also be some discussion of the forthcoming USGv6 profile > version 2. A full Agenda will be posted to signed up > attendees closer > to the day of the meeting. Due to room size limitations > there can be a > maximum of about 70 participants at this meeting, and attendance from > any one company may need to be limited. Reply to > usgv6-project@antd.nist.gov if you wish to participate, giving full > name, company affiliation, title, contact details and whether > you are a > U.S. citizen. Please also let us know if you have issues you wish to > present, with a maximum of 2 or 3 slides, and speaking time limited > depending on the response. > > For further information, please contact Stephen Nightingale > (night@nist.gov) > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > _______________________________________________ > Nav6tf mailing list > Nav6tf@ipv6forum.com > http://lists.ipv6forum.com/mailman/listinfo/nav6tf >=20 ------=_NextPart_000_02B8_01CAE251.6F9C67F0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Pete,

 

This meeting is very crucial especially for vendors and = to a certain extent to ISPs, so John could publish =C2=A0this event (most = probably already done so) to his ARIN constituency as it=E2=80=99s = Sheila=E2=80=99s desire to get a good representation from all stakeholders.

 

It would be good to time Yanick for this meeting as she = oversees all v6 Ready & Enabled programs together with Hiroshis, Erica, = Timothy, etc, all power designers of these very technical and complex Interop = programs.

 

We have Germany coming pretty strong as well with a great = event (IPv6 Congress) May 20: http://www.heise.= de/events/2010/ipv6-kongress/

 

In terms of v6 prefix ranking the US has shot thru the = roof with 450 v6 Prefixes visible among 1230 allocated, making the US by far the = largest v6 world. I guess ARIN=E2=80=99s aggressive campaign is collecting its = fruits. Congrats.

 

Cheers

Latif

 

 

From: Tseronis, Peter [mailto:Peter.Tseronis@hq.doe.gov]
Sent: 22 April 2010 18:47
To: 'latif@ladid.lu'; 'terry.l.davis@boeing.com'; 'sheila.frankel@nist.gov'; 'ipsec@ietf.org'; 'ipv6@ietf.org'
Cc: 'stephen.whitlock@boeing.com'; = 'ipv6ready-tech@ipv6ready.org'; 'nav6tf@ipv6forum.com'; 'members@ipv6forum.com'; 'tim.polk@nist.gov'
Subject: Re: [Members] [Nav6tf] Announcing the USGv6 Testing = Meeting at NIST

 

Latif,

Will you be in town for this? I will be there for sure.

Yanick and I are getting together ahead of the meeting.

Also, Junaid Islam, John Curran, and I are meeting on Monday.

Pete
Peter J. Tseronis
Senior Advisor
U.S. Department of Energy
301-903-8262 (office)
202-841-5335 (mobile)

 

From: members-bounces@ipv6forum.com <members-bounces@ipv6forum.com>
To: 'Davis, Terry L' <terry.l.davis@boeing.com>; 'Frankel, = Sheila E.' <sheila.frankel@nist.gov>; ipsec@ietf.org = <ipsec@ietf.org>; ipv6@ietf.org <ipv6@ietf.org>
Cc: 'Whitlock, Stephen' <stephen.whitlock@boeing.com>; ipv6ready-tech@ipv6ready.org <ipv6ready-tech@ipv6ready.org>; nav6tf@ipv6forum.com <nav6tf@ipv6forum.com>; members@ipv6forum.com <members@ipv6forum.com>; tim.polk@nist.gov = <tim.polk@nist.gov>
Sent: Thu Apr 22 12:41:39 2010
Subject: Re: [Members] [Nav6tf] Announcing the USGv6 Testing = Meeting at NIST

Terry,

 

You touch a core issue of the he IPv6 Ready Logo = program.

 

The v6RL Phase II (Logo) includes IPsec interop = testing.

 

Though we have stayed away at this staged from mandating = IPsec per RFC to give industry the time to put its arms around IPv6 issues = first,

there a dozen of products that tested IPsec succesfully: =

 

http://cf.v6pc.j= p/logo_db/approved_list_ph2.php

 

We have not yet defined Phase III which could include = IPsec mandated. Now, we need to carefully define the test = profiles.

 

This needs a serious discussion before moving = forward.

 

Cheers

Latif

 

 

From: nav6tf-bounces@ipv6forum.com [mailto:nav6tf-bounces@ipv6forum.com] On Behalf Of Davis, Terry = L
Sent: 22 April 2010 18:06
To: 'Latif LADID ("The New Internet based on IPv6")'; 'Frankel, Sheila E.'; ipsec@ietf.org; ipv6@ietf.org
Cc: Whitlock, Stephen; ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com; 'tim.polk@nist.gov'
Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at = NIST

 

Sheila

Like Latif said, THANK YOU!

As you know from the Seattle meeting with aviation industry = representatives and the vendor community last fall, the Internet security protocols' interoperability is a key lynchpin in being able to ensure that the next generation of Internet enabled aircraft can establish secure = communications in the global aviation environment.  Aviation continues to be = concerned that current IPv4 versions of IPsec, IKE, and IKEv2 still have  vendor-to-vendor compatibility issues that would be difficult for us to overcome in a fully heterogeneous global environment.  In our environment, an aircraft is continually making and breaking = security associations between different service providers and air traffic = management entities as it transverses from country to country and continent to = continent.  Thus our environment requires a very high degree of confidence in = the ability of our systems to dynamically re-establish secure links = with these new entities.

We would encourage that interoperability testing fully include versions = of IPSec, IKE, and IKEv2 to ensure these issues do not continue with IPv6 = on which the next generations of global air traffic management will reply on = (ICAO Document 9896).  The testing ideally should demonstrate a vendor's system's ability to establish links with other vendors systems with = minimal time and effort for setup and link customization as the ease-of-use and ease-of-deployment will be critical for a global aviation = infrastructure.

Unfortunately I will be unable to attend as I will in ICAO = meetings that week, part of which will focus on these same issues.

Take care

Terry L Davis, P.E
Boeing Technical Fellow

Aircraft Network and Security, Architecture & Strategy
Engineering Core =E2=80=93 Avionics =
Boeing Commercial Airplanes

Phone:  206-280-3716
Email:   Terry.L.Davis@Boeing.com

PS:  It would also seem likely that the other CI sectors would = have similar IPv6 security interoperability needs.




> -----Original Message-----
> From: nav6tf-bounces@ipv6forum.com
> [mailto:nav6tf-bounces@ipv6fo= rum.com] On Behalf Of Latif
> LADID ("The New Internet based on IPv6")
> Sent: Thursday, April 22, 2010 7:04 AM
> To: 'Frankel, Sheila E.'; IPSec@ietf.org; ipv6@ietf.org
> Cc: ipv6ready-tech@ipv6ready.org; nav6tf@ipv6forum.com
> Subject: Re: [Nav6tf] Announcing the USGv6 Testing Meeting at = NIST
>
> Thanks Sheila! Good to see you working on IPv6 so vigorously
> recalling our
> days of work on IPsec back in 99.
>
> I have Copied the North American v6 Task Force members and
> the IPv6 Ready
> logo program team.
>
> Cheers
> Latif
>
> -----Original Message-----
> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On
> Behalf Of
> Frankel, Sheila E.
> Sent: 21 April 2010 14:46
> To: ipsec@ietf.org; ipv6@ietf.org
> Subject: Announcing the USGv6 Testing Meeting at NIST
>
> Announcing the USGv6 Testing Meeting at NIST.
>
> To be held on Thursday May 20th 2010 in the AML Conference = Room,
> Building 215 Room C103, from 9am till 5pm.
>
> Following publication of the USG Profile NIST has established
> a testing
> program to determine products' compliance to USGv6
> capabilities. There
> are at present 2 accreditors and 2 accredited test
> laboratories enrolled
> in the program, with more test laboratories in consideration.
>  July 2010
> marks the date when USG Federal Agencies begin to make IT
> acquisitions
> using the USGv6 profile version 1.0.  We wanted to host a
> public meeting
> to give:
>     - a review of how the testing program is operating.
>     - an opportunity for feedback from = Stakeholders, including test
> laboratories, product vendors and USG Agencies.
>
> Accordingly we seek discussion inputs to include:
>     - statements from accredited and = prospective test laboratories.
>     - statements/questions and issues from = Agencies and users.
>     - statements, questions and issues from = USGv6 product vendors.
>
> Issues are expected to include:
>     - testing operations and interlaboratory comparisons.
>     - USGv6 capabilities and requirements.
>     - Suppliers Declaration of Conformity.
>
> There will also be some discussion of the forthcoming USGv6 = profile
> version 2.  A full Agenda will be posted to signed up
> attendees closer
> to the day of the meeting.  Due to room size limitations
> there can be a
> maximum of about 70 participants at this meeting, and attendance = from
> any one company may need to be limited. Reply to
> usgv6-project@antd.nist.gov if you wish to participate, giving = full
> name, company affiliation, title, contact details and whether
> you are a
> U.S. citizen. Please also let us know if you have issues you wish = to
> present, with a maximum of 2 or 3 slides, and speaking time = limited
> depending on the response.
>
> For further information, please contact Stephen Nightingale
> (night@nist.gov)
>
>
> = --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/= mailman/listinfo/ipv6
> = --------------------------------------------------------------------
>
> _______________________________________________
> Nav6tf mailing list
> Nav6tf@ipv6forum.com
> http://lists.= ipv6forum.com/mailman/listinfo/nav6tf
>

------=_NextPart_000_02B8_01CAE251.6F9C67F0-- From dharkins@lounge.org Sat Apr 24 02:48:31 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 E29FC3A6AFC for ; Sat, 24 Apr 2010 02:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.058 X-Spam-Level: X-Spam-Status: No, score=-4.058 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_40=-0.185, IP_NOT_FRIENDLY=0.334, 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 vVavysqeYR1s for ; Sat, 24 Apr 2010 02:48:31 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id B7DBE28C0DE for ; Sat, 24 Apr 2010 02:48:20 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 003FC1022404C for ; Sat, 24 Apr 2010 02:48:09 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 24 Apr 2010 02:48:10 -0700 (PDT) Message-ID: Date: Sat, 24 Apr 2010 02:48:10 -0700 (PDT) From: "Dan Harkins" To: ipsec@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [IPsec] New PAKE Criteria draft posted 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: Sat, 24 Apr 2010 09:48:32 -0000 A new PAKE criteria draft has been posted to the I-D repository at: http://www.ietf.org/id/draft-harkins-ipsecme-pake-criteria-00.txt It describes a different approach to selection criteria and considerations than that provided by the other similarly-named I-D. Please take a look and comment. regards, Dan. From JArora@acmepacket.com Sat Apr 24 07:09: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 206D83A69E3 for ; Sat, 24 Apr 2010 07:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzYPczFjAp5x for ; Sat, 24 Apr 2010 07:09:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B99C13A68D3 for ; Sat, 24 Apr 2010 07:09:44 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Sat, 24 Apr 2010 10:09:33 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 24 Apr 2010 10:09:32 -0400 From: Jitender Arora To: "ipsec@ietf.org" Date: Sat, 24 Apr 2010 10:09:31 -0400 Thread-Topic: New draft posted Thread-Index: Acrjk0f2A1kTOkT3REq/aPMOZK0P7QAI7WHQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] New draft posted 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: Sat, 24 Apr 2010 14:09:48 -0000 Hi All, A new version of I-D, draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.txt= has been posted to the IETF repository. Filename: draft-arora-ipsecme-ikev2-alt-tunnel-addresses Revision: 00 Title: Alternate Tunnel Addresses for IKEv2 =20 Please take a look and comment. Regards, Jitender From yaronf.ietf@gmail.com Sat Apr 24 10:59: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 6CF103A6A92 for ; Sat, 24 Apr 2010 10:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziXxdRm3TqUm for ; Sat, 24 Apr 2010 10:59:57 -0700 (PDT) Received: from mail-bw0-f217.google.com (mail-bw0-f217.google.com [209.85.218.217]) by core3.amsl.com (Postfix) with ESMTP id F054B3A6A9B for ; Sat, 24 Apr 2010 10:59:55 -0700 (PDT) Received: by bwz9 with SMTP id 9so1000999bwz.29 for ; Sat, 24 Apr 2010 10:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=gjZkDCCbbWQHAYN4jURjQRvQw8BrRCfwKjzTC1nt7DI=; b=lz3WTGZwd0h/mqIsE03w3Kbr6K5bwJ+p/rI50zBk6XrqXtaaKkbJtLBuOOMYZJ2uQL +ee18LUxkdSN+xxRFRVHNJh6NUDbGBi2QMd3LlVXlextHe293cpXMwTmE6TYoYd9C6Pc hOi+kgfrPTBHcA5qfY8rYnYzzsUxIfqXbBF/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=Vz0Y+KQ8rUqzI3//O0K+oimpsRZFIza+KmIamGvfAAxUBx1ZlZ9Z3djPF2snRPBxNq +8SYSkOW8WvWwJKEF9JgLqzxEbn5Yt6sRlMJ0fq66bKXwFxM4rz8L7Lj63YHHjzUQG0H J8W2lasgSbkgGu/CUI13tzS9AS2mgMBON96zw= Received: by 10.102.80.5 with SMTP id d5mr952418mub.2.1272131981742; Sat, 24 Apr 2010 10:59:41 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-181-18-85.red.bezeqint.net [79.181.18.85]) by mx.google.com with ESMTPS id 23sm9474041mum.36.2010.04.24.10.59.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 24 Apr 2010 10:59:40 -0700 (PDT) From: Yaron Sheffer To: Dan Harkins In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Sat, 24 Apr 2010 20:59:33 +0300 Message-ID: <1272131973.22380.13.camel@yaronf-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] New PAKE Criteria draft posted 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: Sat, 24 Apr 2010 17:59:58 -0000 Hi everyone, I read Dan's draft and I am OK with holding the working group's discussion of alternative PAKE solutions based on this draft. In particular, I am glad that Dan proposes a way for rational analysis of the related IPR issues. Given my own involvement as a coauthor of the HUSH (EKE) draft, it will be Paul who will lead the discussion. Thanks, Yaron On Sat, 2010-04-24 at 02:48 -0700, Dan Harkins wrote: > A new PAKE criteria draft has been posted to the I-D repository at: > > http://www.ietf.org/id/draft-harkins-ipsecme-pake-criteria-00.txt > > It describes a different approach to selection criteria and considerations > than that provided by the other similarly-named I-D. > > Please take a look and comment. > > regards, > > Dan. > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Sun Apr 25 02: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 ED76E3A6951 for ; Sun, 25 Apr 2010 02:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHxw05cHipwZ for ; Sun, 25 Apr 2010 02:23:31 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 45EBB3A688B for ; Sun, 25 Apr 2010 02:22:13 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so86047fgb.13 for ; Sun, 25 Apr 2010 02:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=bP5h6wvJ0NEFoQuOr6e5X5kAcYXOKvRfCLsTdFRojBc=; b=Bc4S2j6mAGn/MGcmlpYyW2Wh2wcKce0/ZG8+EHLnddWb+i/97qBG5uzyabzJL383xu UsPgHW9GrgZiskPwW5a29Xa6KRSXvhs6BT73de/X/9hS4YdrHT1vhG9HZiUTq4RNaR5c EzoGHLSIzsTZwVB7XSFSQZ5w4oTIFGTqe74Kk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=WruCo1xS/TF6G25/+mwsAT0Wf8mAMfLGISrj3e/7WQrurhioVGo+1z6tNtAdSUkiVm sAo5l/8/h5BGMavxjWUFteJ10l6ufGV4REuZxb8Oyci+51E6IjdN7Hul6tKFRrwh3Kgj tPDkMCu1VBKao/i3KeekDLTy+Y8Gt9P47p4W0= Received: by 10.103.7.26 with SMTP id k26mr1322655mui.15.1272187318953; Sun, 25 Apr 2010 02:21:58 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-181-18-85.red.bezeqint.net [79.181.18.85]) by mx.google.com with ESMTPS id t10sm11715329muh.29.2010.04.25.02.21.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 25 Apr 2010 02:21:58 -0700 (PDT) From: Yaron Sheffer To: Jitender Arora In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Sun, 25 Apr 2010 12:21:55 +0300 Message-ID: <1272187315.22380.46.camel@yaronf-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New draft posted 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: Sun, 25 Apr 2010 09:23:33 -0000 Hi Jitender, this is certainly an interesting approach to the high-availability/load-balancing issue that we are just starting to tackle, as a group. I would appreciate your inputs to the discussion on draft-ietf-ipsecme-ipsec-ha. Below are a few initial comments on your draft: - I suggest moving Sec. 5.1 to the front (or at least pointing to it from the Introduction) so that the motivation becomes clear before the protocol details are presented. - Of course, if there are additional usage scenarios, it would be nice to include them. - Essentially ignoring the issue of NAT severely hurts the applicability of this protocol. Even saying something like "use STUN/TURN" is better than limiting the protocol to closed networks. - The security considerations never discuss the issue that the peer can now claims ownership of ANY IP address. I *think* this is just a denial-of-service issue, but it certainly needs to be analyzed. Which leads to the main issue with this proposal: - This is not just a change to IKEv2, it is a rather major change to the IPsec architecture. So I would expect some discussion of RFC 4301 entities. See the last 2 paragraphs of http://tools.ietf.org/html/rfc5685#section-3 for an example. Thanks, Yaron On Sat, 2010-04-24 at 10:09 -0400, Jitender Arora wrote: > Hi All, > > A new version of I-D, draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.txt has been posted to the IETF repository. > > Filename: draft-arora-ipsecme-ikev2-alt-tunnel-addresses > Revision: 00 > Title: Alternate Tunnel Addresses for IKEv2 > > Please take a look and comment. > > Regards, > Jitender > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Sun Apr 25 04:34:32 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 6BA233A69DD for ; Sun, 25 Apr 2010 04:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_40=-0.185, 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 HE0deypfHF2G for ; Sun, 25 Apr 2010 04:34:31 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id EF8863A69D2 for ; Sun, 25 Apr 2010 04:34:30 -0700 (PDT) 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 o3PBYEph014278; Sun, 25 Apr 2010 14:34:14 +0300 (IDT) X-CheckPoint: {4BD4367C-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 25 Apr 2010 14:34:44 +0300 From: Yoav Nir To: Yaron Sheffer Date: Sun, 25 Apr 2010 14:34:16 +0300 Thread-Topic: [IPsec] New draft posted Thread-Index: Acrka0zx6TC9ptA2SPCGubX2McRa3w== Message-ID: References: <1272187315.22380.46.camel@yaronf-linux> In-Reply-To: <1272187315.22380.46.camel@yaronf-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Jitender Arora Subject: Re: [IPsec] New draft posted 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: Sun, 25 Apr 2010 11:34:32 -0000 I agree. And whatever we may think of the particular solution, it does pres= ent a problem that can and should be in the problem statement draft. So how about adding teh following sub-section: 3.7. Different IP addresses for IKE and IPsec In many implementations there are separate IP addresses for the cluster, and for each member. While the packets protected by tunnel mode child SAs are encapsulated in IP headers with the cluster IP address, the IKE packets originate from a specific member, and carry that member's IP address. For the peer, this looks weird, as the usual thing is for the IPsec packets to come from the same IP address as the IKE packets. One obvious solution, is to use some fancy capability of the IKE host to change things so that IKE packets also come out of the cluster IP address. This can be achieved through NAT or through assigning multiple addresses to interfaces. This is not, however, possible for all implementations. [ARORA] discusses this problem in greater depth, and proposes another solution, that does involve protocol changes. On Apr 25, 2010, at 12:21 PM, Yaron Sheffer wrote: > Hi Jitender, >=20 > this is certainly an interesting approach to the > high-availability/load-balancing issue that we are just starting to > tackle, as a group. I would appreciate your inputs to the discussion on > draft-ietf-ipsecme-ipsec-ha. >=20 > Below are a few initial comments on your draft: >=20 > - I suggest moving Sec. 5.1 to the front (or at least pointing to it > from the Introduction) so that the motivation becomes clear before the > protocol details are presented. > - Of course, if there are additional usage scenarios, it would be nice > to include them. > - Essentially ignoring the issue of NAT severely hurts the applicability > of this protocol. Even saying something like "use STUN/TURN" is better > than limiting the protocol to closed networks. > - The security considerations never discuss the issue that the peer can > now claims ownership of ANY IP address. I *think* this is just a > denial-of-service issue, but it certainly needs to be analyzed. Which > leads to the main issue with this proposal: > - This is not just a change to IKEv2, it is a rather major change to the > IPsec architecture. So I would expect some discussion of RFC 4301 > entities. See the last 2 paragraphs of > http://tools.ietf.org/html/rfc5685#section-3 for an example. >=20 > Thanks, > Yaron >=20 > On Sat, 2010-04-24 at 10:09 -0400, Jitender Arora wrote: >> Hi All, >>=20 >> A new version of I-D, draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.= txt has been posted to the IETF repository. >>=20 >> Filename: draft-arora-ipsecme-ikev2-alt-tunnel-addresses >> Revision: 00 >> Title: Alternate Tunnel Addresses for IKEv2 >>=20 >> Please take a look and comment. >>=20 >> Regards, >> Jitender >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Mon Apr 26 04:20: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 908503A6B71 for ; Mon, 26 Apr 2010 04:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=-0.869, 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 Ukk8sAozKMT7 for ; Mon, 26 Apr 2010 04:19:58 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id EE73E3A6994 for ; Mon, 26 Apr 2010 04:19:52 -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 o3QBJYdi019374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Apr 2010 14:19:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3QBJXvk019632; Mon, 26 Apr 2010 14:19:33 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19413.30405.5158.838402@fireball.kivinen.iki.fi> Date: Mon, 26 Apr 2010 14:19:33 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> <19389.52595.209726.960078@fireball.kivinen.iki.fi> <19400.25514.92364.300616@fireball.kivinen.iki.fi> <19409.38762.719146.5305@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Another round of IKEv2-bis issues 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, 26 Apr 2010 11:20:00 -0000 David Wierbowski writes: > What I do not like about the text is that it is a rule related to the > life of the Child SAs. I think it would be clearer to tie the rule > to the termination of the IKE SA. For example I think replacing the > text with some thing like the following is more straight forward: > > If an IKE SA fails without being able to send a delete > message, then all Child SAs created by the IKE SA MUST be silently > deleted. Do you think it is legal to create a system where one Child SA can fail in such way that IKE SA cannot send delete notification? The current text says it is not legal, but your replacement text allows it. I do not think such setup should be allowed. I.e. if any of the Child SAs or the associated IKE SA fail, in such way that delete notification cannot be sent, then all the Child SAs AND the IKE SA needs to be destroyed. -- kivinen@iki.fi From kivinen@iki.fi Mon Apr 26 04:29: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 45F623A6984 for ; Mon, 26 Apr 2010 04:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.503, 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 t9mghGJexX0f for ; Mon, 26 Apr 2010 04:29:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E6C3D3A6B81 for ; Mon, 26 Apr 2010 04:29:40 -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 o3QBTGNe021683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Apr 2010 14:29:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3QBTFWc014492; Mon, 26 Apr 2010 14:29:15 +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: <19413.30987.504756.15413@fireball.kivinen.iki.fi> Date: Mon, 26 Apr 2010 14:29:15 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <1272187315.22380.46.camel@yaronf-linux> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min Cc: "ipsec@ietf.org" , Jitender Arora Subject: Re: [IPsec] New draft posted 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, 26 Apr 2010 11:29:56 -0000 Yoav Nir writes: > I agree. And whatever we may think of the particular solution, it does present a problem that can and should be in the problem statement draft. > > So how about adding teh following sub-section: > > 3.7. Different IP addresses for IKE and IPsec > > In many implementations there are separate IP addresses for the > cluster, and for each member. While the packets protected by tunnel > mode child SAs are encapsulated in IP headers with the cluster IP > address, the IKE packets originate from a specific member, and carry > that member's IP address. For the peer, this looks weird, as the > usual thing is for the IPsec packets to come from the same IP address > as the IKE packets. Normally all ESP packets also have the members IP address as their outer address, so there is no problem. Both IKE and ESP packets have same address (provided the IKE and Child SAs are located on the same cluster member). If the ESP packets have special handling that will change their outer source address to match cluster's IP address instead of individual member's IP address, then the same mechanims can easily be used for IKE SA too. > One obvious solution, is to use some fancy capability of the IKE host > to change things so that IKE packets also come out of the cluster IP > address. This can be achieved through NAT or through assigning > multiple addresses to interfaces. This is not, however, possible for > all implementations. I would expect this to be one of those very basic systems provided by the cluster, so if cluster implementationdoes not offer such setup, then it most likely does not offer that for Child SAs either, thus there is no problem, as both ESP and IKE will use same IP (i.e. member's own IP). We already have standard track mechanims for updating the outer address for both Child SAs and IKE (MOBIKE), so even when the cluster's outer IP address is used in normal case, the failover to another cluster member (using different IP address) is easy to do provided both the cluster member's share the same SA state. -- kivinen@iki.fi From ynir@checkpoint.com Mon Apr 26 04:56: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 067FC3A6984 for ; Mon, 26 Apr 2010 04:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=-0.627, BAYES_50=0.001, 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 m9uEQ1MzEFNZ for ; Mon, 26 Apr 2010 04:56:47 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 8E7F93A6994 for ; Mon, 26 Apr 2010 04:56:42 -0700 (PDT) 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 o3QBuGph013326; Mon, 26 Apr 2010 14:56:16 +0300 (IDT) X-CheckPoint: {4BD58D1B-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 26 Apr 2010 14:56:46 +0300 From: Yoav Nir To: Tero Kivinen Date: Mon, 26 Apr 2010 14:56:16 +0300 Thread-Topic: [IPsec] New draft posted Thread-Index: AcrlN4rfCGCCpQ16R5OcUDpGKgtP/w== Message-ID: <97C2EE5B-BF5C-4037-955F-16B6894294B1@checkpoint.com> References: <1272187315.22380.46.camel@yaronf-linux> <19413.30987.504756.15413@fireball.kivinen.iki.fi> In-Reply-To: <19413.30987.504756.15413@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Jitender Arora Subject: Re: [IPsec] New draft posted 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, 26 Apr 2010 11:56:48 -0000 This is why we need multiple vendors to look at this draft. On Apr 26, 2010, at 2:29 PM, Tero Kivinen wrote: > Yoav Nir writes: >> I agree. And whatever we may think of the particular solution, it does p= resent a problem that can and should be in the problem statement draft. >>=20 >> So how about adding teh following sub-section: >>=20 >> 3.7. Different IP addresses for IKE and IPsec >>=20 >> In many implementations there are separate IP addresses for the >> cluster, and for each member. While the packets protected by tunnel >> mode child SAs are encapsulated in IP headers with the cluster IP >> address, the IKE packets originate from a specific member, and carry >> that member's IP address. For the peer, this looks weird, as the >> usual thing is for the IPsec packets to come from the same IP address >> as the IKE packets. >=20 > Normally all ESP packets also have the members IP address as their > outer address, so there is no problem. Both IKE and ESP packets have > same address (provided the IKE and Child SAs are located on the same > cluster member). Actually, in our implementation, all packets (IKE and ESP) have the cluster= IP address, so the peer doesn't notice a failover, and also the peer can't= tell which member is "active" or which member it is working with. > If the ESP packets have special handling that will change their outer > source address to match cluster's IP address instead of individual > member's IP address, then the same mechanims can easily be used for > IKE SA too. Not really. The IPsec stack constructs the ESP header and encapsulating IP = header for tunnel mode SAs. It can put whatever external IP address it want= s in there. IKE is handled by a user space process that opens a regular UDP= socket and sends packets. To get those packets to have the cluster IP addr= ess, we need some special OS feature that allows you to override the IP sta= ck, or a NAT mechanism to change the packets. >=20 >> One obvious solution, is to use some fancy capability of the IKE host >> to change things so that IKE packets also come out of the cluster IP >> address. This can be achieved through NAT or through assigning >> multiple addresses to interfaces. This is not, however, possible for >> all implementations. >=20 > I would expect this to be one of those very basic systems provided by > the cluster, so if cluster implementationdoes not offer such setup, > then it most likely does not offer that for Child SAs either, thus > there is no problem, as both ESP and IKE will use same IP (i.e. > member's own IP).=20 Again, for ESP, your code constructs the external source IP address, or it = is a property of the child SA that the IKE process created. >=20 > We already have standard track mechanims for updating the outer > address for both Child SAs and IKE (MOBIKE), so even when the > cluster's outer IP address is used in normal case, the failover to > another cluster member (using different IP address) is easy to do > provided both the cluster member's share the same SA state. MOBIKE was intended for mobile clients such as laptops and phones. It would= be weird to use that for the enterprise gateway that uses clustering to im= prove scalability or availability. But in any case, at the moment we are on= ly dealing with a problem statement. Solutions are yet to come. From kivinen@iki.fi Mon Apr 26 05:57: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 EDB943A6B9B for ; Mon, 26 Apr 2010 05:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, 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 zEcx808JrLT2 for ; Mon, 26 Apr 2010 05:57:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AA2CF3A6922 for ; Mon, 26 Apr 2010 05:57:24 -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 o3QCuuNr020786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Apr 2010 15:56:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3QCutEb025308; Mon, 26 Apr 2010 15:56:55 +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: <19413.36247.180750.847872@fireball.kivinen.iki.fi> Date: Mon, 26 Apr 2010 15:56:55 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <97C2EE5B-BF5C-4037-955F-16B6894294B1@checkpoint.com> References: <1272187315.22380.46.camel@yaronf-linux> <19413.30987.504756.15413@fireball.kivinen.iki.fi> <97C2EE5B-BF5C-4037-955F-16B6894294B1@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: "ipsec@ietf.org" , Jitender Arora Subject: Re: [IPsec] New draft posted 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, 26 Apr 2010 12:57:26 -0000 Yoav Nir writes: > Actually, in our implementation, all packets (IKE and ESP) have the > cluster IP address, so the peer doesn't notice a failover, and also > the peer can't tell which member is "active" or which member it is > working with. Yes, that is also one way doing it, but in that case there is no problem, as IKE and ESP uses same address. > > If the ESP packets have special handling that will change their outer > > source address to match cluster's IP address instead of individual > > member's IP address, then the same mechanims can easily be used for > > IKE SA too. > > Not really. The IPsec stack constructs the ESP header and > encapsulating IP header for tunnel mode SAs. It can put whatever > external IP address it wants in there. IKE is handled by a user > space process that opens a regular UDP socket and sends packets. To > get those packets to have the cluster IP address, we need some > special OS feature that allows you to override the IP stack, or a > NAT mechanism to change the packets. In userspace you can still use the normal bind operation to bind the source IP to specific IP address. You do not need special OS features, those features are usually present in most of the operating systems available, so you just need standard OS features... > > We already have standard track mechanims for updating the outer > > address for both Child SAs and IKE (MOBIKE), so even when the > > cluster's outer IP address is used in normal case, the failover to > > another cluster member (using different IP address) is easy to do > > provided both the cluster member's share the same SA state. > > MOBIKE was intended for mobile clients such as laptops and phones. That is one use. Another use for for gateways to provide high-availability when you have multiple connections to the internet, i.e. multiple ISPs. > It would be weird to use that for the enterprise gateway that uses > clustering to improve scalability or availability. I would expect to see it in all environments where the gateway supports redundant intenet connections, i.e. same box has two connections to the internet using different ISPs (and of course using completely different IP-addresses). > But in any case, at the moment we are only dealing with a problem > statement. Solutions are yet to come. I have not read the draft you mentioned, but I assumed it was also solution document, not problem statement document. I do not know how it relates to MOBIKE, or to anything else, but I think MOBIKE is one of the solutions we are going to be using where it is applicable. -- kivinen@iki.fi From wierbows@us.ibm.com Mon Apr 26 06:25: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 266F328C16B; Mon, 26 Apr 2010 06:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.267 X-Spam-Level: X-Spam-Status: No, score=-5.267 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_20=-0.74, 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 c5OXNEqM1-ET; Mon, 26 Apr 2010 06:25:11 -0700 (PDT) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id B87C23A6A8F; Mon, 26 Apr 2010 06:23:10 -0700 (PDT) Received: from d01relay01.pok.ibm.com (d01relay01.pok.ibm.com [9.56.227.233]) by e4.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3QDAh2E025104; Mon, 26 Apr 2010 09:10:43 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay01.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3QDMoiV125516; Mon, 26 Apr 2010 09:22:50 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3QDMobL032553; Mon, 26 Apr 2010 10:22:50 -0300 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o3QDMo64032412; Mon, 26 Apr 2010 10:22:50 -0300 In-Reply-To: <19413.30405.5158.838402@fireball.kivinen.iki.fi> References: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> <19389.52595.209726.960078@fireball.kivinen.iki.fi> <19400.25514.92364.300616@fireball.kivinen.iki.fi> <19409.38762.719146.5305@fireball.kivinen.iki.fi> <19413.30405.5158.838402@fireball.kivinen.iki.fi> X-KeepSent: 0F6264F9:FAD2B467-85257711:0047B610; type=4; name=$KeepSent To: Tero Kivinen X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Mon, 26 Apr 2010 09:22:44 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 04/26/2010 09:22:49 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Another round of IKEv2-bis issues 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, 26 Apr 2010 13:25:13 -0000 >Do you think it is legal to create a system where one Child SA can >fail in such way that IKE SA cannot send delete notification? I do not think a robust IKE implementation would allow this. > >The current text says it is not legal, but your replacement text >allows it. The current bis text is: If a system creates Child SAs that can fail independently from one another without the associated IKE SA being able to send a delete message, then the system MUST negotiate such Child SAs using separate IKE SAs. This text also does not prevent the above. It just says how the children can be created. It says nothing about what happens when they fail. > >I do not think such setup should be allowed. I.e. if any of the Child >SAs or the associated IKE SA fail, in such way that delete >notification cannot be sent, then all the Child SAs AND the IKE SA >needs to be destroyed. Then say that. Say if a Child SA fails and a delete notification cannot be sent then the IKE SA must be deleted. Personally I think you change how you interpret the sentence each time you respond which just echoes Paul's original point, that the text is not clear. Dave Wierbowski From yaronf.ietf@gmail.com Mon Apr 26 07:49:11 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 1244B3A6C4F for ; Mon, 26 Apr 2010 07:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 RAuSM7e1jN9v for ; Mon, 26 Apr 2010 07:49:10 -0700 (PDT) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by core3.amsl.com (Postfix) with ESMTP id 0879C28C287 for ; Mon, 26 Apr 2010 07:27:58 -0700 (PDT) Received: by ewy24 with SMTP id 24so3595271ewy.13 for ; Mon, 26 Apr 2010 07:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=1b1i45EMJmnuYAnF+eoO+HVtb0cgSNlrsPA7IMTTJcY=; b=N4Y6krpdZOW3cTOybtHWUZbP4u+dRl1nsW7RqjXaDrRF4dMVz3HWWY3BZTX5Ria9Ua mMOdi/vS3ihewt7br/MgCU3ti2YGsCL7WgjUSZR9hMuNxxnrVyjX30KUpS9/1DP/bUkN S2mOFqkqa5GwBHpY8z4Ug6csd4msUlWN6G6To= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; b=s8booRZBYRXAdjE4PxOeKm4qyrYGg7bzLoHmYf0pU+t3Nk/8n0LK/owX+mfnnaHaTT JZAHChj05NpkwitwTWu2Wth84t3H6OkSkOVxXpcSWoMPRqPJLfXPVmVWDUmr4dkwUZx+ qEBrIdaOAZ/dXloouCul8GG257FTP5gLMCoJE= Received: by 10.103.66.9 with SMTP id t9mr2347367muk.73.1272292062724; Mon, 26 Apr 2010 07:27:42 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-181-18-85.red.bezeqint.net [79.181.18.85]) by mx.google.com with ESMTPS id w5sm17343354mue.54.2010.04.26.07.27.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 26 Apr 2010 07:27:42 -0700 (PDT) From: Yaron Sheffer To: ipsec In-Reply-To: <1271864821.6636.55.camel@yaronf-linux> References: <1271864821.6636.55.camel@yaronf-linux> Content-Type: text/plain; charset="UTF-8" Date: Mon, 26 Apr 2010 17:27:39 +0300 Message-ID: <1272292059.2347.12.camel@yaronf-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] IPsec HA problem statement 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, 26 Apr 2010 14:49:11 -0000 Hi, There has been very little follow-on discussion on this draft, just a few mails related to one proposed solution. So if you've read the draft and think it's complete and good to go into WGLC, let us all know. If some things are still missing, tell us which. Different vendors have different views, and Yoav's problem statement may not cover them all. Thanks, Yaron On Wed, 2010-04-21 at 18:47 +0300, Yaron Sheffer wrote: > Hi, > > we've had a useful discussion on HA terminology, and Yoav published a > new version of the draft: > http://tools.ietf.org/html/draft-ietf-ipsecme-ipsec-ha-02. > > We'd like to move it forward ASAP so we can get into the fun protocol > stuff. So, before we go into WG LC, I'd like to have the group's inputs > on the completeness of the draft: are we missing anything that'll come > back to bite us as we discuss the protocol? > > Thanks, > Yaron From JArora@acmepacket.com Mon Apr 26 19:23: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 D3C3E3A685B for ; Mon, 26 Apr 2010 19:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 JHD5V3F-UwHF for ; Mon, 26 Apr 2010 19:23:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 56ED63A68DB for ; Mon, 26 Apr 2010 19:23:55 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Apr 2010 22:23:41 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 26 Apr 2010 22:23:40 -0400 From: Jitender Arora To: Yaron Sheffer Date: Mon, 26 Apr 2010 22:23:35 -0400 Thread-Topic: [IPsec] New draft posted Thread-Index: AcrkWM944O1yRC7DREmah50QGGEHTgBVpHgQ Message-ID: References: <1272187315.22380.46.camel@yaronf-linux> In-Reply-To: <1272187315.22380.46.camel@yaronf-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New draft posted 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, 27 Apr 2010 02:23:57 -0000 Hi Yaron, Thanks for the feedback. I will definitely read the draft-ietf-ipsecme= -ipsec-ha and will get back to you. Here are my answers to your suggestions: 1. I will point the section 5.1 in the introduction itself that way the pu= rpose and applications of the draft are clear. 2. We did discuss the NAT scenarios and were of the opinion that if we tak= e care of the NAT scenario's then it will change the IKEv2 protocol in a ma= jor way. Here is how we were planning to solve the NAT issues: We were thinking that once the IKE_AUTH exchange is completed and the diffe= rent tunnel addresses are specified by the VPN client or the Gateway, each = side can send the informational IKEv2 message containing the NAT_DETECTION_= SOURCE_IP and the NAT_DETECTION_DESTINATION_IP payloads (they will have to = send this informational message using the tunnel addresses as the IKEv2 pee= r addresses) to see if there are NAT devices between them or not. If they d= etermine that there is a NAT device, they can always use NAT addresses as t= he tunnel address. Using this approach the client or the gateway can determine whether there i= s a NAT device in the ESP traffic path or not. But using this approach requ= ires that the Client and the gateway also to be able to listen for the IKE = packets on the tunnel addresses and also these IKE packets will be protecte= d by the IKE-SA negotiated on the IKE addresses. So this will require a lot of changes in the current implementation, but th= is is certainly possible. 3. The tunnel addresses are negotiated during the IKE-AUTH or the CREATE_CH= ILD_SA exchanges. These exchanges are protected using the IKE-SA and also t= he users are being authenticated by each side before the tunnel addresses a= re accepted. So once the users are authenticated, the Security Associations= will be setup using the tunnel addresses as the tunnel src and the tunnel = destination addresses, so the traffic will protected using these SA's. Shou= ld not this be enough for the case you mentioned below?=20 Also as in our case all the IKEv2 signaling will be handled by the same gat= eway (load balancer will just act as a pass-through for IKEv2 traffic and w= ill just choose the gateway), so I am not sure how the sections you mention= ed in the RFC 5685 will be applicable. Thanks, Jitender -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 Sent: Sunday, April 25, 2010 5:22 AM To: Jitender Arora Cc: ipsec@ietf.org Subject: Re: [IPsec] New draft posted Hi Jitender, this is certainly an interesting approach to the high-availability/load-balancing issue that we are just starting to tackle, as a group. I would appreciate your inputs to the discussion on draft-ietf-ipsecme-ipsec-ha. Below are a few initial comments on your draft: - I suggest moving Sec. 5.1 to the front (or at least pointing to it from the Introduction) so that the motivation becomes clear before the protocol details are presented. - Of course, if there are additional usage scenarios, it would be nice to include them. - Essentially ignoring the issue of NAT severely hurts the applicability of this protocol. Even saying something like "use STUN/TURN" is better than limiting the protocol to closed networks. - The security considerations never discuss the issue that the peer can now claims ownership of ANY IP address. I *think* this is just a denial-of-service issue, but it certainly needs to be analyzed. Which leads to the main issue with this proposal: - This is not just a change to IKEv2, it is a rather major change to the IPsec architecture. So I would expect some discussion of RFC 4301 entities. See the last 2 paragraphs of http://tools.ietf.org/html/rfc5685#section-3 for an example. Thanks, Yaron On Sat, 2010-04-24 at 10:09 -0400, Jitender Arora wrote: > Hi All, >=20 > A new version of I-D, draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.t= xt has been posted to the IETF repository. >=20 > Filename: draft-arora-ipsecme-ikev2-alt-tunnel-addresses > Revision: 00 > Title: Alternate Tunnel Addresses for IKEv2 > =20 > Please take a look and comment. >=20 > Regards, > Jitender > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From kivinen@iki.fi Tue Apr 27 04:09: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 A6D1C3A6963; Tue, 27 Apr 2010 04:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.868 X-Spam-Level: X-Spam-Status: No, score=-0.868 tagged_above=-999 required=5 tests=[AWL=-0.869, 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 xHnIXFsqlzSL; Tue, 27 Apr 2010 04:09:41 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 122293A68ED; Tue, 27 Apr 2010 04:09: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 o3RB9H8t011372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 14:09:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3RB9F4L026016; Tue, 27 Apr 2010 14:09:15 +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: <19414.50651.777449.313125@fireball.kivinen.iki.fi> Date: Tue, 27 Apr 2010 14:09:15 +0300 From: Tero Kivinen To: David Wierbowski In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> <19389.52595.209726.960078@fireball.kivinen.iki.fi> <19400.25514.92364.300616@fireball.kivinen.iki.fi> <19409.38762.719146.5305@fireball.kivinen.iki.fi> <19413.30405.5158.838402@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Another round of IKEv2-bis issues 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, 27 Apr 2010 11:09:47 -0000 David Wierbowski writes: > >Do you think it is legal to create a system where one Child SA can > >fail in such way that IKE SA cannot send delete notification? > > I do not think a robust IKE implementation would allow this. I agree, and the current text says you cannot do that (i.e. it says taht if that is possible, you need to create Child SAs with separate IKE SAs). > >The current text says it is not legal, but your replacement text > >allows it. > > The current bis text is: > If a system creates Child SAs that can fail independently from one > another without the associated IKE SA being able to send a delete > message, then the system MUST negotiate such Child SAs using separate > IKE SAs. > > This text also does not prevent the above. It just says how the > children can be created. It says nothing about what happens when > they fail. It says that you are not allowed to do that, you MUST create such Child SAs on separate IKE SAs. Meaning that if you follow that MUST, then the Child SAs cannot fail independently from one another without the associated IKE SA being able to send a delete notification. I.e you must group IKE SA and the Child SAs in such way that they cannot fail independently. In worst case you need to create one IKE SA for one Child SAs. > >I do not think such setup should be allowed. I.e. if any of the Child > >SAs or the associated IKE SA fail, in such way that delete > >notification cannot be sent, then all the Child SAs AND the IKE SA > >needs to be destroyed. > > Then say that. Say if a Child SA fails and a delete notification > cannot be sent then the IKE SA must be deleted. Personally I think > you change how you interpret the sentence each time you respond which > just echoes Paul's original point, that the text is not clear. I am not changing the way I interpret the sentence, I am trying to explain to you that the current text provides solution for different cases, and covers lots of cases. I agree it might not be clear for some people, but I have not seen any better way to say the same text which would cover all the cases behind the original text. If you can provide such exact text, then we can look at that. I have not yet seen such text, meaning the current text is best we have now. I do not want the current text to be removed just because some people think it is not clear as for me it is clear enough and it is something that needs to be mentioned, and I have not seen better text to replace it. -- kivinen@iki.fi From kivinen@iki.fi Tue Apr 27 04:20: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 3E1C03A6896 for ; Tue, 27 Apr 2010 04:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[AWL=0.489, 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 FEanj2B-zzIV for ; Tue, 27 Apr 2010 04:20:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 832103A6918 for ; Tue, 27 Apr 2010 04:20:10 -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 o3RBJqZ0010690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Apr 2010 14:19:52 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3RBJpDo024898; Tue, 27 Apr 2010 14:19:51 +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: <19414.51287.786283.875147@fireball.kivinen.iki.fi> Date: Tue, 27 Apr 2010 14:19:51 +0300 From: Tero Kivinen To: Jitender Arora In-Reply-To: References: <1272187315.22380.46.camel@yaronf-linux> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New draft posted 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, 27 Apr 2010 11:20:48 -0000 Jitender Arora writes: > 1. I will point the section 5.1 in the introduction itself that way > the purpose and applications of the draft are clear. After I read the section 5.1 (I skipped most of the other draft as I needed to know first WHY this is needed before I care about HOW it is implemented), and I do not really see enough text there to cause me to read the HOW part. So I would need better and more text about WHY this extension is needed. Why it is important that the IKEv2 SA and Child SA uses different outer addresses? Who is supposed to terminate the IKEv2 SA and who is supposed to terminate the Child SAs. Is this assuming that IKEv2 SA and Child SA are still on the same machine or what? If so, why not just use the IP address of that host for both IKEv2 SA and Child SA? So I think the usage scenarios (WHY part) is much more important than the actual protocol (HOW part), and it should be clear from the beginning. Currently this draft mostly assumes there is problem, but it does not explain why you think the problem actually exists or what the problem is. -- kivinen@iki.fi From yaronf.ietf@gmail.com Tue Apr 27 05:27: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 BED8A3A6968 for ; Tue, 27 Apr 2010 05:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 E4210InMwhPv for ; Tue, 27 Apr 2010 05:27:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 4CAAC3A672E for ; Tue, 27 Apr 2010 05:27:29 -0700 (PDT) Received: by wyb35 with SMTP id 35so3568554wyb.31 for ; Tue, 27 Apr 2010 05:27:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=b8+qNgleZb5nQdZWAesR1Zcd3w5dVDeD/U+3t0AEnR8=; b=P7nFSO+cmUXD6GxbS8sSJwJ2mcZpWxZTTiFHefpMk+XgIm7xdfLsQtDp+4Wbt0YghN Dy2PKi7SJCm9UyGibz+v4pfknARQ8FZ9Ze3JBCm7n5OuhG+AUgLjh83k8xqY3Kzx9CYs hUV1g0wYp5Ez2CH6SgC2QDzSq7RBkLlv8U8fk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=hCuZSYUpFOK4E/GG7zULhS/t1m2MblrQr4N6ksVhp8fck/iitHNG5kl73yLiQ4nL7f DbmPaEpwph6A3pqMQ+Xs8hmNt3I29E5ju+BdYKLX3K9c37bkgAttWjZJAjKXiZfV1UrL Z+MtUXTX+WdeUv+C9A3FH5LYTFj++0KCjwVaw= Received: by 10.216.85.203 with SMTP id u53mr5006739wee.184.1272371233525; Tue, 27 Apr 2010 05:27:13 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-181-18-85.red.bezeqint.net [79.181.18.85]) by mx.google.com with ESMTPS id z34sm5212447wbv.14.2010.04.27.05.27.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Apr 2010 05:27:13 -0700 (PDT) From: Yaron Sheffer To: Jitender Arora In-Reply-To: References: <1272187315.22380.46.camel@yaronf-linux> Content-Type: text/plain; charset="UTF-8" Date: Tue, 27 Apr 2010 15:27:09 +0300 Message-ID: <1272371229.2347.87.camel@yaronf-linux> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New draft posted 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, 27 Apr 2010 12:27:33 -0000 Hi Jitender, regarding your point #3: I am not sure that if I trust a gateway to connect to, I also trust it to say that all ESP traffic from an arbitrary IP address should be treated as a Child SA of this gateway. I cannot see a concrete attack based on this assumption, but it can surely result in interesting configuration issues. Just think of two IKE gateways that (possibly because of misconfiguration) share one IPsec box. Thanks, Yaron On Mon, 2010-04-26 at 22:23 -0400, Jitender Arora wrote: > Hi Yaron, > > Thanks for the feedback. I will definitely read the draft-ietf-ipsecme-ipsec-ha and will get back to you. > > Here are my answers to your suggestions: > > 1. I will point the section 5.1 in the introduction itself that way the purpose and applications of the draft are clear. > > 2. We did discuss the NAT scenarios and were of the opinion that if we take care of the NAT scenario's then it will change the IKEv2 protocol in a major way. > > Here is how we were planning to solve the NAT issues: > > We were thinking that once the IKE_AUTH exchange is completed and the different tunnel addresses are specified by the VPN client or the Gateway, each side can send the informational IKEv2 message containing the NAT_DETECTION_SOURCE_IP and the NAT_DETECTION_DESTINATION_IP payloads (they will have to send this informational message using the tunnel addresses as the IKEv2 peer addresses) to see if there are NAT devices between them or not. If they determine that there is a NAT device, they can always use NAT addresses as the tunnel address. > > Using this approach the client or the gateway can determine whether there is a NAT device in the ESP traffic path or not. But using this approach requires that the Client and the gateway also to be able to listen for the IKE packets on the tunnel addresses and also these IKE packets will be protected by the IKE-SA negotiated on the IKE addresses. > > So this will require a lot of changes in the current implementation, but this is certainly possible. > 3. The tunnel addresses are negotiated during the IKE-AUTH or the CREATE_CHILD_SA exchanges. These exchanges are protected using the IKE-SA and also the users are being authenticated by each side before the tunnel addresses are accepted. So once the users are authenticated, the Security Associations will be setup using the tunnel addresses as the tunnel src and the tunnel destination addresses, so the traffic will protected using these SA's. Should not this be enough for the case you mentioned below? > > Also as in our case all the IKEv2 signaling will be handled by the same gateway (load balancer will just act as a pass-through for IKEv2 traffic and will just choose the gateway), so I am not sure how the sections you mentioned in the RFC 5685 will be applicable. > > Thanks, > Jitender > > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Sunday, April 25, 2010 5:22 AM > To: Jitender Arora > Cc: ipsec@ietf.org > Subject: Re: [IPsec] New draft posted > > Hi Jitender, > > this is certainly an interesting approach to the > high-availability/load-balancing issue that we are just starting to > tackle, as a group. I would appreciate your inputs to the discussion on > draft-ietf-ipsecme-ipsec-ha. > > Below are a few initial comments on your draft: > > - I suggest moving Sec. 5.1 to the front (or at least pointing to it > from the Introduction) so that the motivation becomes clear before the > protocol details are presented. > - Of course, if there are additional usage scenarios, it would be nice > to include them. > - Essentially ignoring the issue of NAT severely hurts the applicability > of this protocol. Even saying something like "use STUN/TURN" is better > than limiting the protocol to closed networks. > - The security considerations never discuss the issue that the peer can > now claims ownership of ANY IP address. I *think* this is just a > denial-of-service issue, but it certainly needs to be analyzed. Which > leads to the main issue with this proposal: > - This is not just a change to IKEv2, it is a rather major change to the > IPsec architecture. So I would expect some discussion of RFC 4301 > entities. See the last 2 paragraphs of > http://tools.ietf.org/html/rfc5685#section-3 for an example. > > Thanks, > Yaron > > On Sat, 2010-04-24 at 10:09 -0400, Jitender Arora wrote: > > Hi All, > > > > A new version of I-D, draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00.txt has been posted to the IETF repository. > > > > Filename: draft-arora-ipsecme-ikev2-alt-tunnel-addresses > > Revision: 00 > > Title: Alternate Tunnel Addresses for IKEv2 > > > > Please take a look and comment. > > > > Regards, > > Jitender > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > From ynir@checkpoint.com Tue Apr 27 06:18:15 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 2CEBD3A69CE for ; Tue, 27 Apr 2010 06:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.891 X-Spam-Level: X-Spam-Status: No, score=-2.891 tagged_above=-999 required=5 tests=[AWL=0.708, 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 k-KjD-i-Wh+Q for ; Tue, 27 Apr 2010 06:18:13 -0700 (PDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id EAC5A3A6880 for ; Tue, 27 Apr 2010 06:18:08 -0700 (PDT) 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 o3RDHeph021045; Tue, 27 Apr 2010 16:17:41 +0300 (IDT) X-CheckPoint: {4BD6F1A4-0-1B201DC2-2FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 27 Apr 2010 16:18:10 +0300 From: Yoav Nir To: Yaron Sheffer Date: Tue, 27 Apr 2010 16:17:42 +0300 Thread-Topic: [IPsec] New draft posted Thread-Index: AcrmDBVgMIOg6k3vSFWjgP5sfFRTYw== Message-ID: <707EB85B-97CC-49FA-A0E5-CA552AD3DC25@checkpoint.com> References: <1272187315.22380.46.camel@yaronf-linux> <1272371229.2347.87.camel@yaronf-linux> In-Reply-To: <1272371229.2347.87.camel@yaronf-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Jitender Arora Subject: Re: [IPsec] New draft posted 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, 27 Apr 2010 13:18:15 -0000 Or think of a single IKE gateway that sets up IPsec SAs for multiple IPsec = boxes. Like the key server in MSEC. On Apr 27, 2010, at 3:27 PM, Yaron Sheffer wrote: > Hi Jitender, >=20 > regarding your point #3: I am not sure that if I trust a gateway to > connect to, I also trust it to say that all ESP traffic from an > arbitrary IP address should be treated as a Child SA of this gateway. I > cannot see a concrete attack based on this assumption, but it can surely > result in interesting configuration issues. Just think of two IKE > gateways that (possibly because of misconfiguration) share one IPsec > box. >=20 > Thanks, > Yaron >=20 > On Mon, 2010-04-26 at 22:23 -0400, Jitender Arora wrote: >> Hi Yaron, >>=20 >> Thanks for the feedback. I will definitely read the draft-ietf-ipsec= me-ipsec-ha and will get back to you. >>=20 >> Here are my answers to your suggestions: >>=20 >> 1. I will point the section 5.1 in the introduction itself that way the= purpose and applications of the draft are clear. >>=20 >> 2. We did discuss the NAT scenarios and were of the opinion that if we = take care of the NAT scenario's then it will change the IKEv2 protocol in a= major way. >>=20 >> Here is how we were planning to solve the NAT issues: >>=20 >> We were thinking that once the IKE_AUTH exchange is completed and the di= fferent tunnel addresses are specified by the VPN client or the Gateway, ea= ch side can send the informational IKEv2 message containing the NAT_DETECTI= ON_SOURCE_IP and the NAT_DETECTION_DESTINATION_IP payloads (they will have = to send this informational message using the tunnel addresses as the IKEv2 = peer addresses) to see if there are NAT devices between them or not. If the= y determine that there is a NAT device, they can always use NAT addresses a= s the tunnel address. >>=20 >> Using this approach the client or the gateway can determine whether ther= e is a NAT device in the ESP traffic path or not. But using this approach r= equires that the Client and the gateway also to be able to listen for the I= KE packets on the tunnel addresses and also these IKE packets will be prote= cted by the IKE-SA negotiated on the IKE addresses. >>=20 >> So this will require a lot of changes in the current implementation, but= this is certainly possible. >> 3. The tunnel addresses are negotiated during the IKE-AUTH or the CREATE= _CHILD_SA exchanges. These exchanges are protected using the IKE-SA and als= o the users are being authenticated by each side before the tunnel addresse= s are accepted. So once the users are authenticated, the Security Associati= ons will be setup using the tunnel addresses as the tunnel src and the tunn= el destination addresses, so the traffic will protected using these SA's. S= hould not this be enough for the case you mentioned below?=20 >>=20 >> Also as in our case all the IKEv2 signaling will be handled by the same = gateway (load balancer will just act as a pass-through for IKEv2 traffic an= d will just choose the gateway), so I am not sure how the sections you ment= ioned in the RFC 5685 will be applicable. >>=20 >> Thanks, >> Jitender >>=20 >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 >> Sent: Sunday, April 25, 2010 5:22 AM >> To: Jitender Arora >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] New draft posted >>=20 >> Hi Jitender, >>=20 >> this is certainly an interesting approach to the >> high-availability/load-balancing issue that we are just starting to >> tackle, as a group. I would appreciate your inputs to the discussion on >> draft-ietf-ipsecme-ipsec-ha. >>=20 >> Below are a few initial comments on your draft: >>=20 >> - I suggest moving Sec. 5.1 to the front (or at least pointing to it >> from the Introduction) so that the motivation becomes clear before the >> protocol details are presented. >> - Of course, if there are additional usage scenarios, it would be nice >> to include them. >> - Essentially ignoring the issue of NAT severely hurts the applicability >> of this protocol. Even saying something like "use STUN/TURN" is better >> than limiting the protocol to closed networks. >> - The security considerations never discuss the issue that the peer can >> now claims ownership of ANY IP address. I *think* this is just a >> denial-of-service issue, but it certainly needs to be analyzed. Which >> leads to the main issue with this proposal: >> - This is not just a change to IKEv2, it is a rather major change to the >> IPsec architecture. So I would expect some discussion of RFC 4301 >> entities. See the last 2 paragraphs of >> http://tools.ietf.org/html/rfc5685#section-3 for an example. >>=20 >> Thanks, >> Yaron >>=20 >> On Sat, 2010-04-24 at 10:09 -0400, Jitender Arora wrote: >>> Hi All, >>>=20 >>> A new version of I-D, draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00= .txt has been posted to the IETF repository. >>>=20 >>> Filename: draft-arora-ipsecme-ikev2-alt-tunnel-addresses >>> Revision: 00 >>> Title: Alternate Tunnel Addresses for IKEv2 >>>=20 >>> Please take a look and comment. >>>=20 >>> Regards, >>> Jitender >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >>=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From wierbows@us.ibm.com Thu Apr 29 08:02:15 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 5A3AC3A6B16; Thu, 29 Apr 2010 08:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=0.534, 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 fkqM8Kf6ZrMy; Thu, 29 Apr 2010 08:02:10 -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 27A6D3A6896; Thu, 29 Apr 2010 08:02:10 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e2.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3TEoIIl002706; Thu, 29 Apr 2010 10:50:18 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3TF1rEc175326; Thu, 29 Apr 2010 11:01:53 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3TF1nKD002489; Thu, 29 Apr 2010 12:01:49 -0300 Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av03.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o3TF1n39002483; Thu, 29 Apr 2010 12:01:49 -0300 In-Reply-To: <19414.50651.777449.313125@fireball.kivinen.iki.fi> References: <006FEB08D9C6444AB014105C9AEB133FB37650C568@il-ex01.ad.checkpoint.com> <19389.52595.209726.960078@fireball.kivinen.iki.fi> <19400.25514.92364.300616@fireball.kivinen.iki.fi> <19409.38762.719146.5305@fireball.kivinen.iki.fi> <19413.30405.5158.838402@fireball.kivinen.iki.fi> <19414.50651.777449.313125@fireball.kivinen.iki.fi> X-KeepSent: ED93C205:65C23062-85257714:0051E9B2; type=4; name=$KeepSent To: Tero Kivinen X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009 Message-ID: From: David Wierbowski Date: Thu, 29 Apr 2010 11:01:48 -0400 X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 04/29/2010 11:01:49 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] Another round of IKEv2-bis issues 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, 29 Apr 2010 15:02:15 -0000 >I do not want the current text to be removed just because some people >think it is not clear as for me it is clear enough and it is something >that needs to be mentioned, and I have not seen better text to replace >it. What about: If any Child SA fails in such way that a delete notification cannot be sent, then the corresponding IKE SA and all its associated Child SAs MUST be deleted. If the IKE SA fails without being able to send a delete message, then all Child SAs created by the IKE SA MUST be silently deleted. Dave Wierbowski From narten@us.ibm.com Thu Apr 29 11:54: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 0182F3A6AA6 for ; Thu, 29 Apr 2010 11:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.762 X-Spam-Level: X-Spam-Status: No, score=-5.762 tagged_above=-999 required=5 tests=[AWL=0.837, 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 RBLieBfLt7ab for ; Thu, 29 Apr 2010 11:54:15 -0700 (PDT) Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by core3.amsl.com (Postfix) with ESMTP id 1DD0C3A697B for ; Thu, 29 Apr 2010 11:54:15 -0700 (PDT) Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3TIcMeq026451 for ; Thu, 29 Apr 2010 14:38:22 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o3TIrrsq175038 for ; Thu, 29 Apr 2010 14:53:55 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3TIrqXB020204 for ; Thu, 29 Apr 2010 14:53:52 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-65-232-249.mts.ibm.com [9.65.232.249]) by d01av01.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o3TIrq7X020125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Apr 2010 14:53:52 -0400 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id o3TIrpe6014408 for ; Thu, 29 Apr 2010 14:53:51 -0400 Message-Id: <201004291853.o3TIrpe6014408@cichlid.raleigh.ibm.com> To: ipsec@ietf.org Date: Thu, 29 Apr 2010 14:53:51 -0400 From: Thomas Narten Subject: [IPsec] Is IKEv2 mandatory to implement? 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, 29 Apr 2010 18:54:16 -0000 I'm looking at revising RFC 4294 (IPv6 Node Requirements), to update its security section. (e.g., see draft-ietf-6man-node-req-bis-04.txt) RFC 4294 (based on what I understand and recall the thinking to be at the time) mandated IPsec (ESP/AH), but only made IKEv2 a SHOULD. But, it's been pointed out to me that RFC 4301 actually 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. And earlier: > Because most of the security services provided by IPsec require the > use of cryptographic keys, IPsec relies on a separate set of > mechanisms for putting these keys in place. This document requires > support for both manual and automated distribution of keys. It > specifies a specific public-key based approach (IKEv2 [Kau05]) for > automated key management, but other automated key distribution > techniques MAY be used. This implies IKEv2 is a MUST, but doesn't quite say it. This text is taken from Section 3, "System Overview", rather than elsewhere, where it might be considered less normative. Is there more specific wording in 4301 on this point? Is it viewed as an absolute MUST requirement to implement IKEv2 in order to claim compliance with RFC4301? Thomas From dan.mcdonald@oracle.com Thu Apr 29 13:15: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 E66AC3A67D7 for ; Thu, 29 Apr 2010 13:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 h3cepKWsuz+R for ; Thu, 29 Apr 2010 13:15:25 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 150803A68FC for ; Thu, 29 Apr 2010 13:15:25 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3TKF7Ld007329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 29 Apr 2010 20:15:09 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3TId1NJ015257 for ; Thu, 29 Apr 2010 20:15:07 GMT Received: from abhmt013.oracle.com by acsmt355.oracle.com with ESMTP id 222216891272571996; Thu, 29 Apr 2010 13:13:16 -0700 Received: from everywhere.SFBay.Sun.COM (/129.146.109.249) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Apr 2010 13:13:16 -0700 Date: Thu, 29 Apr 2010 16:13:12 -0400 From: Dan McDonald To: ipsec@ietf.org Message-ID: <20100429201312.GA1499@everywhere.SFBay.Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Oracle - Solaris Security (hon. Networking) User-Agent: Mutt/1.5.20 (2009-06-14) X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090201.4BD9E8CE.0021:SCFMA4539811,ss=1,fgs=0 Subject: [IPsec] Multiple IPsec proposals, same SPI? 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, 29 Apr 2010 20:15:26 -0000 Consider the example in section 3.3 of IKEv2bis, which I've edited for brevity: SA Payload | +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, | | 7 transforms, SPI = 0x052357bb ) (either way for ESN, three CBC ciphers, two hashes) +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, | 4 transforms, SPI = 0x35a1d6f2 ) (either way for ESN, two GCM ciphers) the example shows two distinct SPI values. Is it *required* that the SPI values be different? For example, PF_KEY has SADB_GETSPI which merely reserves an inbound SPI value, without ANY other properties attached. IN theory, given the above example, I could instead issue: SA Payload | +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, | | 7 transforms, SPI = 0x052357bb ) (either way for ESN, three CBC ciphers, two hashes) +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, | 4 transforms, SPI = 0x052357bb ) (either way for ESN, two GCM ciphers) since I merely did a GETSPI which reserved 0x052357bb. Thanks, Dan From kivinen@iki.fi Fri Apr 30 01:48: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 626E03A68A9 for ; Fri, 30 Apr 2010 01:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.884 X-Spam-Level: X-Spam-Status: No, score=-0.884 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_40=-0.185] 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 24LJied8xSzn for ; Fri, 30 Apr 2010 01:47:59 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 162EF3A69C8 for ; Fri, 30 Apr 2010 01:47:58 -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 o3U8leEM006810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2010 11:47:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3U8ldBX021424; Fri, 30 Apr 2010 11:47:39 +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: <19418.39211.806428.816790@fireball.kivinen.iki.fi> Date: Fri, 30 Apr 2010 11:47:39 +0300 From: Tero Kivinen To: Thomas Narten In-Reply-To: <201004291853.o3TIrpe6014408@cichlid.raleigh.ibm.com> References: <201004291853.o3TIrpe6014408@cichlid.raleigh.ibm.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min Cc: ipsec@ietf.org Subject: [IPsec] Is IKEv2 mandatory to implement? 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, 30 Apr 2010 08:48:00 -0000 Thomas Narten writes: > Is there more specific wording in 4301 on this point? Is it viewed as > an absolute MUST requirement to implement IKEv2 in order to claim > compliance with RFC4301? RFC4301 says in section 4.5: ---------------------------------------------------------------------- 4.5. SA and Key Management All IPsec implementations MUST support both manual and automated SA and cryptographic key management. ... ... 4.5.2. Automated SA and Key Management Widespread deployment and use of IPsec requires an Internet-standard, scalable, automated, SA management protocol. Such support is required to facilitate use of the anti-replay features of AH and ESP, and to accommodate on-demand creation of SAs, e.g., for user- and session-oriented keying. (Note that the notion of "rekeying" an SA actually implies creation of a new SA with a new SPI, a process that generally implies use of an automated SA/key management protocol.) The default automated key management protocol selected for use with IPsec is IKEv2 [Kau05]. This document assumes the availability of certain functions from the key management protocol that are not supported by IKEv1. Other automated SA management protocols MAY be employed. ... ---------------------------------------------------------------------- I.e. automated key management is mandatory, but the automated key management protocol can also be something else than IKEv2, but for example IKEv1 is NOT enough, as certain functions required by RFC4301 are missing. I do not think there currently exists any other automated key management protocol that could be used for RFC4301 than IKEv2. -- kivinen@iki.fi From kivinen@iki.fi Fri Apr 30 01:55:19 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 58C743A6AC4 for ; Fri, 30 Apr 2010 01:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_20=-0.74] 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 O0VLlIn4miEZ for ; Fri, 30 Apr 2010 01:55:18 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id EB4733A6AC8 for ; Fri, 30 Apr 2010 01:55:17 -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 o3U8t2Rp008600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2010 11:55:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3U8t2kq013234; Fri, 30 Apr 2010 11:55:02 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19418.39654.223692.207039@fireball.kivinen.iki.fi> Date: Fri, 30 Apr 2010 11:55:02 +0300 From: Tero Kivinen To: Dan McDonald In-Reply-To: <20100429201312.GA1499@everywhere.SFBay.Sun.COM> References: <20100429201312.GA1499@everywhere.SFBay.Sun.COM> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 7 min Cc: ipsec@ietf.org Subject: [IPsec] Multiple IPsec proposals, same SPI? 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, 30 Apr 2010 08:55:19 -0000 Dan McDonald writes: > Consider the example in section 3.3 of IKEv2bis, which I've edited for > brevity: > > SA Payload > | > +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, > | | 7 transforms, SPI = 0x052357bb ) > > (either way for ESN, three CBC ciphers, two hashes) > > +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, > | 4 transforms, SPI = 0x35a1d6f2 ) > (either way for ESN, two GCM ciphers) > > the example shows two distinct SPI values. > > Is it *required* that the SPI values be different? It is not required that SPI values are different. But it is required that recipient accepts such proposal where they are different. The SA allocation is completely local matter. > For example, PF_KEY has SADB_GETSPI which merely reserves an inbound > SPI value, without ANY other properties attached. IN theory, given > the above example, I could instead issue: > > SA Payload > | > +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, > | | 7 transforms, SPI = 0x052357bb ) > > (either way for ESN, three CBC ciphers, two hashes) > > +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, > | 4 transforms, SPI = 0x052357bb ) > (either way for ESN, two GCM ciphers) > > since I merely did a GETSPI which reserved 0x052357bb. Yes, that is also completely legal proposal. I.e. both versions must be supported by the receiving end, but sender end can only use whatever is more convinient for him. In some environments the SPI selection can be done so that part of the SPI indicates for example the crypto processor which will be taking care of the traffic, and if there are multiple crypto processors which have different capabilities, it might not be possible for sender end to select same SPI for all proposals. In other environments like in yours, it might be that SPI is same because it is allocated using one PF_KEY operation. Unfortunately this is also true for IKE SA rekey (where the half of the IKE SA SPIs are inside the Proposal payloads inside SA Payload), and that would be one place where I would like to change specification so they would need to be same in all proposals, but it is too late for that change. -- kivinen@iki.fi