From hartmans-ietf at mit.edu Tue Dec 4 09:58:08 2007 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Tue, 4 Dec 2007 12:58:08 -0500 (EST) Subject: [anonsec] Five minutes to discuss nfs interactions Message-ID: <20071204175808.4EDC84819@carter-zimmerman.suchdamage.org> I'd like to request five minutes on the agenda to discuss interactions between our work and nfs. From hartmans-ietf at mit.edu Thu Dec 6 15:38:36 2007 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 06 Dec 2007 18:38:36 -0500 Subject: [anonsec] Comments on connection latching draft Message-ID: What is the purpose of the connection states? I see them enumerated but never used. Why must implementations make available nat state? I'm unconvinced that is well enough defined to actually be useful. o Any IPsec channel created with a given peer while another distinct, established IPsec channel exists with the same source and destination addresses SHOULD be bound to the same peer. How does this interact with nats? Is it really desirable? It seems like the BITS model plus proprietary extensions might work for channel binding. Section 2.1: What does it mean for connection latches to be broken? Section 2.1: define what a conflicting latch is; you use the term several times but don't define it. There is what I think is a definition but it is not associated with the term. From Nicolas.Williams at sun.com Thu Dec 6 15:57:39 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 6 Dec 2007 17:57:39 -0600 Subject: [anonsec] Comments on connection latching draft In-Reply-To: References: Message-ID: <20071206235738.GA8628@Sun.COM> On Thu, Dec 06, 2007 at 06:38:36PM -0500, Sam Hartman wrote: > What is the purpose of the connection states? I see them enumerated but never used. To help describe the process by which latches are created and torn down. > Why must implementations make available nat state? I'm unconvinced > that is well enough defined to actually be useful. I think this is Michael's requirement. > o Any IPsec channel created with a given peer while another > distinct, established IPsec channel exists with the same source > and destination addresses SHOULD be bound to the same peer. > > > How does this interact with nats? Hmmm, badly :) > Is it really desirable? It's a mitigation for BTNS clients using non-channel binding applications with multiple TCP connections. It's not important to me, and I'll be glad to remove it. > It seems like the BITS model plus proprietary extensions might work for channel binding. That's native IPsec built with BITS components. > Section 2.1: What does it mean for connection latches to be broken? That ULPs (and applications) are informed. ULPs are informed synchronously, so they can close/reset the connection before any subsequent packets can be accepted. > Section 2.1: define what a conflicting latch is; you use the term > several times but don't define it. There is what I think is a > definition but it is not associated with the term. Here: o Create a connection latch object for a ULP 5-tuple (local and remote address, protocol and local and remote port numbers). This operation succeeds when no conflicting connection latch objects exist and when there exist no child SAs encompassing the given 5-tuple or when all such SAs are with the same peer and equal quality of protection. The key manager SHOULD attempt to create a suitable SA pair if one does not already exist; if it does then it MUST use the 5-tuple as the initial traffic selectors of the proposed child SAs. s/no conflicting connection latch objects exist/no connection latch exists already with the same 5-tuple/ I.e., "conflicting connection latch" there means that a latch with the same 5-tuple as the proposed new latch already exists. The latch manager can know this while the ULP cannot, which is why the latch manager checks this. So far I'm putting latch management in the same place as key management, but this is very abstract -- it need not translate into latch management being done by an IKE daemon. From hartmans-ietf at mit.edu Thu Dec 6 16:08:36 2007 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 06 Dec 2007 19:08:36 -0500 Subject: [anonsec] Comments on connection latching draft In-Reply-To: <20071206235738.GA8628@Sun.COM> (Nicolas Williams's message of "Thu, 6 Dec 2007 17:57:39 -0600") References: <20071206235738.GA8628@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Thu, Dec 06, 2007 at 06:38:36PM -0500, Sam Hartman Nicolas> wrote: >> What is the purpose of the connection states? I see them >> enumerated but never used. Nicolas> To help describe the process by which latches are created Nicolas> and torn down. Then actually use the states in section 2 etc. >> Why must implementations make available nat state? I'm >> unconvinced that is well enough defined to actually be useful. Nicolas> I think this is Michael's requirement. >> o Any IPsec channel created with a given peer while another >> distinct, established IPsec channel exists with the same source >> and destination addresses SHOULD be bound to the same peer. >> >> >> How does this interact with nats? Nicolas> Hmmm, badly :) >> Is it really desirable? Nicolas> It's a mitigation for BTNS clients using non-channel Nicolas> binding applications with multiple TCP connections. It's Nicolas> not important to me, and I'll be glad to remove it. >> It seems like the BITS model plus proprietary extensions might >> work for channel binding. Nicolas> That's native IPsec built with BITS components. >> Section 2.1: What does it mean for connection latches to be >> broken? Nicolas> That ULPs (and applications) are informed. ULPs are Nicolas> informed synchronously, so they can close/reset the Nicolas> connection before any subsequent packets can be accepted. >> Section 2.1: define what a conflicting latch is; you use the >> term several times but don't define it. There is what I think >> is a definition but it is not associated with the term. Nicolas> Here: Nicolas> o Create a connection latch object for a ULP 5-tuple Nicolas> (local and remote address, protocol and local and remote Nicolas> port numbers). This operation succeeds when no Nicolas> conflicting connection latch objects exist and when there Nicolas> exist no child SAs encompassing the given 5-tuple or when Nicolas> all such SAs are with the same peer and equal quality of Nicolas> protection. The key manager SHOULD attempt to create a Nicolas> suitable SA pair if one does not already exist; if it Nicolas> does then it MUST use the 5-tuple as the initial traffic Nicolas> selectors of the proposed child SAs. Nicolas> s/no conflicting connection latch objects exist/no Nicolas> connection latch exists already with the same 5-tuple/ Nicolas> I.e., "conflicting connection latch" there means that a Nicolas> latch with the same 5-tuple as the proposed new latch Nicolas> already exists. The latch manager can know this while Nicolas> the ULP cannot, which is why the latch manager checks Nicolas> this. Nicolas> So far I'm putting latch management in the same place as Nicolas> key management, but this is very abstract -- it need not Nicolas> translate into latch management being done by an IKE Nicolas> daemon. From paul at xelerance.com Thu Dec 6 20:50:06 2007 From: paul at xelerance.com (Paul Wouters) Date: Thu, 6 Dec 2007 23:50:06 -0500 (EST) Subject: [anonsec] Comments on connection latching draft In-Reply-To: <20071206235738.GA8628@Sun.COM> References: <20071206235738.GA8628@Sun.COM> Message-ID: On Thu, 6 Dec 2007, Nicolas Williams wrote: > To help describe the process by which latches are created and torn down. > > > Why must implementations make available nat state? I'm unconvinced > > that is well enough defined to actually be useful. > > I think this is Michael's requirement. I think this might have to do with detecting multiple clients behind the same NAT router. > > o Any IPsec channel created with a given peer while another > > distinct, established IPsec channel exists with the same source > > and destination addresses SHOULD be bound to the same peer. > > > > > > How does this interact with nats? > > Hmmm, badly :) Why not make it souce and destination address plus port? > o Create a connection latch object for a ULP 5-tuple (local and > remote address, protocol and local and remote port numbers). Like here. Paul From Nicolas.Williams at sun.com Sat Dec 8 22:43:50 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 9 Dec 2007 00:43:50 -0600 Subject: [anonsec] Comments on connection latching draft In-Reply-To: References: <20071206235738.GA8628@Sun.COM> Message-ID: <20071209064350.GB11013@Sun.COM> On Thu, Dec 06, 2007 at 11:50:06PM -0500, Paul Wouters wrote: > On Thu, 6 Dec 2007, Nicolas Williams wrote: > > > Why must implementations make available nat state? I'm unconvinced > > > that is well enough defined to actually be useful. > > > > I think this is Michael's requirement. > > I think this might have to do with detecting multiple clients behind > the same NAT router. The information is available, therefore requiring that it be made available seems reasonable. Making this a recommendation is also reasonable. > > > o Any IPsec channel created with a given peer while another > > > distinct, established IPsec channel exists with the same source > > > and destination addresses SHOULD be bound to the same peer. > > > > > > > > > How does this interact with nats? > > > > Hmmm, badly :) > > Why not make it souce and destination address plus port? Did you mean only one port, and if so, the destination port, or both ports? (Connection latching already does this for all five elements of the 5-tuple, so if your answer is "both" then note that that's the whole point of connection latching :) From Internet-Drafts at ietf.org Sun Dec 9 00:30:01 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Sun, 09 Dec 2007 03:30:01 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-04.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-connection-latching-04.txt -------------- next part -------------- From julien.IETF at laposte.net Thu Dec 13 05:51:35 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Thu, 13 Dec 2007 14:51:35 +0100 Subject: [anonsec] Minutes of BTNS session at IETF-70 Message-ID: <200712131451.37565.julien.IETF@laposte.net> Folks, Minutes of the meeting are available there: Please send to chairs corrections and/or add-ons, if any. Thanks. --julien From mcr at sandelman.ca Sat Dec 15 16:57:14 2007 From: mcr at sandelman.ca (Michael Richardson) Date: Sat, 15 Dec 2007 19:57:14 -0500 Subject: [anonsec] Comments on connection latching draft In-Reply-To: <20071206235738.GA8628@Sun.COM> References: <20071206235738.GA8628@Sun.COM> Message-ID: Nicolas Williams wrote: > On Thu, Dec 06, 2007 at 06:38:36PM -0500, Sam Hartman wrote: >> What is the purpose of the connection states? I see them enumerated but never used. > > To help describe the process by which latches are created and torn down. > >> Why must implementations make available nat state? I'm unconvinced >> that is well enough defined to actually be useful. > I think this is Michael's requirement. > >> o Any IPsec channel created with a given peer while another >> distinct, established IPsec channel exists with the same source >> and destination addresses SHOULD be bound to the same peer. >> >> >> How does this interact with nats? > > Hmmm, badly :) If as you say, it's my requirement, let me remember why. I thought that we had ruled NAT interaction as out-of-scope. BTW: real world case where channel binding is necessary: http://www.schneier.com/blog/archives/2007/12/defeating_the_s.html ... This works because the two security systems are decoupled. And the shoe screening machine is so crowded and chaotic, and so poorly manned, that no one notices the switch. From hartmans-ietf at mit.edu Thu Dec 20 12:25:07 2007 From: hartmans-ietf at mit.edu (Sam Hartman) Date: Thu, 20 Dec 2007 15:25:07 -0500 Subject: [anonsec] AD review comments on draft-ietf-btns-core Message-ID: Hi. I've sent the core document to last call. It was not as readable as I would like. If you get a bunch of comments back from people who do not understand you probably should take a style and readability pass. I have two changes I'd like te request as last call comments myself. First, when you require bare RSA cert payloads, please reference a specific section of the IKE V2 spec for a definition of this. Also, how can BTNS work with DSA if nodes are required to include RSA payloads? Please replace the statement in section 4.2 that leap of faith is being handled by BTNS with a statement that it is an item for future work.