From Internet-Drafts at ietf.org Tue Sep 4 14:10:02 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue, 04 Sep 2007 17:10:02 -0400 Subject: [anonsec] I-D Action:draft-ietf-btns-core-05.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-core-05.txt -------------- next part -------------- From Nicolas.Williams at sun.com Fri Sep 7 15:07:57 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 7 Sep 2007 17:07:57 -0500 Subject: [anonsec] A note about connection latchin. Message-ID: <20070907220757.GL22639@Sun.COM> The connection latching I-D puts forward two informative models. The next version, which I'm working on right now, will make one of those models normative. The two models, you might recall, are: a) ULPs interface with IPsec via "template" PAD and SPD entries that get "cloned" upon triggering events. For example, a TCP connect() would create a template PAD entry with the connection's 5-tuple as child SA constraints, prior to sending the TCP SYN packet. A TCP listen() would create a template PAD entry with the listener's 3-tuple as child SA constraints, prior to accepting any TCP SYN packets. There are other details, of course, but let's obviate them here. The next version of the I-D will certainly have fleshed this model out a lot more. b) ULPs interface with IPsec by tagging packets as they go up or down the stack. On input the IPsec layer tags the packet with the SAD entry for the SA that protected it; the ULP checks that the SAD matches the ULP's TCB latch and drops the packet if it does not. On output the ULP tags the packet with its latched requirements and the IPsec layer uses this to find an appropriate SA to protect the outgoing packet with. I'll make (a) the normative model, though (b) is much simpler to implement (unless you have a NIC that can offload ESP/AH processing but which cannot tag inbound packets with enough information). Each model has some quirks though, and that's what I want to discuss here. The (a) model has the following quirks: - synchronization Packets race with changes to the IPsec PAD/SPD. This is a problem that implementations of this model MUST overcome. One way to overcome it is to create a barrier based on a timestamp: updates to the PAD/SPD update the timestamp, the IPsec layer tags inbound packets with the current timestamp, and the ULPs tag outbound packets with the current timestamp, with the ULP layers dropping packets whose timestamp tags are too old. - ambiguous configurations From what I can tell it is possible to configure IPsec so that multiple peers can have access to overlapping traffic selectors, and when this is the case we end up with a situation where: - the ULP may not be able to determine the parameters to latch, - and where even if the ULP could (e.g., because the ambiguous configuration is created after a connection latch) the packets for the given packet flow could be protected by one or more SA pairs that do not match the latched parameters. This is hard to detect and prevent. I think the right thing to do is to document the problem and warn administrators not to create such configurations if they would be problematic for them. The (b) model has a single, minor quirk: if multiple peers can access the same addresses then there may be multiple latched connections with the same peer address, but each with a different peer ID. Advice on the ambiguous configuration problem of model (a) is welcome. Nico -- From Internet-Drafts at ietf.org Tue Sep 4 14:10:02 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Tue, 04 Sep 2007 17:10:02 -0400 Subject: [anonsec] I-D Action:draft-ietf-btns-core-05.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-core-05.txt -------------- next part -------------- -------------- next part -------------- _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce From Nicolas.Williams at sun.com Sun Sep 9 17:10:12 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sun, 9 Sep 2007 19:10:12 -0500 Subject: [anonsec] A note about connection latchin. In-Reply-To: <20070907220757.GL22639@Sun.COM> References: <20070907220757.GL22639@Sun.COM> Message-ID: <20070910001012.GA27297@Sun.COM> Hmmm, never mind. In model (a) connection latching is to be enforced by key management at latch and child SA creation time. That is what must change in the processing model to allow a description of model (a). From julien.IETF at laposte.net Mon Sep 10 00:16:49 2007 From: julien.IETF at laposte.net (Julien Laganier) Date: Mon, 10 Sep 2007 09:16:49 +0200 Subject: [anonsec] Fwd: Nomcom 2007-8: Nominations Close on Sep 10, 2007 Message-ID: <200709100916.49707.julien.IETF@laposte.net> FWIW, one message from our Nomcom chair: he's asking for more nominations and feedback on incumbents. --julien -------------- next part -------------- An embedded message was scrubbed... From: Lakshminath Dondeti Subject: Nomcom 2007-8: Nominations Close on Sep 10, 2007 Date: Fri, 07 Sep 2007 12:52:33 -0700 Size: 3974 Url: http://mailman.postel.org/pipermail/anonsec/attachments/20070910/e848f0d4/attachment.mht From kent at bbn.com Mon Sep 10 10:44:32 2007 From: kent at bbn.com (Stephen Kent) Date: Mon, 10 Sep 2007 13:44:32 -0400 Subject: [anonsec] A note about connection latchin. In-Reply-To: <20070907220757.GL22639@Sun.COM> References: <20070907220757.GL22639@Sun.COM> Message-ID: At 5:07 PM -0500 9/7/07, Nicolas Williams wrote: >The connection latching I-D puts forward two informative models. The >next version, which I'm working on right now, will make one of those >models normative. > >The two models, you might recall, are: > >a) ULPs interface with IPsec via "template" PAD and SPD entries that get > "cloned" upon triggering events. > > For example, a TCP connect() would create a template PAD entry with > the connection's 5-tuple as child SA constraints, prior to sending > the TCP SYN packet. A TCP listen() would create a template PAD entry > with the listener's 3-tuple as child SA constraints, prior to > accepting any TCP SYN packets. For SPD entries, the applicable term is "populate from packet" and we have a flag for that. PAD entries don't have 5-tuples, so did you mean SPD above? If so, do you want to specify the template PAD entry separately above? Steve -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.postel.org/pipermail/anonsec/attachments/20070910/279bf772/attachment.html From Nicolas.Williams at sun.com Mon Sep 10 13:22:29 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 10 Sep 2007 15:22:29 -0500 Subject: [anonsec] A note about connection latchin. In-Reply-To: References: <20070907220757.GL22639@Sun.COM> Message-ID: <20070910202228.GO27512@Sun.COM> On Mon, Sep 10, 2007 at 01:44:32PM -0400, Stephen Kent wrote: > At 5:07 PM -0500 9/7/07, Nicolas Williams wrote: > >a) ULPs interface with IPsec via "template" PAD and SPD entries that get > > "cloned" upon triggering events. > > > > For example, a TCP connect() would create a template PAD entry with > > the connection's 5-tuple as child SA constraints, prior to sending > > the TCP SYN packet. A TCP listen() would create a template PAD entry > > with the listener's 3-tuple as child SA constraints, prior to > > accepting any TCP SYN packets. > > For SPD entries, the applicable term is "populate from packet" and we > have a flag for that. PAD entries don't have 5-tuples, so did you > mean SPD above? If so, do you want to specify the template PAD entry > separately above? Although PFP seems appropriate, it's not quite sufficient. Since my post on Friday I've realized just how best to describe connection latching as an extension of the IPsec child SA authorization process. As for what I meant by referenceing 5-tuples and PAD entries, keep in mind that I wrote "template PAD entries" -- which in my I-D as it stood on Friday (not submitted) referred to something somewhat different from PAD entries. I'm abandoning that terminology; it's not just confusing: there's a better way to describe the state that is being created. Nico -- From kent at bbn.com Mon Sep 10 13:29:15 2007 From: kent at bbn.com (Stephen Kent) Date: Mon, 10 Sep 2007 16:29:15 -0400 Subject: [anonsec] A note about connection latchin. In-Reply-To: <20070910202228.GO27512@Sun.COM> References: <20070907220757.GL22639@Sun.COM> <20070910202228.GO27512@Sun.COM> Message-ID: At 3:22 PM -0500 9/10/07, Nicolas Williams wrote: >On Mon, Sep 10, 2007 at 01:44:32PM -0400, Stephen Kent wrote: >> At 5:07 PM -0500 9/7/07, Nicolas Williams wrote: >> >a) ULPs interface with IPsec via "template" PAD and SPD entries that get >> > "cloned" upon triggering events. >> > >> > For example, a TCP connect() would create a template PAD entry with >> > the connection's 5-tuple as child SA constraints, prior to sending >> > the TCP SYN packet. A TCP listen() would create a template PAD entry >> > with the listener's 3-tuple as child SA constraints, prior to >> > accepting any TCP SYN packets. >> >> For SPD entries, the applicable term is "populate from packet" and we >> have a flag for that. PAD entries don't have 5-tuples, so did you >> mean SPD above? If so, do you want to specify the template PAD entry >> separately above? > >Although PFP seems appropriate, it's not quite sufficient. Since my >post on Friday I've realized just how best to describe connection >latching as an extension of the IPsec child SA authorization process. > >As for what I meant by referenceing 5-tuples and PAD entries, keep in >mind that I wrote "template PAD entries" -- which in my I-D as it stood >on Friday (not submitted) referred to something somewhat different from >PAD entries. I'm abandoning that terminology; it's not just confusing: >there's a better way to describe the state that is being created. > >Nico >-- never mind .... :-) Steve From Internet-Drafts at ietf.org Tue Sep 11 23:50:01 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Wed, 12 Sep 2007 02:50:01 -0400 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-02.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-connection-latching-02.txt -------------- next part -------------- From Nicolas.Williams at sun.com Fri Sep 14 10:41:33 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 14 Sep 2007 12:41:33 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-02.txt In-Reply-To: References: Message-ID: <20070914174133.GF1920@Sun.COM> I'd appreciate some feedback on this version of the connection latching I-D. - In particular I'm looking for feedback on section 2.1, whether the proposed modification to the child SA authorization process is reasonable. (Note: the child SA authorization process is modified only when connection latching is used; see also the note in section 2.3 about a PAD entry flag to preserve traditional semantics.) - Section 2.2 should have been renamed (something like "Informative model: local packet tagging"). - Neither section 2.1 nor 2.2 talks about when to initiate SAs. But it should be obvious that the right time is when a latch is initiated. - Section 3 doesn't say much about the SPD. In particular, when an application requests that traffic be PROTECTED that would otherwise have been BYPASSed (or when a locally privileged app requests the opposite) then the SPD should be temporarily modified accordingly. This should be described in detail. - Sam proposed that we describe connection latching in BITS implementations. I'm not entirely sure if Sam meant describing a model where BITS devices are integrated into the local IP stack where such devices be interfaced to, or if he meant that we should describe how BITS/SG middle boxes can apply connection latching principles to traffic traversing them. If the former, then I believe that may not be possible without changes to those devices to bring them in line with the model described in section 2.2; aside from that the model in section 2.2 should suffice for BITS-like devices that can be interfaced to. If the latter, that's easy, but like all stateful middle boxes, the result is not 100% perfect. And channel binding is not possible in such a scenario. - Sam also wanted it to be possible to support connection latching and channel binding for road warriors who move from behind a VPN into the private network. I believe this is feasible using nested SAs (the outer SA being between the client and an SG, the inned SA being between the client and the server). But of course, whether TCP connections can survive such moves is another story -- the inner client address has to remain the same. Nico -- From Nicolas.Williams at sun.com Mon Sep 17 13:24:52 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 17 Sep 2007 15:24:52 -0500 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-02.txt In-Reply-To: <20070914174133.GF1920@Sun.COM> References: <20070914174133.GF1920@Sun.COM> Message-ID: <20070917202451.GB3328@Sun.COM> On Fri, Sep 14, 2007 at 12:41:33PM -0500, Nicolas Williams wrote: > I'd appreciate some feedback on this version of the connection latching > I-D. > > - In particular I'm looking for feedback on section 2.1, whether the > proposed modification to the child SA authorization process is > reasonable. (Note: the child SA authorization process is modified > only when connection latching is used; see also the note in section > 2.3 about a PAD entry flag to preserve traditional semantics.) I've found a way around that. I've submitted -03 just now. > - Neither section 2.1 nor 2.2 talks about when to initiate SAs. But it > should be obvious that the right time is when a latch is initiated. Fixed. > - Section 3 doesn't say much about the SPD. > > In particular, when an application requests that traffic be PROTECTED > that would otherwise have been BYPASSed (or when a locally privileged > app requests the opposite) then the SPD should be temporarily > modified accordingly. This should be described in detail. Sections 2.1 and 3 now both deal with this properly, methinks. Comments welcome. From Internet-Drafts at ietf.org Mon Sep 17 13:30:02 2007 From: Internet-Drafts at ietf.org (Internet-Drafts@ietf.org) Date: Mon, 17 Sep 2007 16:30:02 -0400 Subject: [anonsec] I-D Action:draft-ietf-btns-connection-latching-03.txt Message-ID: ENCODING mime FILE /internet-drafts/draft-ietf-btns-connection-latching-03.txt -------------- next part --------------