From Nicolas.Williams@sun.com Thu Oct 15 15:27:28 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C0E93A6407 for ; Thu, 15 Oct 2009 15:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.226 X-Spam-Level: X-Spam-Status: No, score=-4.226 tagged_above=-999 required=5 tests=[AWL=-0.594, 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 K5PksYdm9phf for ; Thu, 15 Oct 2009 15:27:27 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by core3.amsl.com (Postfix) with ESMTP id 023003A68CD for ; Thu, 15 Oct 2009 15:27:26 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9FMRUvc001993 for ; Thu, 15 Oct 2009 22:27:30 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9FMRTNu038182 for ; Thu, 15 Oct 2009 16:27:29 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9FMG8D4001736 for ; Thu, 15 Oct 2009 17:16:08 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9FMG8BO001735 for btns@ietf.org; Thu, 15 Oct 2009 17:16:08 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 15 Oct 2009 17:16:08 -0500 From: Nicolas Williams To: btns@ietf.org Message-ID: <20091015221608.GC907@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.7i Subject: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 22:27:28 -0000 During AUTH48 review I noticed this: o CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection parameters], [peer ID], [local ID]) -> latch handle | error -------->If no connection latch exists in the ESTABLISHED states with -------->the same 5-tuple, and if there exist no child SAs that match -------->the given 5-tuple, and if local policy permits it, then the -------->system MUST initiate an IKE exchange to set up child SAs for -------->this 5-tuple. Otherwise, an error is returned to the ULP. Once one or more applicable SAs exist in the SAD and all such SAs share the same type and quality-of-protection parameters and the same peer, then this operation creates a connection latch object in the ESTABLISHED state for the given 5-tuple. If the caller provided all the optional arguments to this operation, then the resulting connection latch can be created in the ESTABLISHED state directly. -------->If there exist no child SAs matching the given 5-tuple, then -------->the key manager SHOULD try to create a pair of child SAs for that 5-tuple. In any case, the key manager can expect that the -------->ULP will send a packet that would trigger the creation of such -------->SAs. There are two conflicts here. The first and second highlighted sentences conflict in that one says "MUST" while the other says "SHOULD". The third highlighted sentence conflicts with the first two highlighted sentences. The third highlighted sentence is the correct one: the IKE exchange need not be triggered until the ULP sends a packet. The IKE exchange _can_ be triggered before then (since the key manager knows, from the fact that CREATE_CONNECTION_LATCH() was used, that that packet is coming, but it doesn't need to be. Now, if the key manager waits for the ULP to send a packet then the latch that gets created cannot have all parameters filled in. That is, we have a "larval" state to consider. IMO this is a fairly minor editing issue, but nonetheless it should be fixed. And though minor, the amount of change involved (a new state!) definitely requires review by the WG. (I've also asked Tim, and he concurs.) My proposed resolution is to add a new state, called "LARVAL", a description of that state in section 2.2, update the state diagram in figure 1, and update the description of CREATE_CONNECTION_LATCH(). Section 2.2 now reads: 2.2. Connection Latch State Machine Connection latches can exist in any of the following five states: o LISTENER o LARVAL o ESTABLISHED o BROKEN (there exist SAs that conflict with the given connection latch, conflicting SPD changes have been made, or DPD has been triggered and the peer is considered dead or restarted) o CLOSED (by the ULP, the application or administratively) and always have an associated owner, or holder, such as a ULP transmission control block (TCB). A connection latch can be born in the LISTENER state, which can transition only to the CLOSED state. The LISTENER state corresponds to LISTEN state of TCP (and other ULPs) and is associated with IP 3-tuples, and can give rise to new connection latches in the ESTABLISHED state. A connection latch can also be born in the LARVAL, ESTABLISHED and BROKEN states, either through the direct initiative of a ULP or when an event occurs that causes a LISTENER latch to create a new latch (in either ESTABLISHED or BROKEN states). These states represent an active connection latch for a traffic flow's 5-tuple. Connection latches in the LARVAL state can transition to the ESTABLISHED and BROKEN states. Connection latches in the ESTABLISHED state can transition to the BROKEN and CLOSED states. Connection latches in the BROKEN state can transition to the the LARVAL state if and only if the latch had been in the LARVAL state before and never in the ESTABLISHED state. Connection latches in the BROKEN state can transition to the ESTABLISHED states as well as to the CLOSED state. The LARVAL state is used when not all the parameters to be latched are known; a future IKE exchange may fill them in. Connection latches remain in the LARVAL state until a child SA appears in the the SAD from which all the missing parameters can be obtained, in which case it transitions to the ESTABLISHED state. If it is possible that conflicting SAs can appear in the SAD before a latch in the LARVAL state can be changed to the ESTABLISHED state, then the latch will transition to the BROKEN state, and may later transition back to LARVAL or ESTABLISHED when the conflict clears up. Connection latches remain in the CLOSED state until... ... The state diagram now looks like: | | V | | | /--------\ | | | +------|LISTENER|...... | | | | \--------/ | | | | | | | | | | | | | | | /------\ | | | | | |LARVAL| | | | | | \------/ | | | | | | | | | | : | | | +--------+ | | : | | (e.g., TCP SYN | | | | | received, | | | | +--------------------+ | connect() | | | | |Legend: | | called, ...) v v | | | dotted lines denote| | | /-----------\ | | | latch creation | | | |ESTABLISHED| | | | | | \-----------/ | | | solid lines denote | | | ^ | | | | state transition| | | | | semi-solid lines | | | cleared> | | | | denote async | | | | | +---+ | notification | | | | v v +--------------------+ | | /----------------\ | +.....>| BROKEN |.-.-.-.-.-> | \----------------/ | | | | | v | /------\ +------------------->|CLOSED| \------/ And the description of CREATE_CONNECTION_LATCH() now reads: o CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection parameters], [peer ID], [local ID]) -> latch handle | error If no connection latch exists with the same 5-tuple, and if local policy (i.e., the SPD) permits it, then a latch is created in either the LARVAL, ESTABLISHED, or BROKEN states. Otherwise, an error is returned to the ULP. If one or more applicable SA pairs exist in the SAD, and all such SAs share the same type- and quality-of-protection parameters and the same peer, then this operation creates a connection latch object in the ESTABLISHED state for the given 5-tuple. If more than one applicable SA pair exists in the SAD that do not agree on type-, quality-of-protection parameters and peer IDs, then this operation creates a connection latch object in the BROKEN state. If no SA pairs exists in the SAD then this operation creates a connection latch object in the LARVAL state. If the caller provided all the optional arguments to this operation, then the resulting connection latch can be created in the ESTABLISHED state even if there are no applicable SA pairs in the SAD. If there exist no child SAs matching the given 5-tuple, then the key manager MAY try to create a pair of child SAs for that 5-tuple. In any case, the key manager can expect that the ULP will send a packet that would trigger the creation of such SAs. Either way, and assuming no conflicts arise, the necessary child SA pairs should eventually be created, causing a latch in the LARVAL state to transition to the ESTABLISHED state. Comments? Nico -- From mcr@marajade.sandelman.ca Thu Oct 15 17:58:38 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FFDA3A6826 for ; Thu, 15 Oct 2009 17:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 QWXEXSY8fEU0 for ; Thu, 15 Oct 2009 17:58:38 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 0EDE23A680E for ; Thu, 15 Oct 2009 17:58:38 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id 816943428C; Fri, 16 Oct 2009 01:03:21 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id CD5C34E7F9; Thu, 15 Oct 2009 20:58:40 -0400 (EDT) From: Michael Richardson To: Nicolas Williams In-Reply-To: <20091015221608.GC907@Sun.COM> References: <20091015221608.GC907@Sun.COM> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 15 Oct 2009 20:58:40 -0400 Message-ID: <7260.1255654720@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca Cc: btns@ietf.org Subject: Re: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 00:58:38 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> The third highlighted sentence is the correct one: the IKE Nicolas> exchange need not be triggered until the ULP sends a Nicolas> packet. The IKE exchange _can_ be triggered before then Nicolas> (since the key manager knows, from the fact that Nicolas> CREATE_CONNECTION_LATCH() was used, that that packet is Nicolas> coming, but it doesn't need to be. Nicolas> Now, if the key manager waits for the ULP to send a packet Nicolas> then the latch that gets created cannot have all parameters Nicolas> filled in. That is, we have a "larval" state to consider. Right. Nicolas> Comments? I have no other solution. It all makes sense to me. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@marajade.sandelman.ca Thu Oct 15 17:54:16 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9CF03A63EC for ; Thu, 15 Oct 2009 17:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] 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 b98ZDznFh7eo for ; Thu, 15 Oct 2009 17:54:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id C85BF3A6801 for ; Thu, 15 Oct 2009 17:54:15 -0700 (PDT) Received: from sandelman.ottawa.on.ca (unknown [209.87.252.196]) by relay.sandelman.ca (Postfix) with ESMTPS id BD3B734287; Fri, 16 Oct 2009 00:58:58 +0000 (UTC) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 09F2E4E7F9; Thu, 15 Oct 2009 20:54:18 -0400 (EDT) From: Michael Richardson To: Nicolas Williams In-Reply-To: <20091015221608.GC907@Sun.COM> References: <20091015221608.GC907@Sun.COM> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 15 Oct 2009 20:54:18 -0400 Message-ID: <6903.1255654458@marajade.sandelman.ca> Sender: mcr@marajade.sandelman.ca X-Mailman-Approved-At: Fri, 16 Oct 2009 08:29:48 -0700 Cc: btns@ietf.org Subject: Re: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 00:54:16 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> The third highlighted sentence is the correct one: the IKE Nicolas> exchange need not be triggered until the ULP sends a Nicolas> packet. The IKE exchange _can_ be triggered before then Nicolas> (since the key manager knows, from the fact that Nicolas> CREATE_CONNECTION_LATCH() was used, that that packet is Nicolas> coming, but it doesn't need to be. Nicolas> Now, if the key manager waits for the ULP to send a packet Nicolas> then the latch that gets created cannot have all parameters Nicolas> filled in. That is, we have a "larval" state to consider. Right. Nicolas> Comments? I have no other solution. It all makes sense to me. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From Nicolas.Williams@sun.com Fri Oct 16 10:37:18 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9F328C133 for ; Fri, 16 Oct 2009 10:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.315 X-Spam-Level: X-Spam-Status: No, score=-5.315 tagged_above=-999 required=5 tests=[AWL=0.731, 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 9Gcn-CFZaCgc for ; Fri, 16 Oct 2009 10:37:17 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 46D043A67B8 for ; Fri, 16 Oct 2009 10:37:17 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9GHbKN5029233 for ; Fri, 16 Oct 2009 17:37:20 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9GHbKgt053963 for ; Fri, 16 Oct 2009 11:37:20 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9GHPwQq002011; Fri, 16 Oct 2009 12:25:58 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9GHPvsm002010; Fri, 16 Oct 2009 12:25:57 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 16 Oct 2009 12:25:42 -0500 From: Nicolas Williams To: Michael Richardson Message-ID: <20091016172542.GG892@Sun.COM> References: <20091015221608.GC907@Sun.COM> <6903.1255654458@marajade.sandelman.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6903.1255654458@marajade.sandelman.ca> User-Agent: Mutt/1.5.7i Cc: btns@ietf.org Subject: Re: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 17:37:18 -0000 On Thu, Oct 15, 2009 at 08:54:18PM -0400, Michael Richardson wrote: > > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> The third highlighted sentence is the correct one: the IKE > Nicolas> exchange need not be triggered until the ULP sends a > Nicolas> packet. The IKE exchange _can_ be triggered before then > Nicolas> (since the key manager knows, from the fact that > Nicolas> CREATE_CONNECTION_LATCH() was used, that that packet is > Nicolas> coming, but it doesn't need to be. > > Nicolas> Now, if the key manager waits for the ULP to send a packet > Nicolas> then the latch that gets created cannot have all parameters > Nicolas> filled in. That is, we have a "larval" state to consider. > > Right. > > Nicolas> Comments? > > I have no other solution. It all makes sense to me. Thanks! I've beautified the state machine figure a bit (no arrows cross now), clarified the trigger events in the figure, and restored dotted lines that I'd accidentally made non-dotted. The new figure is below. Anyone else have comments? : : V : : : /--------\ : : : +-----|LISTENER|--+ : : : | \--------/ | : : : | | | : : : | | | : /------\ : | | | : |LARVAL| : +--------------------+ | | | : \------/ : |Legend: | | | | : | | : | dotted lines denote| | : child SAs : | | | [e.g., for TCP] : installed> : | solid lines denote | | [ SYN soon to ] : [e.g., TCP] : | state transition| | [ be received ] : [ SYN sent] : | | | | | : | | : | semi-solid lines | | | v v v | : | denote async | | | /-----------\ | : | notification | | | |ESTABLISHED| | : +--------------------+ | \-----------/ | : | | ^ | | : | | | : | | cleared> | | : | | | | | : | | | v v v | | /---------------------\ | +------>| BROKEN |-.-.-.-> | \---------------------/ | | | | | v | /------\ +------------------->|CLOSED| \------/ Nico -- From julienl@qualcomm.com Fri Oct 16 12:48:21 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475E428C0FA for ; Fri, 16 Oct 2009 12:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE4EMWPZ5lhZ for ; Fri, 16 Oct 2009 12:48:19 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id CC2A93A63D3 for ; Fri, 16 Oct 2009 12:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1255722504; x=1287258504; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Nicolas=20Williams=20, =0D=0A=20=20=20=20=20=20=20=20"btns@ietf.org"=0D=0A=09|Date:=20Fri,=2016=20Oct=202009=2012:48:16=20 -0700|Subject:=20RE:=20[btns]=20Minor=20connection-latch =20problem=20in=20AUTH48|Thread-Topic:=20[btns]=20Minor =20connection-latch=20problem=20in=20AUTH48|Thread-Index: =20AcpN5rHQ/v0A0SqLQNuZ6uFW3sOslQAsAB1g|Message-ID:=20|References:=20<20091015221608.GC907@Sun.COM> |In-Reply-To:=20<20091015221608.GC907@Sun.COM> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5773"=3B=20a=3D"25422095"; bh=UAtjKGzXimfIXHsuhPSLWMxjyIURbjJnif4+ItsVnwk=; b=QF5hE7VcgDI3MCd38kX37zrSAp0aE6uvlnNMyp0jOj/IjPiOzZRNTAlZ V5N3AUBZBh1jNEAVsM8bjxFv7Y/UEtKB4dhJhBmkTUg82PTUoqg0qKjhL osv22MsxaPnn1smokVPVyvQqhO++M3ZhLYnFncxikwESp5Zn3ktWV5BGq Q=; X-IronPort-AV: E=McAfee;i="5300,2777,5773"; a="25422095" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2009 12:48:22 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9GJmLAo016549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2009 12:48:22 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9GJmLhx021081 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Oct 2009 12:48:21 -0700 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 16 Oct 2009 12:48:20 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.21; Fri, 16 Oct 2009 12:48:20 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Fri, 16 Oct 2009 12:48:20 -0700 From: "Laganier, Julien" To: Nicolas Williams , "btns@ietf.org" Date: Fri, 16 Oct 2009 12:48:16 -0700 Thread-Topic: [btns] Minor connection-latch problem in AUTH48 Thread-Index: AcpN5rHQ/v0A0SqLQNuZ6uFW3sOslQAsAB1g Message-ID: References: <20091015221608.GC907@Sun.COM> In-Reply-To: <20091015221608.GC907@Sun.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: Re: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 19:48:21 -0000 Hi Nico, I understand your proposal below tries to removes some sort of chicken-and-= egg problem with the ULP creating the latch before sending a packet, the la= tch creation triggering key management to create an SA if there's none, and= the packet being sent triggering the key management. I'd like to make sure I understand the issue and your proposal, and in part= icular why we can't have the latch DB triggering directly the key manager: = The existing text you have quoted below says "... if there exist no child S= As that match the given 5-tuple, and if local policy permits it", which imp= lies that the 5-tuple is matched against the SPD. Couldn't this action trig= ger the key manager to establish a child SA without having to be triggered = by an actual packet? Since the ULP trying to create a latch presumably implies that the ULP has = a packet to transmit, when it is the case that the ULP tries to latch the 5= -tuple, an SPD entry is matched by the 5-tuple but no child SA is found, I'= d like to understand what's the value of: (1) latching the ULP on a larval latch, wait for the actual packet to be tr= ansmitted by the ULP to trigger IKEv2 after an SPD entry is matched but no = child SA is found, establish the SA, and transition the latch to establishe= d vs.=20 (2) triggering IKEv2 based on the 5-tuple, establish the SA, latch the ULP = on it. To me it seems that your proposal (1) above simply implies delaying latchin= g on the final SA (and performing an additional SPD match on the real packe= t but that's negligible), while I see no problem with (2)... Am I missing something? --julien Nicolas Williams wrote: >=20 > During AUTH48 review I noticed this: >=20 > o CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection > parameters], [peer ID], [local ID]) -> latch handle | error >=20 > -------->If no connection latch exists in the ESTABLISHED states with > -------->the same 5-tuple, and if there exist no child SAs that match > -------->the given 5-tuple, and if local policy permits it, then the > -------->system MUST initiate an IKE exchange to set up child SAs for > -------->this 5-tuple. Otherwise, an error is returned to the ULP. > Once one or more applicable SAs exist in the SAD and all such > SAs share the same type and quality-of-protection parameters > and the same peer, then this operation creates a connection > latch object in the ESTABLISHED state for the given 5-tuple. > If the caller provided all the optional arguments to this > operation, then the resulting connection latch can be created > in the ESTABLISHED state directly. >=20 > -------->If there exist no child SAs matching the given 5-tuple, then > -------->the key manager SHOULD try to create a pair of child SAs for > that 5-tuple. In any case, the key manager can expect that > the > -------->ULP will send a packet that would trigger the creation of such > -------->SAs. >=20 > There are two conflicts here. The first and second highlighted > sentences conflict in that one says "MUST" while the other says > "SHOULD". The third highlighted sentence conflicts with the first two > highlighted sentences. >=20 > The third highlighted sentence is the correct one: the IKE exchange > need > not be triggered until the ULP sends a packet. The IKE exchange _can_ > be triggered before then (since the key manager knows, from the fact > that CREATE_CONNECTION_LATCH() was used, that that packet is coming, > but > it doesn't need to be. >=20 > Now, if the key manager waits for the ULP to send a packet then the > latch that gets created cannot have all parameters filled in. That is, > we have a "larval" state to consider. >=20 > IMO this is a fairly minor editing issue, but nonetheless it should be > fixed. And though minor, the amount of change involved (a new state!) > definitely requires review by the WG. (I've also asked Tim, and he > concurs.) >=20 > My proposed resolution is to add a new state, called "LARVAL", a > description of that state in section 2.2, update the state diagram in > figure 1, and update the description of CREATE_CONNECTION_LATCH(). >=20 > Section 2.2 now reads: >=20 > 2.2. Connection Latch State Machine >=20 > Connection latches can exist in any of the following five states: >=20 > o LISTENER >=20 > o LARVAL >=20 > o ESTABLISHED >=20 > o BROKEN (there exist SAs that conflict with the given connection > latch, conflicting SPD changes have been made, or DPD has been > triggered and the peer is considered dead or restarted) >=20 > o CLOSED (by the ULP, the application or administratively) >=20 > and always have an associated owner, or holder, such as a ULP > transmission control block (TCB). >=20 > A connection latch can be born in the LISTENER state, which can > transition only to the CLOSED state. The LISTENER state corresponds > to LISTEN state of TCP (and other ULPs) and is associated with IP > 3-tuples, and can give rise to new connection latches in the > ESTABLISHED state. >=20 > A connection latch can also be born in the LARVAL, ESTABLISHED and > BROKEN states, either through the direct initiative of a ULP or when > an event occurs that causes a LISTENER latch to create a new latch > (in either ESTABLISHED or BROKEN states). These states represent an > active connection latch for a traffic flow's 5-tuple. Connection > latches in the LARVAL state can transition to the ESTABLISHED and > BROKEN states. Connection latches in the ESTABLISHED state can > transition to the BROKEN and CLOSED states. Connection latches in > the BROKEN state can transition to the the LARVAL state if and only > if the latch had been in the LARVAL state before and never in the > ESTABLISHED state. Connection latches in the BROKEN state can > transition to the ESTABLISHED states as well as to the CLOSED state. >=20 > The LARVAL state is used when not all the parameters to be latched > are known; a future IKE exchange may fill them in. Connection > latches remain in the LARVAL state until a child SA appears in the > the SAD from which all the missing parameters can be obtained, in > which case it transitions to the ESTABLISHED state. If it is > possible that conflicting SAs can appear in the SAD before a latch > in > the LARVAL state can be changed to the ESTABLISHED state, then the > latch will transition to the BROKEN state, and may later transition > back to LARVAL or ESTABLISHED when the conflict clears up. >=20 > Connection latches remain in the CLOSED state until... > ... >=20 > The state diagram now looks like: >=20 > > | > | > V | | | > /--------\ | | | > +------|LISTENER|...... | | | > | \--------/ | | | | > | | | | | | > | | | | | /------\ > | | | | | |LARVAL| > | | | | | \------/ > | | | | | | > | | | | : > | | | +--------+ > | | : | > | (e.g., TCP SYN | | | | > | received, | | | | +--------------------+ > | connect() | | | | |Legend: | > | called, ...) v v | | | dotted lines denote| > | | /-----------\ | | | latch creation | > | | |ESTABLISHED| | | | | > | \-----------/ | | | solid lines denote | > | | ^ | | | | state transition| > | | | | | | semi-solid lines | > | | cleared> | | | | denote async | > | | | | +---+ | notification | > | | | v v +--------------------+ > | | /----------------\ > | +.....>| BROKEN |.-.-.-.-.-> > | \----------------/ > | | > > | | > | v > | /------\ > +------------------->|CLOSED| > \------/ >=20 > And the description of CREATE_CONNECTION_LATCH() now reads: >=20 > o CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection > parameters], [peer ID], [local ID]) -> latch handle | error >=20 > If no connection latch exists with the same 5-tuple, and if > local policy (i.e., the SPD) permits it, then a latch is > created in either the LARVAL, ESTABLISHED, or BROKEN states. > Otherwise, an error is returned to the ULP. If one or more > applicable SA pairs exist in the SAD, and all such SAs share > the same type- and quality-of-protection parameters and the > same peer, then this operation creates a connection latch > object in the ESTABLISHED state for the given 5-tuple. If > more > than one applicable SA pair exists in the SAD that do not > agree > on type-, quality-of-protection parameters and peer IDs, then > this operation creates a connection latch object in the BROKEN > state. If no SA pairs exists in the SAD then this operation > creates a connection latch object in the LARVAL state. If the > caller provided all the optional arguments to this operation, > then the resulting connection latch can be created in the > ESTABLISHED state even if there are no applicable SA pairs in > the SAD. >=20 > If there exist no child SAs matching the given 5-tuple, then > the key manager MAY try to create a pair of child SAs for that > 5-tuple. In any case, the key manager can expect that the ULP > will send a packet that would trigger the creation of such SAs. > Either way, and assuming no conflicts arise, the necessary > child SA pairs should eventually be created, causing a latch > in > the LARVAL state to transition to the ESTABLISHED state. >=20 >=20 > Comments? >=20 > Nico > -- > _______________________________________________ > btns mailing list > btns@ietf.org > https://www.ietf.org/mailman/listinfo/btns From Nicolas.Williams@sun.com Fri Oct 16 13:51:17 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22883A68E4 for ; Fri, 16 Oct 2009 13:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.437 X-Spam-Level: X-Spam-Status: No, score=-5.437 tagged_above=-999 required=5 tests=[AWL=0.610, 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 u9mhWnCGbY4l for ; Fri, 16 Oct 2009 13:51:17 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id F19A63A68A3 for ; Fri, 16 Oct 2009 13:51:16 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9GKpF8w014702 for ; Fri, 16 Oct 2009 20:51:15 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9GKpEV0050462 for ; Fri, 16 Oct 2009 14:51:14 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9GKdrth002159; Fri, 16 Oct 2009 15:39:53 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9GKdrlE002158; Fri, 16 Oct 2009 15:39:53 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 16 Oct 2009 15:39:53 -0500 From: Nicolas Williams To: "Laganier, Julien" Message-ID: <20091016203953.GQ892@Sun.COM> References: <20091015221608.GC907@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "btns@ietf.org" Subject: Re: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 20:51:17 -0000 On Fri, Oct 16, 2009 at 12:48:16PM -0700, Laganier, Julien wrote: > I understand your proposal below tries to removes some sort of > chicken-and-egg problem with the ULP creating the latch before sending > a packet, the latch creation triggering key management to create an SA > if there's none, and the packet being sent triggering the key > management. Actually, I was just trying to resolve a three-way conflict in the text. As a secondary goal I thought it would be a good idea to not REQUIRE that the key manager initiate IKE/child SAs just because a ULP is expected soon to send a packet that will require child SAs. I think that should be at least a MAY, and at most a SHOULD. Perhaps the WG would say that we should REQUIRE that the key manager initiate IKE/child SAs ahead of any triggering packet as a simplification of the model (then we don't need a LARVAL state). But I could certainly see implementors not wanting to do that (for one it makes the CREATE_CONNECTION_LATCH() call slow). An alternative would be to say "must" instead of "MUST" and then explain that if the key manager does not initiate IKE/child SAs as part of the CREATE_CONNECTION_LATCH() call, then it must have a LARVAL state that we have not defined. You can see why I think this is a minor problem, but also why it'd be better to address it. > I'd like to make sure I understand the issue and your proposal, and in > particular why we can't have the latch DB triggering directly the key > manager: The existing text you have quoted below says "... if there > exist no child SAs that match the given 5-tuple, and if local policy > permits it", which implies that the 5-tuple is matched against the > SPD. Couldn't this action trigger the key manager to establish a child > SA without having to be triggered by an actual packet? Indeed. We don't absolutely need the LARVAL state. Perhaps we should describe it as an OPTIONAL state, since an implementation might not have such a state at all. Nico -- From julienl@qualcomm.com Fri Oct 16 14:13:13 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23BC3A682B for ; Fri, 16 Oct 2009 14:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.414 X-Spam-Level: X-Spam-Status: No, score=-105.414 tagged_above=-999 required=5 tests=[AWL=1.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmirjU0ubPsi for ; Fri, 16 Oct 2009 14:13:11 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id D1CE03A6358 for ; Fri, 16 Oct 2009 14:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1255727596; x=1287263596; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Nicolas=20Williams=20 |CC:=20"btns@ietf.org"=20|Date:=20Fri,=201 6=20Oct=202009=2014:13:13=20-0700|Subject:=20RE:=20[btns] =20Minor=20connection-latch=20problem=20in=20AUTH48 |Thread-Topic:=20[btns]=20Minor=20connection-latch=20prob lem=20in=20AUTH48|Thread-Index:=20AcpOo3bPggPZz765RK6MwvU yWuQX8wAAOeow|Message-ID:=20|References: =20<20091015221608.GC907@Sun.COM>=0D=0A=20 =0D=0A=20<20091016203953.GQ892@Sun.COM>|In-Reply-To:=20<2 0091016203953.GQ892@Sun.COM>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5773"=3B=20a=3D"25427614"; bh=F1oM9cASjzaxSWdyW5zYXuYCO8SuRb3jCa5juTHA5G4=; b=VAqYzVOneOIDX1Q9ONvMZSMEPnTrPXlr8JYyc1xecOOvS760U1Lf0XSR tfgMtXuoV8t2xEST9vIaEAOADRYikUNqNbyp+0z9sRx4lK4qYOv2UugWT 7NYLsK7bhCUwS/uxvVvRT8TAT0G/ei1+KhLghshUG5lwnIR20W9fFJma0 E=; X-IronPort-AV: E=McAfee;i="5300,2777,5773"; a="25427614" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2009 14:13:16 -0700 Received: from msgtransport04.qualcomm.com (msgtransport04.qualcomm.com [129.46.61.156]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9GLDFrb019390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2009 14:13:15 -0700 Received: from nasanexhub01.na.qualcomm.com (nasanexhub01.na.qualcomm.com [10.46.93.121]) by msgtransport04.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9GLDFth006481 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Oct 2009 14:13:15 -0700 Received: from nalasexhc02.na.qualcomm.com (10.47.129.186) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 16 Oct 2009 14:13:14 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhc02.na.qualcomm.com ([10.47.129.186]) with mapi; Fri, 16 Oct 2009 14:13:14 -0700 From: "Laganier, Julien" To: Nicolas Williams Date: Fri, 16 Oct 2009 14:13:13 -0700 Thread-Topic: [btns] Minor connection-latch problem in AUTH48 Thread-Index: AcpOo3bPggPZz765RK6MwvUyWuQX8wAAOeow Message-ID: References: <20091015221608.GC907@Sun.COM> <20091016203953.GQ892@Sun.COM> In-Reply-To: <20091016203953.GQ892@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "btns@ietf.org" Subject: Re: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 21:13:13 -0000 Nicolas Williams wrote >=20 > On Fri, Oct 16, 2009 at 12:48:16PM -0700, Laganier, Julien wrote: > > I understand your proposal below tries to removes some sort of > > chicken-and-egg problem with the ULP creating the latch before > sending > > a packet, the latch creation triggering key management to create an > SA > > if there's none, and the packet being sent triggering the key > > management. >=20 > Actually, I was just trying to resolve a three-way conflict in the > text. As a secondary goal I thought it would be a good idea to not > REQUIRE that the key manager initiate IKE/child SAs just because a ULP > is expected soon to send a packet that will require child SAs. I think > that should be at least a MAY, and at most a SHOULD. >=20 > Perhaps the WG would say that we should REQUIRE that the key manager > initiate IKE/child SAs ahead of any triggering packet as a > simplification of the model (then we don't need a LARVAL state). But I > could certainly see implementors not wanting to do that (for one it > makes the CREATE_CONNECTION_LATCH() call slow). I think this is the external behavior that we want to capture. The specific= s of how a given implementation achieves that need not to be specified in t= he RFC as long as the conceptual behavior is clear and guarantees interoper= ability. Both style of implementation would conform to that behavior, whether or not= the triggering occurs directly as a result of latch creation, or indirectl= y via triggering by the first packet. =20 > An alternative would be to say "must" instead of "MUST" and then > explain that if the key manager does not initiate IKE/child SAs as part o= f the > CREATE_CONNECTION_LATCH() call, then it must have a LARVAL state that > we have not defined. FWIW - from my perspective there's no difference between "must" and "MUST",= RFC 2119 says about key word that "These words are often capitalized", but= does not make it a must. > You can see why I think this is a minor problem, but also why it'd be > better to address it. >=20 > > I'd like to make sure I understand the issue and your proposal, and > in > > particular why we can't have the latch DB triggering directly the key > > manager: The existing text you have quoted below says "... if there > > exist no child SAs that match the given 5-tuple, and if local policy > > permits it", which implies that the 5-tuple is matched against the > > SPD. Couldn't this action trigger the key manager to establish a > > child SA without having to be triggered by an actual packet? >=20 > Indeed. We don't absolutely need the LARVAL state. Perhaps we should > describe it as an OPTIONAL state, since an implementation might not > have such a state at all. I tend to think that we do not need the state at all. It is a valid impleme= ntation strategy, but it does not need to be captured in the standard since= there are as-valid alternatives (e.g., Latch Manager triggers key Manageme= nt directly)_ --julien From Nicolas.Williams@sun.com Fri Oct 16 14:28:11 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60EA23A688F for ; Fri, 16 Oct 2009 14:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.524 X-Spam-Level: X-Spam-Status: No, score=-5.524 tagged_above=-999 required=5 tests=[AWL=0.522, 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 M9p61RkkEZbL for ; Fri, 16 Oct 2009 14:28:10 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 55ADD3A682B for ; Fri, 16 Oct 2009 14:28:10 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9GLSEOk028203 for ; Fri, 16 Oct 2009 21:28:14 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9GLSDpV011363 for ; Fri, 16 Oct 2009 15:28:13 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9GLGqLD002251; Fri, 16 Oct 2009 16:16:52 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9GLGqMf002250; Fri, 16 Oct 2009 16:16:52 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 16 Oct 2009 16:16:52 -0500 From: Nicolas Williams To: "Laganier, Julien" Message-ID: <20091016211652.GV892@Sun.COM> References: <20091015221608.GC907@Sun.COM> <20091016203953.GQ892@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "btns@ietf.org" Subject: Re: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 21:28:11 -0000 On Fri, Oct 16, 2009 at 02:13:13PM -0700, Laganier, Julien wrote: > Nicolas Williams wrote > > Perhaps the WG would say that we should REQUIRE that the key manager > > initiate IKE/child SAs ahead of any triggering packet as a > > simplification of the model (then we don't need a LARVAL state). But I > > could certainly see implementors not wanting to do that (for one it > > makes the CREATE_CONNECTION_LATCH() call slow). > > I think this is the external behavior that we want to capture. The > specifics of how a given implementation achieves that need not to be > specified in the RFC as long as the conceptual behavior is clear and > guarantees interoperability. Let me re-think the text. Perhaps I'll simply add a note that an implementor whose key manager does not immediately initiake IKE/child SAs on CREATE_CONNECTION_LATCH() must have a larval state that we don't describe. Would that work? > Both style of implementation would conform to that behavior, whether > or not the triggering occurs directly as a result of latch creation, > or indirectly via triggering by the first packet. The external behavior will only show differences in timing. > > An alternative would be to say "must" instead of "MUST" and then > > explain that if the key manager does not initiate IKE/child SAs as part of the > > CREATE_CONNECTION_LATCH() call, then it must have a LARVAL state that > > we have not defined. > > FWIW - from my perspective there's no difference between "must" and > "MUST", RFC 2119 says about key word that "These words are often > capitalized", but does not make it a must. When those terms are used in capitals I think the intent is clear; when they are not the intent may be clear from the fact that the same document also uses those terms in capitalized form. > > Indeed. We don't absolutely need the LARVAL state. Perhaps we should > > describe it as an OPTIONAL state, since an implementation might not > > have such a state at all. > > I tend to think that we do not need the state at all. It is a valid > implementation strategy, but it does not need to be captured in the > standard since there are as-valid alternatives (e.g., Latch Manager > triggers key Management directly)_ OK. I'll propose new text later today. From julienl@qualcomm.com Fri Oct 16 15:49:41 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902343A67AA for ; Fri, 16 Oct 2009 15:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.583 X-Spam-Level: X-Spam-Status: No, score=-105.583 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NbMTL9xr5Ev for ; Fri, 16 Oct 2009 15:49:40 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 959943A694D for ; Fri, 16 Oct 2009 15:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1255733385; x=1287269385; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Nicolas=20Williams=20 |CC:=20"btns@ietf.org"=20|Date:=20Fri,=201 6=20Oct=202009=2015:49:41=20-0700|Subject:=20RE:=20[btns] =20Minor=20connection-latch=20problem=20in=20AUTH48 |Thread-Topic:=20[btns]=20Minor=20connection-latch=20prob lem=20in=20AUTH48|Thread-Index:=20AcpOqKBFczXeTb4CTs+CFM/ u0zhK1wACgwDA|Message-ID:=20|References: =20<20091015221608.GC907@Sun.COM>=0D=0A=20 =0D=0A=20<20091016203953.GQ892@Sun.COM>=0D=0A=20=0D=0A=20<20091016211652.GV892@Sun.COM> |In-Reply-To:=20<20091016211652.GV892@Sun.COM> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5773"=3B=20a=3D"25434639"; bh=zBpCa/7BrjIsn3dSErnBYENPz0Qhncz6EZ3VwFyBDTw=; b=OjwSVkCp7FXKih++p0FRoihdfDcASMuSigIxPeUAKU/mFiyQNczCrUNb swljAaOU6id/m+WhDfecrV2o8HMLyhjN0w+QLst1eHNzP9WL7evZ9OSdD PN/RfpPbty3dGKxPm+GxreITaWc2b+7JRC3RM8fyHapzzeun2OnMLRUR/ 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5773"; a="25434639" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Oct 2009 15:49:45 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9GMniFY008129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Oct 2009 15:49:45 -0700 Received: from nasanexhub02.na.qualcomm.com (nasanexhub02.na.qualcomm.com [10.46.143.120]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9GMniu0024033 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 16 Oct 2009 15:49:44 -0700 (PDT) Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 16 Oct 2009 15:49:43 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Fri, 16 Oct 2009 15:49:43 -0700 From: "Laganier, Julien" To: Nicolas Williams Date: Fri, 16 Oct 2009 15:49:41 -0700 Thread-Topic: [btns] Minor connection-latch problem in AUTH48 Thread-Index: AcpOqKBFczXeTb4CTs+CFM/u0zhK1wACgwDA Message-ID: References: <20091015221608.GC907@Sun.COM> <20091016203953.GQ892@Sun.COM> <20091016211652.GV892@Sun.COM> In-Reply-To: <20091016211652.GV892@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "btns@ietf.org" Subject: Re: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 22:49:41 -0000 Nicolas Williams wrote: >=20 > On Fri, Oct 16, 2009 at 02:13:13PM -0700, Laganier, Julien wrote: > > Nicolas Williams wrote > > > Perhaps the WG would say that we should REQUIRE that the key > manager > > > initiate IKE/child SAs ahead of any triggering packet as a > > > simplification of the model (then we don't need a LARVAL state). > But I > > > could certainly see implementors not wanting to do that (for one it > > > makes the CREATE_CONNECTION_LATCH() call slow). > > > > I think this is the external behavior that we want to capture. The > > specifics of how a given implementation achieves that need not to be > > specified in the RFC as long as the conceptual behavior is clear and > > guarantees interoperability. >=20 > Let me re-think the text. Perhaps I'll simply add a note that an > implementor whose key manager does not immediately initiake IKE/child > SAs on CREATE_CONNECTION_LATCH() must have a larval state that we don't > describe. >=20 > Would that work? Yup - sounds good. (and maybe transient or intermediate is better than larv= al to describe that state...) --julien From Nicolas.Williams@sun.com Mon Oct 19 09:51:35 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F6F83A6836 for ; Mon, 19 Oct 2009 09:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.382 X-Spam-Level: X-Spam-Status: No, score=-4.382 tagged_above=-999 required=5 tests=[AWL=-0.750, 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 I+htnHucoqHg for ; Mon, 19 Oct 2009 09:51:34 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id A71963A681E for ; Mon, 19 Oct 2009 09:51:32 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9JGpdBO007240 for ; Mon, 19 Oct 2009 16:51:39 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9JGpdgW030692 for ; Mon, 19 Oct 2009 10:51:39 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9JGeGji003141; Mon, 19 Oct 2009 11:40:16 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9JGeEnc003140; Mon, 19 Oct 2009 11:40:14 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 19 Oct 2009 11:40:14 -0500 From: Nicolas Williams To: "Laganier, Julien" Message-ID: <20091019164014.GF892@Sun.COM> References: <20091015221608.GC907@Sun.COM> <20091016203953.GQ892@Sun.COM> <20091016211652.GV892@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "btns@ietf.org" Subject: Re: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 16:51:35 -0000 OK, this way the changes are much smaller and localized -- only the description of CREATE_CONNECTION_LATCH() changes, to: o CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection parameters], [peer ID], [local ID]) -> latch handle | error If a) the requested latch does not exist (or exists, but is in the CLOSED state), b) all the latch parameters are provided, or if suitable SAs exist in the SAD from which to derive them, and c) if there are no conflicts with the SPD and SAD, then this creates a connection latch in the ESTABLISHED state. If the latch parameters are not provided and no suitable SAs exist in the SAD from which to derive those parameters, then the key manager MUST initiate child SAs, and if need be, IKE_SA, from which to derive those parameters. The key manager MAY delay the child SA setup and return immediately after the policy check, knowing that the ULP that requested the latch will subsequently output a packet that will trigger the SA establishment. Such an implementation may require an additional state in the connection latch state machine, a "LARVAL" state, that is not described herein. If the connection latch ultimately cannot be established, either because of conflicts or because no SAs can be established with the peer at the destination address, then an error is returned to the ULP. (If the key manager delayed SA establishment, and SA establishment ultimately fails, then the key manager has to inform the ULP, possibly asynchornously. This is one of several details that implementors who use a LARVAL state must take care of.) How's that? This way the change is small enough that it wouldn't have required WG discussion. I should have thought of this. Thanks Julien! Nico -- From julienl@qualcomm.com Mon Oct 19 14:59:31 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66FE33A6981 for ; Mon, 19 Oct 2009 14:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.71 X-Spam-Level: X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-1.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFlKO-PLOdlN for ; Mon, 19 Oct 2009 14:59:30 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 42A073A69AB for ; Mon, 19 Oct 2009 14:59:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1255989577; x=1287525577; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Nicolas=20Williams=20 |CC:=20"btns@ietf.org"=20|Date:=20Mon,=201 9=20Oct=202009=2014:59:31=20-0700|Subject:=20RE:=20[btns] =20Minor=20connection-latch=20problem=20in=20AUTH48 |Thread-Topic:=20[btns]=20Minor=20connection-latch=20prob lem=20in=20AUTH48|Thread-Index:=20AcpQ3X0dFfgmz/SlTImNd+X DyrqwhAADjoCw|Message-ID:=20|References: =20<20091015221608.GC907@Sun.COM>=0D=0A=20 =0D=0A=20<20091016203953.GQ892@Sun.COM>=0D=0A=20=0D=0A=20<20091016211652.GV892@Sun.COM>=0D=0A=20=0D=0A=20<20091019164014.GF892@Sun.COM> |In-Reply-To:=20<20091019164014.GF892@Sun.COM> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5776"=3B=20a=3D"25609620"; bh=LZde4+6kCXiFjUAfiXbk1KTWdU0ANvXLKz4OaH7Oj50=; b=PB32xlwjv2ys6+SRGPvXYxWpYYwHSS9c/BcI3Uc008kAVo55n1ko9i8W /cpZNT9gPrckdPyXNDnB1T5l/jrHRBcyUINweilCmBCwa9z/rMEdvYk+p /DSrZPsyoMJjCHNe3dzgN5eT6DYpbCdTz8UjAEogMrerRgBT/Mxsih7OA 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5776"; a="25609620" Received: from pdmz-ns-mip.qualcomm.com (HELO ithilien.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Oct 2009 14:59:37 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9JLxbbt004937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2009 14:59:37 -0700 Received: from nasanexhub03.na.qualcomm.com (nasanexhub03.na.qualcomm.com [10.46.93.98]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9JLxaSE017156 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 19 Oct 2009 14:59:37 -0700 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 19 Oct 2009 14:59:36 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.639.21; Mon, 19 Oct 2009 14:59:36 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Mon, 19 Oct 2009 14:59:33 -0700 From: "Laganier, Julien" To: Nicolas Williams Date: Mon, 19 Oct 2009 14:59:31 -0700 Thread-Topic: [btns] Minor connection-latch problem in AUTH48 Thread-Index: AcpQ3X0dFfgmz/SlTImNd+XDyrqwhAADjoCw Message-ID: References: <20091015221608.GC907@Sun.COM> <20091016203953.GQ892@Sun.COM> <20091016211652.GV892@Sun.COM> <20091019164014.GF892@Sun.COM> In-Reply-To: <20091019164014.GF892@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "btns@ietf.org" Subject: Re: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 21:59:31 -0000 Hi Nico, Nicolas Williams wrote: >=20 > OK, this way the changes are much smaller and localized -- only the > description of CREATE_CONNECTION_LATCH() changes, to: >=20 > o CREATE_CONNECTION_LATCH(5-tuple, [type and quality-of-protection > parameters], [peer ID], [local ID]) -> latch handle | error >=20 > If a) the requested latch does not exist (or exists, but is in > the CLOSED state), b) all the latch parameters are provided, or > if suitable SAs exist in the SAD from which to derive them, and > c) if there are no conflicts with the SPD and SAD, then this > creates a connection latch in the ESTABLISHED state. If the > latch parameters are not provided and no suitable SAs exist in > the SAD from which to derive those parameters, then the key > manager MUST initiate child SAs, and if need be, IKE_SA, from > which to derive those parameters. >=20 > The key manager MAY delay the child SA setup and return > immediately after the policy check, knowing that the ULP that > requested the latch will subsequently output a packet that > will trigger the SA establishment. Such an implementation may > require an additional state in the connection latch state > machine, a "LARVAL" state, that is not described herein. >=20 > If the connection latch ultimately cannot be established, > either because of conflicts or because no SAs can be > established with the peer at the destination address, then an > error is returned to the ULP. (If the key manager delayed SA > establishment, and SA establishment ultimately fails, then the > key manager has to inform the ULP, possibly asynchornously. > This is one of several details that implementors who use a > LARVAL state must take care of.) >=20 > How's that? >=20 > This way the change is small enough that it wouldn't have required WG > discussion. I should have thought of this. Thanks Julien! Hmm. Better, but somehow I'd rather take the 2 last paragraphs about the "l= arval" state completely out, because right now it IMHO says either too much= or too less. It's not precise enough to tell an implementer who hasn't fol= lowed that discussion what to do yet it outlines at alternative to the key = manager establishing the SA straight and the ULP latching the connection on= the SA. If you want to keep the "larval" text in, I've did some wordsmithing below = that you might want to consider: =20 > The key manager MAY delay the child SA setup and return > immediately after the policy check, knowing that the ULP that > requested the latch will subsequently output a packet that > will trigger the SA establishment. Such an implementation may > require an additional transient state in the connection latch st= ate > machine, a "LARVAL" state, to which the connection is latched pe= nding > establishment of the SA. The "LARVAL" state is not described fur= ther herein. >=20 > If the connection latch ultimately cannot be established, > either because of conflicts or because no SAs can be > established with the peer at the destination address, then an > error is returned to the ULP. (Note that if the key manager del= ayed SA > establishment, and SA establishment ultimately fails, then the > key manager has to inform the ULP, possibly asynchronously. > This is one of several details that implementers who use a > LARVAL state must take care of.) --julien From Nicolas.Williams@sun.com Mon Oct 19 15:25:26 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B31193A687E for ; Mon, 19 Oct 2009 15:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.506 X-Spam-Level: X-Spam-Status: No, score=-5.506 tagged_above=-999 required=5 tests=[AWL=0.540, 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 bINTBc3328PJ for ; Mon, 19 Oct 2009 15:25:26 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id CA0CD3A635F for ; Mon, 19 Oct 2009 15:25:25 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9JMPWpj003754 for ; Mon, 19 Oct 2009 22:25:32 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9JMPWRv062562 for ; Mon, 19 Oct 2009 16:25:32 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9JMEAtV003391; Mon, 19 Oct 2009 17:14:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9JMEAfg003390; Mon, 19 Oct 2009 17:14:10 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 19 Oct 2009 17:14:10 -0500 From: Nicolas Williams To: "Laganier, Julien" Message-ID: <20091019221410.GN892@Sun.COM> References: <20091015221608.GC907@Sun.COM> <20091016203953.GQ892@Sun.COM> <20091016211652.GV892@Sun.COM> <20091019164014.GF892@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "btns@ietf.org" Subject: Re: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2009 22:25:26 -0000 On Mon, Oct 19, 2009 at 02:59:31PM -0700, Laganier, Julien wrote: > Nicolas Williams wrote: > > OK, this way the changes are much smaller and localized -- only the > > description of CREATE_CONNECTION_LATCH() changes, to: > > Hmm. Better, but somehow I'd rather take the 2 last paragraphs about > the "larval" state completely out, because right now it IMHO says > either too much or too less. It's not precise enough to tell an > implementer who hasn't followed that discussion what to do yet it > outlines at alternative to the key manager establishing the SA > straight and the ULP latching the connection on the SA. I really want to leave the MAY in, as well as the note that that implies a state that we're not describing. I'm willing to remove the parenthetical note, since that's really informative of something that implementors, who chose to implement that MAY, would figure out on their own anyways. > If you want to keep the "larval" text in, I've did some wordsmithing > below that you might want to consider: I can't tell what's particularly different in your text. You did split a sentence, but I think I'll just re-write that sentence this way: "Such an implementation may require an additional state in the connection latch state machine: a "LARVAL" state, so to speak, that is not described herein." I think the colon helps more than either the comma I had written originally, or than a period. Nico -- From julienl@qualcomm.com Tue Oct 20 09:30:19 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 930E828C140 for ; Tue, 20 Oct 2009 09:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.771 X-Spam-Level: X-Spam-Status: No, score=-103.771 tagged_above=-999 required=5 tests=[AWL=-1.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZ8jYu5rqvZT for ; Tue, 20 Oct 2009 09:30:17 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 52A523A6A1F for ; Tue, 20 Oct 2009 09:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256056211; x=1287592211; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20Nicolas=20Williams=20 |CC:=20"btns@ietf.org"=20|Date:=20Tue,=202 0=20Oct=202009=2009:30:08=20-0700|Subject:=20RE:=20[btns] =20Minor=20connection-latch=20problem=20in=20AUTH48 |Thread-Topic:=20[btns]=20Minor=20connection-latch=20prob lem=20in=20AUTH48|Thread-Index:=20AcpRDDZrzgFh5vQsTaCUrmT D0p/xMQAlhE9Q|Message-ID:=20|References: =20<20091015221608.GC907@Sun.COM>=0D=0A=20 =0D=0A=20<20091016203953.GQ892@Sun.COM>=0D=0A=20=0D=0A=20<20091016211652.GV892@Sun.COM>=0D=0A=20=0D=0A=20<20091019164014.GF892@Sun.COM>=0D=0A =20=0D=0A=20<20091019221410.GN892@Sun.COM> |In-Reply-To:=20<20091019221410.GN892@Sun.COM> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5777"=3B=20a=3D"25670561"; bh=xcr2rse8bzRZ1vmfEijCzm5h5KcN2DTrsgUJn+Jw/9I=; b=gxiCAGUSqf2fAJZBW7sUVn1WGw/XBDSX2CzOL4e2WwG9pZV/n48k85B/ 4erz3HfX28Wtv3kci4M6nEcuQ57s4AWnz8FBu3vUl49zpIPpSAJC3BoF4 mMK90JhPqp3Ce1KmHWqeVU3fRJsRYM0r/aNfXJQ6glFkpW2Ip4AmurJGb 4=; X-IronPort-AV: E=McAfee;i="5300,2777,5777"; a="25670561" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Oct 2009 09:30:11 -0700 Received: from msgtransport01.qualcomm.com (msgtransport01.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9KGUAL0018922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Oct 2009 09:30:10 -0700 Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport01.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9KGU99n014189 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 20 Oct 2009 09:30:09 -0700 Received: from nalasexhub02.na.qualcomm.com (10.47.130.89) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 20 Oct 2009 09:30:09 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub02.na.qualcomm.com ([10.47.130.89]) with mapi; Tue, 20 Oct 2009 09:30:08 -0700 From: "Laganier, Julien" To: Nicolas Williams Date: Tue, 20 Oct 2009 09:30:08 -0700 Thread-Topic: [btns] Minor connection-latch problem in AUTH48 Thread-Index: AcpRDDZrzgFh5vQsTaCUrmTD0p/xMQAlhE9Q Message-ID: References: <20091015221608.GC907@Sun.COM> <20091016203953.GQ892@Sun.COM> <20091016211652.GV892@Sun.COM> <20091019164014.GF892@Sun.COM> <20091019221410.GN892@Sun.COM> In-Reply-To: <20091019221410.GN892@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "btns@ietf.org" Subject: Re: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 16:30:19 -0000 > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > Sent: Monday, October 19, 2009 3:14 PM > To: Laganier, Julien > Cc: btns@ietf.org > Subject: Re: [btns] Minor connection-latch problem in AUTH48 >=20 > On Mon, Oct 19, 2009 at 02:59:31PM -0700, Laganier, Julien wrote: > > Nicolas Williams wrote: > > > OK, this way the changes are much smaller and localized -- only the > > > description of CREATE_CONNECTION_LATCH() changes, to: > > > > Hmm. Better, but somehow I'd rather take the 2 last paragraphs about > > the "larval" state completely out, because right now it IMHO says > > either too much or too less. It's not precise enough to tell an > > implementer who hasn't followed that discussion what to do yet it > > outlines at alternative to the key manager establishing the SA > > straight and the ULP latching the connection on the SA. >=20 > I really want to leave the MAY in, as well as the note that that > implies > a state that we're not describing. I'm willing to remove the > parenthetical note, since that's really informative of something that > implementors, who chose to implement that MAY, would figure out on > their > own anyways. >=20 > > If you want to keep the "larval" text in, I've did some wordsmithing > > below that you might want to consider: >=20 > I can't tell what's particularly different in your text. You did split > a sentence, but I think I'll just re-write that sentence this way: I added some words saying that the larval state is transient, and the conne= ction is latched is latched pending establishement of the SA, see below: =20 > "Such an implementation may require an additional state in the > connection latch state machine: a "LARVAL" state, so to speak, that is > not described herein." >=20 > I think the colon helps more than either the comma I had written > originally, or than a period. So how about: Such an implementation may require an additional transient state in the con= nection latch state machine: a "LARVAL" state, so to speak, to which the co= nnection is latched pending establishment of the SA. Such a "LARVAL" state is not described further her= ein. --julien From Nicolas.Williams@sun.com Tue Oct 20 11:18:42 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED4F28C137 for ; Tue, 20 Oct 2009 11:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.604 X-Spam-Level: X-Spam-Status: No, score=-5.604 tagged_above=-999 required=5 tests=[AWL=0.442, 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 VrRyM95vjOxI for ; Tue, 20 Oct 2009 11:18:42 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id D594D28C119 for ; Tue, 20 Oct 2009 11:18:38 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9KIIk3c012849 for ; Tue, 20 Oct 2009 18:18:46 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9KIIkt8052458 for ; Tue, 20 Oct 2009 12:18:46 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9KI7NI2003923; Tue, 20 Oct 2009 13:07:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9KI7N4c003922; Tue, 20 Oct 2009 13:07:23 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 20 Oct 2009 13:07:23 -0500 From: Nicolas Williams To: "Laganier, Julien" Message-ID: <20091020180723.GJ892@Sun.COM> References: <20091015221608.GC907@Sun.COM> <20091016203953.GQ892@Sun.COM> <20091016211652.GV892@Sun.COM> <20091019164014.GF892@Sun.COM> <20091019221410.GN892@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "btns@ietf.org" Subject: Re: [btns] Minor connection-latch problem in AUTH48 X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2009 18:18:42 -0000 On Tue, Oct 20, 2009 at 09:30:08AM -0700, Laganier, Julien wrote: > So how about: > > Such an implementation may require an additional transient state in > the connection latch state machine: a "LARVAL" state, so to speak, to > which the connection is latched pending establishment of the SA. Such > a "LARVAL" state is not described further herein. "transient" seems confusable/redundant to me: all these states are transient, in a way, since a latch is never permanently in one state. In the case of the CLOSED state I used the word "fleeting"; "ephemeral" would work just as well. I will use the word "fleeting", since I've already used it to the same effect. I'll send an updated .xml file to the RFC-Editor later today. Thanks! Nico -- From dbernard@ozonline.com.au Wed Oct 21 13:51:50 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 263D928C137 for ; Wed, 21 Oct 2009 13:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.7 X-Spam-Level: * X-Spam-Status: No, score=1.7 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994, STOX_REPLY_TYPE=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 ekzt0CBwLmS8 for ; Wed, 21 Oct 2009 13:51:49 -0700 (PDT) Received: from smtp.ozonline.com.au (smtp.ozonline.com.au [203.4.248.46]) by core3.amsl.com (Postfix) with ESMTP id 30FDB28C119 for ; Wed, 21 Oct 2009 13:51:48 -0700 (PDT) Received: from DanielPC (adsl-syd-4-240.ozonline.com.au [210.4.231.240]) by smtp.ozonline.com.au (8.13.7/8.13.7) with SMTP id n9LKpreR004811 for ; Thu, 22 Oct 2009 07:51:54 +1100 Message-ID: <2A5090A900C84CBCBF98A5C2D900EF88@DanielPC> From: "DB" To: References: <20091015221608.GC907@Sun.COM><20091016203953.GQ892@Sun.COM> <20091016211652.GV892@Sun.COM> In-Reply-To: <20091016211652.GV892@Sun.COM> Date: Thu, 22 Oct 2009 07:51:33 +1100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Subject: [btns] Security UDT X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 20:51:50 -0000 I dont know how this WG works, but could this be included in your next agenda? I need your inputs and comments, http://tools.ietf.org/html/draft-d-sec-udt-00 From touch@ISI.EDU Wed Oct 21 14:29:38 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA4A28C104 for ; Wed, 21 Oct 2009 14:29:38 -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 2yuq0dgUVgig for ; Wed, 21 Oct 2009 14:29:37 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 66C9A28C100 for ; Wed, 21 Oct 2009 14:29:37 -0700 (PDT) Received: from [10.251.94.42] (mobile-166-137-133-031.mycingular.net [166.137.133.31]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id n9LLTVTX008214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 Oct 2009 14:29:36 -0700 (PDT) From: Joe Touch To: DB In-Reply-To: <2A5090A900C84CBCBF98A5C2D900EF88@DanielPC> X-Mailer: iPhone Mail (7D11) References: <20091015221608.GC907@Sun.COM><20091016203953.GQ892@Sun.COM> <20091016211652.GV892@Sun.COM> <2A5090A900C84CBCBF98A5C2D900EF88@DanielPC> Message-Id: <91473272-CCF6-4493-A4C2-9453FBB39F93@isi.edu> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Wed, 21 Oct 2009 17:29:21 -0400 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "" Subject: Re: [btns] Security UDT X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2009 21:29:38 -0000 Seems out of scope for BTNS. See our charter. You might try SAAG. Joe On Oct 21, 2009, at 4:51 PM, "DB" wrote: > I dont know how this WG works, but could this be included in your > next agenda? > I need your inputs and comments, > > http://tools.ietf.org/html/draft-d-sec-udt-00 > > _______________________________________________ > btns mailing list > btns@ietf.org > https://www.ietf.org/mailman/listinfo/btns From rfc-editor@rfc-editor.org Wed Oct 28 12:22:02 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60FEB28C0CE; Wed, 28 Oct 2009 12:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.93 X-Spam-Level: X-Spam-Status: No, score=-16.93 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] 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 DBARTCtCJ0ho; Wed, 28 Oct 2009 12:22:01 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 7D30028C1A4; Wed, 28 Oct 2009 12:22:01 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 54E06356BC1; Wed, 28 Oct 2009 12:19:11 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20091028191911.54E06356BC1@bosco.isi.edu> Date: Wed, 28 Oct 2009 12:19:11 -0700 (PDT) Cc: btns@ietf.org, rfc-editor@rfc-editor.org Subject: [btns] RFC 5660 on IPsec Channels: Connection Latching X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 19:22:02 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5660 Title: IPsec Channels: Connection Latching Author: N. Williams Status: Standards Track Date: October 2009 Mailbox: Nicolas.Williams@sun.com Pages: 31 Characters: 74209 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-btns-connection-latching-11.txt URL: http://www.rfc-editor.org/rfc/rfc5660.txt This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create "channels" by latching "connections" (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture. Connection latching can be used to protect applications against accidentally exposing live packet flows to unintended peers, whether as the result of a reconfiguration of IPsec or as the result of using weak peer identity to peer address associations. Weak association of peer ID and peer addresses is at the core of Better Than Nothing Security (BTNS); thus, connection latching can add a significant measure of protection to BTNS IPsec nodes. Finally, the availability of IPsec channels will make it possible to use channel binding to IPsec channels. [STANDARDS TRACK] This document is a product of the Better-Than-Nothing Security 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 USC/Information Sciences Institute From julienl@qualcomm.com Wed Oct 28 13:41:19 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70C693A6A21 for ; Wed, 28 Oct 2009 13:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.21 X-Spam-Level: X-Spam-Status: No, score=-105.21 tagged_above=-999 required=5 tests=[AWL=0.789, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkj9-5AfZV10 for ; Wed, 28 Oct 2009 13:41:17 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A443E3A686C for ; Wed, 28 Oct 2009 13:41:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1256762493; x=1288298493; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Laganier,=20Julien"=20 |To:=20"Nicolas.Williams@sun.com"=20|CC:=20"btns@ietf.org"=20|Date:=20Wed ,=2028=20Oct=202009=2013:41:27=20-0700|Subject:=20RE:=20[ btns]=20RFC=205660=20on=20IPsec=20Channels:=20Connection =20Latching|Thread-Topic:=20[btns]=20RFC=205660=20on=20IP sec=20Channels:=20Connection=20Latching|Thread-Index:=20A cpYA/kJHOX62A53TFiyaqeu4IlBdgACs2Zg|Message-ID:=20|References:=20<20091028191911.54E06356BC1@bosco. isi.edu>|In-Reply-To:=20<20091028191911.54E06356BC1@bosco .isi.edu>|Accept-Language:=20en-US|Content-Language:=20en -US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5300,2777,5785"=3B=20a=3D"26313994"; bh=V58yGcI0pJLKAtXYS55bdS+Mf6Pl1mn5SQbL+EiPbOw=; b=dyYCyDOGX1iNYPiGqiD/JRPgFl+1tyAT3RiJ3rWiLcTKKYZNhnFanE5w D1e6Rm8ThdO6j9dfRvR12VjZ9d31TC8hM+7QPWTWiX+cNzCHGRcY5HQPj YX9aivuTUmO6lbiDc/HImP9iQVsGLagWQNAs977vqqlGG3lY6lRRrm3KK 0=; X-IronPort-AV: E=McAfee;i="5300,2777,5785"; a="26313994" Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Oct 2009 13:41:31 -0700 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9SKfUrZ000440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Oct 2009 13:41:31 -0700 Received: from nasanexhub06.na.qualcomm.com (nasanexhub06.na.qualcomm.com [129.46.134.254]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n9SKfU3S004933 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 Oct 2009 13:41:30 -0700 (PDT) Received: from nalasexhub04.na.qualcomm.com (10.47.130.55) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 28 Oct 2009 13:41:30 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub04.na.qualcomm.com ([10.47.130.55]) with mapi; Wed, 28 Oct 2009 13:41:29 -0700 From: "Laganier, Julien" To: "Nicolas.Williams@sun.com" Date: Wed, 28 Oct 2009 13:41:27 -0700 Thread-Topic: [btns] RFC 5660 on IPsec Channels: Connection Latching Thread-Index: AcpYA/kJHOX62A53TFiyaqeu4IlBdgACs2Zg Message-ID: References: <20091028191911.54E06356BC1@bosco.isi.edu> In-Reply-To: <20091028191911.54E06356BC1@bosco.isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "btns@ietf.org" Subject: Re: [btns] RFC 5660 on IPsec Channels: Connection Latching X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 20:41:19 -0000 Congratulations Nico! And thanks to those that made this possible. --julien > -----Original Message----- > From: btns-bounces@ietf.org [mailto:btns-bounces@ietf.org] On Behalf Of > rfc-editor@rfc-editor.org > Sent: Wednesday, October 28, 2009 12:19 PM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: btns@ietf.org; rfc-editor@rfc-editor.org > Subject: [btns] RFC 5660 on IPsec Channels: Connection Latching >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 5660 >=20 > Title: IPsec Channels: Connection Latching > Author: N. Williams > Status: Standards Track > Date: October 2009 > Mailbox: Nicolas.Williams@sun.com > Pages: 31 > Characters: 74209 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-btns-connection-latching-11.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc5660.txt >=20 > This document specifies, abstractly, how to interface applications > and transport protocols with IPsec so as to create "channels" by > latching "connections" (packet flows) to certain IPsec Security > Association (SA) parameters for the lifetime of the connections. > Connection latching is layered on top of IPsec and does not modify > the underlying IPsec architecture. >=20 > Connection latching can be used to protect applications against > accidentally exposing live packet flows to unintended peers, whether > as the result of a reconfiguration of IPsec or as the result of using > weak peer identity to peer address associations. Weak association of > peer ID and peer addresses is at the core of Better Than Nothing > Security (BTNS); thus, connection latching can add a significant > measure of protection to BTNS IPsec nodes. >=20 > Finally, the availability of IPsec channels will make it possible to > use channel binding to IPsec channels. [STANDARDS TRACK] >=20 > This document is a product of the Better-Than-Nothing Security Working > Group of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > 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. >=20 > 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 >=20 > For searching the RFC series, see http://www.rfc- > editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > 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. >=20 >=20 > The RFC Editor Team > USC/Information Sciences Institute >=20 >=20 > _______________________________________________ > btns mailing list > btns@ietf.org > https://www.ietf.org/mailman/listinfo/btns From Nicolas.Williams@sun.com Wed Oct 28 14:01:02 2009 Return-Path: X-Original-To: btns@core3.amsl.com Delivered-To: btns@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C203028C1FE for ; Wed, 28 Oct 2009 14:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=0.029, 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 IpsFvPekyUC7 for ; Wed, 28 Oct 2009 14:01:01 -0700 (PDT) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id C139328C104 for ; Wed, 28 Oct 2009 14:01:01 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n9SL1FQ0005490 for ; Wed, 28 Oct 2009 21:01:15 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9SL1Ekw064889 for ; Wed, 28 Oct 2009 15:01:14 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9SKnmFB002756; Wed, 28 Oct 2009 15:49:48 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9SKnmqK002755; Wed, 28 Oct 2009 15:49:48 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 28 Oct 2009 15:49:48 -0500 From: Nicolas Williams To: "Laganier, Julien" Message-ID: <20091028204947.GE1105@Sun.COM> References: <20091028191911.54E06356BC1@bosco.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: "btns@ietf.org" Subject: Re: [btns] RFC 5660 on IPsec Channels: Connection Latching X-BeenThere: btns@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Better-Than-Nothing-Security Working Group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2009 21:01:02 -0000 On Wed, Oct 28, 2009 at 01:41:27PM -0700, Laganier, Julien wrote: > > URL: http://www.rfc-editor.org/rfc/rfc5660.txt > > Congratulations Nico! > > And thanks to those that made this possible. The RFC has an acknodlegements section listing a number of WG participants who made critical contributions. This RFC could not possibly have been published without their help. Thank you all so much! Nico --